Using _rev in application logic

[Moritz Post <mo...@gmail.com>]

Hi CouchDB people

I am currently playing with the couchdb and pretty impressed by several of
the feature on offer. Great job so far. While reading up on various web
resources i have come to conclude that it is discouraged to use the _rev
field for application related logic since the revisions are removed when
compacting and they are not replicated when using replication.

Looking at my possible usecase however, i would very much like to use the
_rev key to track changes in my document. So here are several questions
regarding that topic:

1. Is it generally discouraged to use the _rev in application logic?
2. Is compacting something i would like to do for other reasons than to
remove older revisions (so i could basically not do it)
2. Is it possible to somehow also replicate the revision while replicating?
3. Is it good practice to use the _rev field in views?

Any other clarifications in regards to _rev are also welcome.

Thanks in advance and keep up the good work

Greets
Moritz

Re: Using _rev in application logic

[Jan Lehnardt <ja...@apache.org>]

Hi Moritz,

On 1 Apr 2010, at 14:32, Moritz Post wrote:

> Hi CouchDB people
> 
> I am currently playing with the couchdb and pretty impressed by several of
> the feature on offer. Great job so far. While reading up on various web
> resources i have come to conclude that it is discouraged to use the _rev
> field for application related logic since the revisions are removed when
> compacting and they are not replicated when using replication.
> 
> Looking at my possible usecase however, i would very much like to use the
> _rev key to track changes in my document. So here are several questions
> regarding that topic:
> 
> 1. Is it generally discouraged to use the _rev in application logic?

Yes, you should not rely on old revisions to be around in your app. Your
app will fail in unexpected ways and perceive data-loss if you rely on
revisions being around forever.

> 2. Is compacting something i would like to do for other reasons than to
> remove older revisions (so i could basically not do it)

CouchDB's b-tree store is sparse, unless you make very few very large bulk
doc inserts, you will waste a lot of space. Not running compaction is considered
"doing it wrong".


> 2. Is it possible to somehow also replicate the revision while replicating?

This is another reason for not using revisions in applications.


> 3. Is it good practice to use the _rev field in views?

Views can only always see the latest revision of a document. You can't even
access previous revisions.


> Any other clarifications in regards to _rev are also welcome.

We encourage this workflow:

1. Load a document,
2. make a copy,
3. change the document to reflect your changes,
4. attach the copy to the new changed document,
5. save back to CouchDB.


> Thanks in advance and keep up the good work

Welcome and thanks, keep the questions coming :)

Cheers
Jan
--

Re: Using _rev in application logic

[J Chris Anderson <jc...@gmail.com>]

On Apr 1, 2010, at 9:17 AM, Moritz Post wrote:

> Hi Guys
> 
> Thanks for clarifying the situation with the _rev field and pointing out
> alternative solutions. Your mentioned issues sound valid to me.
> 

It can also make sense to take the loaded version of the document and attach it as a binary attachment with the next edit

that keeps the JSON doc from growing without bound (and keeps old versions out of views, but replicating with the current version)

Chris

