incubator-couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rune Skou Larsen <...@trifork.com>
Subject Re: History Proposal
Date Mon, 03 Aug 2009 16:26:48 GMT
Damien Katz skrev:
>>>> 2009/7/31 Jason Davies <jason@jasondavies.com>:
>>>> 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.
>>>>         
> Some comments about the proposal
>
> 1.  The callbacks must be synchronous. Queueing them for writing later  
> means the queue can get overloaded and changes lost.
> 2 Changes can still get lost. We don't have commits across dbs, so  
> it's possible a crash during update will put the main and history dbs  
> out of sync.
> 3. Replicated changes get lost. If a client makes 5 edits to local  
> replica of a document, then replicates it to a server db, only the  
> most recent change get recorded in the history.
>
> I would prefer to store the history as attachments to the main document.
>
> -Damien
>   
I agree that _all versions of a document should be in the same database_
because commit-scope of a change should include saving the undo-history.
What good is unreliable undo?

But also for other reasons:
1) Future versions
In my company, we need a system, where we can replicate data to all
couchdb-instances before it should be used. This is also very common in
the CMS-world for scheduling a change to the website. So we need to to
be able to store a future version, which becomes valid at a specified
time and make the "invisible" change between versions (we use a url
rewrite). Thats very tough if current data and history data are in
separate databases and in different formats.

2) Applying views
View'ing on historic docs should be as powerful as viewing "current"
docs. With the proposed format for historic documents, the same view
cannot be applied on current and history db. In fact, complex views
can't  be used at all in the history db, since the one-dimensional
view-index must include time.

I dream of a fully temporal couchdb, where all GET requests can include
the point in time for which I want to see the docs through my views,
lists and shows  :-)

Using attachments is not optimal, because there's still the "un-dynamic"
distinction between past, current and future, but its much better than a
seperate db. The attachments-proposal retains the possibility to
manipulate versions of the same doc in one commit-scope.

- Rune

Mime
View raw message