Thanks Chris. > Your idea to do it in the app server, as the author changes their master > record, is troubling because it can lead to race conditions. The changes > method, where a name-update is an asynchronous process, is more robust, > because you can know for sure that *eventually* the author's name will be > changed everywhere it appears. >
You told about more robust method, you mean run backend process listen _changes feed for Authors, and when changes come try update all contents related to author? If i get you right, i don't understand you >because you can know for sure that *eventually* the author's name will be >changed everywhere it appears. What you mean? > My method is to have a view of docs by author, and then query that view for > the old author's name, updating any docs that appear. This way if new writes > come in with the old name (due to there being out of date replicas of the > master record lingering, for instance) they will be eventually updated as > well. You could have a time-to-live of something like 5 minutes (or longer if > your system is giant) for the process which is running the query for > docs-that-say-Joe-but-should-say-Joseph and updating them. > Probably i don't get you: I track _changes feed, when change come you suggest query that view for the old author's name, but how i know old name, author doc all ready with newest name. Sorry for getting your time, to answer for stupid questions. 2010/4/9 J Chris Anderson <[email protected]>: > > On Apr 8, 2010, at 11:55 PM, faust 1111 wrote: > >> Yes i understand that listen _changes is better to get round race conditions. >> >> Cannot get your suggesting about >> how i can track that all contents related to author was updated not 5 >> of 50 but all. >> > > I think your question is valid. The answer is also simple. There is no way to > transactionally ensure that the author's name is updated everywhere it > appears. > > Your idea to do it in the app server, as the author changes their master > record, is troubling because it can lead to race conditions. The changes > method, where a name-update is an asynchronous process, is more robust, > because you can know for sure that *eventually* the author's name will be > changed everywhere it appears. > > It is probably best to make this clear through the UI with a message like: > "Your name has been changed in the master record. It could take a few minutes > for the change to appear throughout the site." > > In actuality, this is probably no different than in a relational database (as > in a relational database, you'd probably have a caching layer that takes a > few minutes to expire anyway.) > >> Thats ok. >> I don't understand if listen feed _chenges, feed give me info only >> about id & rev of changed doc, how i can get that author name is >> changed? >> > > My method is to have a view of docs by author, and then query that view for > the old author's name, updating any docs that appear. This way if new writes > come in with the old name (due to there being out of date replicas of the > master record lingering, for instance) they will be eventually updated as > well. You could have a time-to-live of something like 5 minutes (or longer if > your system is giant) for the process which is running the query for > docs-that-say-Joe-but-should-say-Joseph and updating them. > > _changes is just a convenient way to trigger that view query (so that you > aren't polling the view when nothing has happened in the database.) With > filtered changes, you can even be sure that you are only polling the view > when there will be something relevant to see. However, all this _changes > stuff is really just an optimization over brute force polling the view once > every N seconds, so you can add it later, when your app is big enough that > load starts to matter. > > Chris > >> >> 2010/4/9 Nicholas Orr <[email protected]>: >>> i don't think you are getting what the above people are suggesting... >>> >>> Go read up on the _changes API :) >>> >>> The basics are, every single change in the database is pushed into this >>> feed. All race conditions that are caused by your ruby way (via the filter) >>> are averted :) >>> >>> Nick >>> >>> On Fri, Apr 9, 2010 at 4:34 AM, faust 1111 <[email protected]> wrote: >>> >>>> i means >>>> when i do >>>> Content.by_author(self).each {|content| >>>> content.author_name = self.name; >>>> content.save(bulk=true) >>>> } >>>> >>>> i don't sure that all contents will updated may be only 5 and then >>>> process crushed. >>>> >>>> 2010/4/8 Andrew Melo <[email protected]>: >>>>> On Thu, Apr 8, 2010 at 12:53 PM, faust 1111 <[email protected]> wrote: >>>>>> What difference? >>>>>> if do >>>>>> Author >>>>>> after_save >>>>>> if name_changed? >>>>>> Content.by_author(self).each {|content| >>>>>> content.author_name = self.name; >>>>>> content.save(bulk=true) >>>>>> } >>>>>> >>>>>> or i start backend process to track Author _changes. >>>>>> >>>>>> This code not guarantee that all contents will updated. >>>>> >>>>> I don't get your question. You asked how to make sure that you could >>>>> change a number of documents consistently, we suggested that you watch >>>>> _changes to catch any silly race conditions. Then, you told us you >>>>> didn't need to use _changes, but you were worried that things would be >>>>> inconsistent. >>>>> >>>>> Even with your code above, you get a race condition (if I understand >>>>> your ruby right, I don't know ruby much at all). Something could >>>>> happen between when you check to see if a document needs to be changed >>>>> and the actual change occurs. Then, you're gonna get a conflict and >>>>> have to write up the logic to handle that intelligently. >>>>> >>>>> best, >>>>> Andrew >>>>> >>>>> >>>>>> >>>>>> 2010/4/8 Andrew Melo <[email protected]>: >>>>>>> On Thu, Apr 8, 2010 at 12:29 PM, faust 1111 <[email protected]> >>>> wrote: >>>>>>>> I can catch changes in my app before save author, may be backend >>>>>>>> process is surplus in my case. >>>>>>>> i need consistent, when i update author name i must know that all >>>>>>>> contents with author was updated success. >>>>>>> >>>>>>> Then their suggestion of watching _changes works for you. Start >>>>>>> watching _changes. Make all your changes to the documents' authors. >>>>>>> Any changes that come through on _changes, make sure they have the >>>>>>> proper author. Keep watching _changes until you're sure that nobody >>>>>>> has stale data they're waiting submit. >>>>>>> >>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> 2010/4/8 Zachary Zolton <[email protected]>: >>>>>>>>> I suggest you check out the _changes API: >>>>>>>>> http://books.couchdb.org/relax/reference/change-notifications >>>>>>>>> >>>>>>>>> Basically, if you have doc types A & B, where B maintains a denormed >>>>>>>>> bit of A, then you can watch the _changes feed in a backend process. >>>>>>>>> When an A gets updated, hit a view of all B's related to that >>>>>>>>> particular A, and update the dernomed data. >>>>>>>>> >>>>>>>>> On Thu, Apr 8, 2010 at 10:20 AM, faust 1111 <[email protected]> >>>> wrote: >>>>>>>>>> Hi guy's >>>>>>>>>> I return back to my problem with denormalization. >>>>>>>>>> >>>>>>>>>> is it possible to keep consistent when apply denormalization? >>>>>>>>>> For example >>>>>>>>>> Content >>>>>>>>>> have author (we store author name and id in Content) >>>>>>>>>> >>>>>>>>>> When author name changed(that's happens not frequently) >>>>>>>>>> i need find all content belong to this author and update author name >>>>>>>>>> but what if this operation not finished (not all docs was updated) >>>>>>>>>> >>>>>>>>>> What i can do in this case? >>>>>>>>>> Thanks. >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> -- >>>>>>> Andrew Melo >>>>>>> >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> -- >>>>> Andrew Melo >>>>> >>>> >>> > >
