Very excellent. Thank you!
On Fri, Nov 5, 2010 at 1:40 PM, Mark J. Reed <[email protected]> wrote: > Look at update handlers. > > On Fri, Nov 5, 2010 at 12: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 >> > > > > -- > Mark J. Reed <[email protected]> >
