On Fri, Apr 9, 2010 at 1:44 PM, faust 1111 <[email protected]> wrote: > 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.
When you spawn the background process, you'll have to pass it that information somehow. > > 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 >>>>>> >>>>> >>>> >> >> > -- -- Andrew Melo
