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 <[email protected]> wrote: > On Fri, Nov 5, 2010 at 5:44 PM, Michael <[email protected]> wrote: > > On Fri, Nov 5, 2010 at 12:03 PM, Paul Davis <[email protected]> > 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 >
