And what today's revision system help in such a case ?
2009/2/8 Paul Davis <paul.joseph.da...@gmail.com> > On Sun, Feb 8, 2009 at 11:50 AM, Patrick Antivackis > <patrick.antivac...@gmail.com> wrote: > > I'm not sure I understood what you asked. > > > > It would be a conflict of document, that would need either manual > correction > > or why not an automatic correction applying a move to one of the > document, > > but at least couch can tell for sure it was not the same document at the > > origin. > > > > What I not understand is what today's revision system or proposed > revision > > system will bring more for this kind of conflict with two different > > documents are created with same Id on two different nodes ? Except that > with > > the new revision proposal, you don't know for sure it was same or > different > > document at the origin if replications occurs after you trimmed the > > reference to the first revision. > > > > I'm saying that your suggestion to always retain the first revision is > going to run into problems when a document is created on two machines > and thus has to initial revisions. Or rather, it will run into the > same problems as Damien's proposal yet have the added complexity that > we now have the special cased 'first revisions' info. > > Unless of course I'm missing something else in the details. > > > > > > > > > 2009/2/8 Paul Davis <paul.joseph.da...@gmail.com> > > > >> On Sun, Feb 8, 2009 at 6:07 AM, Patrick Antivackis > >> <patrick.antivac...@gmail.com> wrote: > >> > 2009/2/8 Damien Katz <dam...@apache.org> > >> > > >> >> You got everything right except this. It doesn't solve the problem, > >> because > >> >> on another node, I could have a document that looked like ["1-foo" > >> "2-bif"]. > >> >> That is a real edit conflict that wouldn't be caught by what I think > you > >> are > >> >> proposing. > >> >> > >> > > >> > That's right, there is a real edit conflict, but at least couchdb can > >> > detect it based on the first revision reference that is always kept. > >> > If you not keep the reference of the first revision you can arrive to > : > >> > BaseA : ["1-foo"] > >> > BaseB : empty > >> > Replication : > >> > BaseA : ["1-foo"] > >> > BaseB : ["1-foo"] > >> > Life goes on : > >> > BaseA : ["1-foo" "2-bar" "3-baz" "4-biz"] but as it's trimmed to 3 you > >> only > >> > keep ["2-bar" "3-baz" "4-biz"] > >> > BaseB : ["1-foo" "2-bad" "3-baf" "4-bif"] but as it's trimmed to 3 you > >> only > >> > keep ["2-bad" "3-baf" "4-bif"] > >> > New replication : > >> > ????? same Id but no common revision, what we do ? And couch can not > even > >> > help to say if it was same doc or not at the origin. > >> > > >> > >> Patrick, > >> > >> I'm pretty sure i see where you're coming from, but can you explain > >> what would happen if the same document ID were created on two servers? > >> Each server would have a different 'first rev' so who's first rev > >> would be carried on in the future? > >> > >> > This is used during conflict detection to figure out if 2 tree > fragments > >> >> overlap. We don't actually store a sequential number for each > revision, > >> we > >> >> store a revision tree of numbers, with the root of the tree being the > >> offset > >> >> from 0 where it was trimmed (technically it's stemmed). > >> >> > >> > > >> > You are right, keep trace of the numbrer of the revision is indeed > >> important > >> > especially when a same origin document in updated on different > nodes.But > >> > couldn't it be replace bu a timestamp, this is sequential too and give > >> even > >> > more information. > >> > > >> > > >> >> Sometimes people can deal with spurious conflicts. This gives you the > >> >> option. If you don't want spurious conflicts, don't use this feature. > >> >> > >> >> And if you want the same document to be editted over and over, 100s > of > >> >> thousands of times, this is really the only option. The revision > history > >> >> will get too big and slow down updates tremendously. > >> >> > >> >> Sure but I would say it's different use cases. Record management for > >> > examples needs to keep track of changes during a period of time. And > in > >> all > >> > CMS/ECM i have worked on, clean up of version is done on time base > more > >> than > >> > on number of revision having occured. > >> > > >> > >> HTH, > >> Paul Davis > >> > > >
