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
