incubator-couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ido Ran <ido....@gmail.com>
Subject Re: Write race conditions, working without _rev
Date Sun, 07 Nov 2010 09:14:28 GMT
Hi,
I think this question raise the general question of "document model" (in the
same way OO programming has Object Model) and that is "how do you model you
document to contain you problem domain including the process of changing
those documents".

In relation databases we use table diagram and description of transactions
to describe it I think we need tools (not has to be software, pen and papare
are great too) to describe out document oriented database.
The question of should you have one document that get updated or several
documents which relate using other means is a good question.

Ido

On Sun, Nov 7, 2010 at 9:15 AM, Benoit Chesneau <bchesneau@gmail.com> wrote:

> On Fri, Nov 5, 2010 at 5:44 PM, Michael <newmaniese@gmail.com> wrote:
> > On Fri, Nov 5, 2010 at 12:03 PM, Paul Davis <paul.joseph.davis@gmail.com>
> wrote:
> >>
> >> In the second case, the second person to write the document wins,
> >> erasing any changes the first write's effects. The first writer will
> >> then be in a state where his view of the database will be
> >> inconsistent. The thing his, he can't know because without requiring a
> >> _rev token he'll never get a notification of any sort of error.
> >
> > True, that is one workflow. I am not too concerned however about
> > updates trampling each other each update does not care about previous
> > revisions. This isn't people updating objects, but applications  To be
> > honest, I will catch the conflict and just ignore it because the data
> > then is "new enough", however if I wanted the newest data, I would
> > have to have:
> >
> > Read object to get rev
> > Try save
> > if resource conflict:
> >    read object for rev again
> >    try save
> >    if resource conflict:
> >        assume newer data and pass
> >
> > If that happens, I have 4 different hits to the database for nothing.
> > On a multithreaded server, this would happen quite frequently.
> >
> > In my workflow, the ideal situation would be to write once, without a
> > read, and for Couch to just accept the change in order.
> >
> > Is that possible?
> >
> > Thanks,
> >
> > Michael
> >
>
>  Just use one document per transaction. Then a view to retrieve the
> last one 'more recent in your case?).
>
> - benoƮt
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message