I think update handlers don't help drop _rev dependency in all cases. update handlers is not in-place update stuff. if send two requests to one update handler together, you will catch Conflict.
2010/11/6 Michael <[email protected]> > 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]> > > >
