Along the lines of my post in Troubleshooting about the crash and lost document, I would suggest some sort of document recovery feature be added to DEVONThink, so that internally created documents are not so drastically vulnerable to data loss as imported ones are.
-Casey Koons
I haven’t had any problems with DT crashing, but it would be a good idea to have backup files of every document open for editing (like editors such as vi do).
This would entail creating a backup file every time a Plain Text or Rich Text document is opened/viewed, and deleting it when the document/window is closed.
Not sure how all of this file creation/deletion would effect performance though.
I don’t see a reason for automatically creating backups until selected/opened documents are modified.
About the same as manually duplicating documents is now (with the DT 1.x architecture), assuming backups are only triggered by modification. Larger documents would obviously take longer.
And if Core Data were somehow used as a backup/undo handler then performance wouldn’t necessarily be a file creation/deletion issue. I’m not privy to any DT 2.x database re-architecture details beyond what’s been briefly mentioned on this forum, which may include eliminating the monolithic proprietary 1.x DEVONthink-*.database files and simplify adding Spotlight support. So maybe any thought of DT 2.x using Core Data is nothing more than my feeble attempt to consider it from a less file-centric perspective.
Well, we would still have the monolithic *.database files as this is where DEVONthink holds the index data. These files would be smaller, but nothing more.
If we’d move to Core Data, we’d eliminate all AI functionality at the same time as these functions are part of the data structure. Also, Core Data is not searchable by Spotlight as Spotlight is, even if most people don’t recognize it, a FILE SEARCH. So, even if we’d use Core Data we would need to keep at least proxy files for Spotlight.
Eric.
Thanks for the clarification. I realized that speculating they’d be eliminated might be incorrect since there obviously needs to be some storage for index data.
Not sure I understand that structural dependency. Is there some limitation with Core Data that can’t support it?
If Core Data were somehow used while most DT 2.x content is being stored as individual files (instead of how it’s currently encapsulated in 1.x *.database files) you’d need about twice as many files – for content and associated Spotlight proxies (similar to the redundancy of using IMAP with maildir storage and Mail as a client on the same host). And it sounds like Core Data is incapable or undesirable for encapsulating DT content as a replacement for existing 1.x *.database files, making regular files a better candidate for content storage in the 2.x architecture.
Yes, our index actually IS the AI itself. Core Data is a regular database, not an AI-based structure.
Eric.
I’ll take your word for it since I don’t understand much about database design. 
Part of my wondering about using Core Data was the possibility of “automatically” gaining certain features currently missing in DT 1.x (like Undo/Redo) that might even help address Casey’s original concern about document recovery. But obviously you’re not going to abandon DT’s superior specialized AI architecture just for some Core Data benefits.