>Author changes their profile document. >Something listening to the _changes feed notices this.
>It starts a process querying for docs that have the old author profile, and >fixing those docs. Eventually all the >docs have been updated. Then its work >is done. But how >Something listening to the _changes feed notices this. know about old author name? 2010/4/9 J Chris Anderson <[email protected]>: > > On Apr 9, 2010, at 11:44 AM, faust 1111 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? >> > > the basic pattern is: > > Author changes their profile document. > > Something listening to the _changes feed notices this. > > It starts a process querying for docs that have the old author profile, and > fixing those docs. Eventually all the docs have been updated. Then its work > is done. > > The only complication is, maybe a write with the old (stale) author profile > comes in much later (for some reason) so maybe you want to recheck any of > those background processes that you spawned, again an hour after they > complete. or something. with a small site you don't have to worry about this > but if you are operating at web scale it will start to matter. > >> >>> 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 >>>>>>> >>>>>> >>>>> >>> >>> > >
