On 31 Jul 2009, at 15:42, Benoit Chesneau wrote:
2009/7/31 Jason Davies <[email protected]>:
The main points of this proposal are:
1. Store the historical versions of documents in a separate
database. This
is for a number of reasons: a) keeping it separate means we don't
clog up
the main database with historical data b) history-specific views
can be kept
here c) non-intrusive implementation of this is easier.
2. The change will be made at the couch_db layer so that *any*
change to any
document in the target database will be mirrored to the history
database.
seem good.
3. Each and every change to a document will result in a new
document being
created in the history database (with a new ID) containing an exact
copy of
that document e.g. {_id: <new ID>, doc: <exact copy of doc> }.
How would you handle case of attachements ? If attachements are copied
for each revision of a doc, it would take a lot of place. Maybe
storing attachements in their own doc could be solution though. So
storing a revision would be
store attachements in differents docs
create a doc {_id: <id>, doc: <doc>, attachments: [<id1>, ...]}
attachements will be tests across revisions depending of their
signature
if signature change, a new atatchment doc is created.
Just a thought anyway.
we also could make the storage layer smart enough to store attachments
with the same hash only once in the db file. (I have no idea how hard or
feasible it is with the current code).
Cheers
Jan
--
4. Adding meta-data to changes can be handled by a custom _update
handler
(yet to be developed) to set fields such as "last_modified" and
"last_modified_user".
why not adding date metadata when storing revision . The obvious one I
mean userCtx, and date?
One use case we'd like to support is effectively (from the point of
the
user) being able to "roll back" a view to a specific point in time,
but how
this would look in the history database has me stumped so far.
Rolling back
a specific doc is easy, but multiple docs, not so easy it seems. Any
suggestions welcome!
rolling back could be handled on a view based on date in history
database ?
- benoit
