On Sun, Mar 8, 2009 at 3:35 AM, Ben Hood <[email protected]> wrote: > Chris, > > On Sun, Mar 8, 2009 at 3:30 AM, Chris Anderson <[email protected]> wrote: >> CouchDB does not do document versioning. Because of it's append-only >> files, the storage model will allow access to snapshots of the >> database at each seq num. The file driver needs a little work to close >> the gap, but once the code is written, you'll be able to roll back to >> point in time snapshots of the database (as long as you don't compact, >> which means storage is unbounded.) > > Cool. Does this mean that you guys this in the pipeline or is just > something that you think would be doable?
I probably should be more coy about this sort of thing on the user list. ;) The functionality is not and never will be appropriate for building a version control system. This planned feature is merely meant to make the database file more resilient, and make it so that the hard drive head never has to seek for writes. A consequence of the fact that the file is never modified, only appended to, is that it contains a full history of all updates (until compaction). There are 2 reasons you can't use this in an application. One is that you're better off assuming your application can't control compaction. The second is that you have to think this way if you'll be dealing with replicated data. If you have edits on dbB and you replicate them to dbA, dbA only see the edits that dbB would still contain if it were replicated. > >> The solution is to store each document version as a different CouchDB >> document. Jan is building an example wiki these days. > > Do you mean to say that it is more effective to version on a document > level rather than snapshotting the underlying storage? If you are building a versioning application, your application needs to do the versioning. The patterns for this are straightforward. I'm sure Jan will post a link to his wiki when it's ready. Chris -- Chris Anderson http://jchris.mfdz.com