> Until the next questions...  :)
> 
> Regards
> Moritz
> 
> On Thu, Apr 1, 2010 at 3:59 PM, Alan Boyce <al...@alanboyce.com> wrote:
> 
>> Hi Moritz
>> 
>> I wouldn't use _rev, see Jan's response. I would use update handlers.
>> See here:
>> 
>> 
>> http://wiki.apache.org/couchdb/How_to_intercept_document_updates_and_perform_additional_server-side_processing
>> 
>> So you could create a revision in the document on update.
>> 
>> {
>> title: "I'm a document",
>> body: "This couchdb stuff is cool."
>> revisions: [{title: "I'm a document", body:"this couchdb stuff is
>> cool."}],
>> update_note: "fixed capitalization of 'this' in body"
>> }
>> 
>> best,
>> alan
>> 
>> 
>> On Thu, 2010-04-01 at 14:32 +0200, Moritz Post wrote:
>>> Hi CouchDB people
>>> 
>>> I am currently playing with the couchdb and pretty impressed by several
>> of
>>> the feature on offer. Great job so far. While reading up on various web
>>> resources i have come to conclude that it is discouraged to use the _rev
>>> field for application related logic since the revisions are removed when
>>> compacting and they are not replicated when using replication.
>>> 
>>> Looking at my possible usecase however, i would very much like to use the
>>> _rev key to track changes in my document. So here are several questions
>>> regarding that topic:
>>> 
>>> 1. Is it generally discouraged to use the _rev in application logic?
>>> 2. Is compacting something i would like to do for other reasons than to
>>> remove older revisions (so i could basically not do it)
>>> 2. Is it possible to somehow also replicate the revision while
>> replicating?
>>> 3. Is it good practice to use the _rev field in views?
>>> 
>>> Any other clarifications in regards to _rev are also welcome.
>>> 
>>> Thanks in advance and keep up the good work
>>> 
>>> Greets
>>> Moritz
>> 
>> 
>> 

Re: Using _rev in application logic

[Moritz Post <mo...@gmail.com>]

Hi Guys

Thanks for clarifying the situation with the _rev field and pointing out
alternative solutions. Your mentioned issues sound valid to me.

Until the next questions...  :)

Regards
Moritz

On Thu, Apr 1, 2010 at 3:59 PM, Alan Boyce <al...@alanboyce.com> wrote:

> Hi Moritz
>
> I wouldn't use _rev, see Jan's response. I would use update handlers.
> See here:
>
>
> http://wiki.apache.org/couchdb/How_to_intercept_document_updates_and_perform_additional_server-side_processing
>
> So you could create a revision in the document on update.
>
> {
> title: "I'm a document",
> body: "This couchdb stuff is cool."
> revisions: [{title: "I'm a document", body:"this couchdb stuff is
> cool."}],
> update_note: "fixed capitalization of 'this' in body"
> }
>
> best,
> alan
>
>
> On Thu, 2010-04-01 at 14:32 +0200, Moritz Post wrote:
> > Hi CouchDB people
> >
> > I am currently playing with the couchdb and pretty impressed by several
> of
> > the feature on offer. Great job so far. While reading up on various web
> > resources i have come to conclude that it is discouraged to use the _rev
> > field for application related logic since the revisions are removed when
> > compacting and they are not replicated when using replication.
> >
> > Looking at my possible usecase however, i would very much like to use the
> > _rev key to track changes in my document. So here are several questions
> > regarding that topic:
> >
> > 1. Is it generally discouraged to use the _rev in application logic?
> > 2. Is compacting something i would like to do for other reasons than to
> > remove older revisions (so i could basically not do it)
> > 2. Is it possible to somehow also replicate the revision while
> replicating?
> > 3. Is it good practice to use the _rev field in views?
> >
> > Any other clarifications in regards to _rev are also welcome.
> >
> > Thanks in advance and keep up the good work
> >
> > Greets
> > Moritz
>
>
>

Re: Using _rev in application logic

[Alan Boyce <al...@alanboyce.com>]

Hi Moritz

I wouldn't use _rev, see Jan's response. I would use update handlers.
See here:

http://wiki.apache.org/couchdb/How_to_intercept_document_updates_and_perform_additional_server-side_processing

So you could create a revision in the document on update.

{
title: "I'm a document",
body: "This couchdb stuff is cool."
revisions: [{title: "I'm a document", body:"this couchdb stuff is
cool."}],
update_note: "fixed capitalization of 'this' in body"
}

best,
alan


On Thu, 2010-04-01 at 14:32 +0200, Moritz Post wrote:
> Hi CouchDB people
> 
> I am currently playing with the couchdb and pretty impressed by several of
> the feature on offer. Great job so far. While reading up on various web
> resources i have come to conclude that it is discouraged to use the _rev
> field for application related logic since the revisions are removed when
> compacting and they are not replicated when using replication.
> 
> Looking at my possible usecase however, i would very much like to use the
> _rev key to track changes in my document. So here are several questions
> regarding that topic:
> 
> 1. Is it generally discouraged to use the _rev in application logic?
> 2. Is compacting something i would like to do for other reasons than to
> remove older revisions (so i could basically not do it)
> 2. Is it possible to somehow also replicate the revision while replicating?
> 3. Is it good practice to use the _rev field in views?
> 
> Any other clarifications in regards to _rev are also welcome.
> 
> Thanks in advance and keep up the good work
> 
> Greets
> Moritz