against databases
Jim Puls
jim at nondifferentiable.com
Sat Jan 16 15:54:24 PST 2010
On Jan 16, 2010, at 3:39 PM, Nathaniel Irons wrote:
> I agree completely; the thrust of jwz's point is to avoid screwing up the primary on-disk representation. All the machinery for performing fast scans/searches/threading calculations should be rebuildable from textual sources, which remain sacrosanct.
This is a common pattern in modern Cocoa programming, yes? "I need to have all of my data Spotlight-indexable, so everything in many parse-able files, but I need to have it quickly searchable, so SQLite database, so I guess both of the above. And then I guess the database changes a lot and is monolithic, so exclude that from Time Machine."
Look in your ~/Library:
- Address Book has AddressBook-v22.abcddb, a SQLite database, and Metadata/*.abcp, binary property list files.
- iCal has Calendar Cache, a SQLite database, and Account/.calendar/*.ics, vCalendar files.
- Mail has Envelope Index, a SQLite database, and Account/.imapmbox/*.emlx, RFC-2822 files with an XML footer.
Also, not in ~/Library:
- iPhoto has iPhotoMain.db, a SQLite database, and Metadata Backup/*.ipmeta, binary property list files.
The first two, of course, are automatically generated as Core Data persistent stores, but it's the same point.
-> jp
More information about the Email-init
mailing list