You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@couchdb.apache.org by faust 1111 <fa...@gmail.com> on 2010/04/08 17:20:44 UTC
About denormalization and keep consistent
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.
Re: About denormalization and keep consistent
Posted by Simon Metson <si...@googlemail.com>.
Hi,
What about turning the problem on it's head. It sounds like a
document can have one author and the author can have one name. What
about storing the _id of the author doc in each document they write/
own then use a view that emits the document _id and the author _id.
Querying that with include_docs=true will pull in both documents (if I
understand http://blog.couch.io/post/446015664/whats-new-in-apache-couchdb-0-11-part-two-views
correctly) so you'd see the document the author wrote and the author
document. That means if the authors name changes you have one place
(one document) to update, which is trivial.
Of course, the above breaks if the author actually changes (a new
name because the author _id has changed) but you already have a
solution for that problem with _changes et. al. ;) If changing a
document author is global (e.g. all docs authored by Joe are all now
authored by Fred) the above should work, you could even have a view
that emits doc id by author that you query with ?key and have your
external process reduce to zero, you could even take that view result
and push a bulk update (though that might not be ideal if a document
is large...).
Cheers
Simon
On 10 Apr 2010, at 00:56, faust 1111 wrote:
> In my case
> change of author name is exceptional situation.
> its happen rarely.
>
>
> I think i can do like this:
> when author change name
> i create doc mark that i begin update all related contents
> then try update
> then remove mark
>
> if update is fail(mark not reomve), i will know about and can
> continue.
>
> And i think i don't need run backend process listen
> _changes feed i can catch changes in my app model Author.
>
>
> 2010/4/10 Michael Ludwig <mi...@gmx.de>:
>> Andrew Melo schrieb am 09.04.2010 um 15:04:59 (-0500)
>> [Re: About denormalization and keep consistent]:
>>
>>>> Are there scenarios where writing happens to an SQL server, from
>>>> where NoSQL replicas are fed and used to serve readers?
>>>
>>> Possibly. But, if you're writing to a single SQL master, then you
>>> lose
>>> two benefits of Couch: horizontally scalable writes and not having
>>> to
>>> be restricted by SQL's data model. You could do (for instance)
>>> single
>>> master writes and many-slave reads on a stock SQL server in that
>>> case.
>>
>> Thanks, Andrew. It appears Faust is concerned about data consistency
>> which is usually and easily ensured by suitable SQL data modeling.
>> That
>> does not happen to be the forte of a system designed for
>> scalability at
>> the expense of consistency.
>>
>> Faust, there are many places and cases where data can be copied and
>> held
>> redundantly in hundreds or thousands of places, and it simply doesn't
>> matter. Think email, for example. If you changed the name belonging
>> to
>> your email address to "Johann Faust", it wouldn't matter that there
>> are
>> mails with the older version of your name in the archive, and they
>> wouldn't have to be updated, and they even shouldn't be updated. That
>> seems to be an excellent use case for a system like CouchDB.
>>
>> If, on the other hand, you care about consistency in the way you
>> described, you might want to consider using a system that supports
>> you in guaranteeing such consistency.
>>
>> --
>> Michael Ludwig
>>
Re: About denormalization and keep consistent
Posted by faust 1111 <fa...@gmail.com>.
In my case
change of author name is exceptional situation.
its happen rarely.
I think i can do like this:
when author change name
i create doc mark that i begin update all related contents
then try update
then remove mark
if update is fail(mark not reomve), i will know about and can continue.
And i think i don't need run backend process listen
_changes feed i can catch changes in my app model Author.
2010/4/10 Michael Ludwig <mi...@gmx.de>:
> Andrew Melo schrieb am 09.04.2010 um 15:04:59 (-0500)
> [Re: About denormalization and keep consistent]:
>
>> > Are there scenarios where writing happens to an SQL server, from
>> > where NoSQL replicas are fed and used to serve readers?
>>
>> Possibly. But, if you're writing to a single SQL master, then you lose
>> two benefits of Couch: horizontally scalable writes and not having to
>> be restricted by SQL's data model. You could do (for instance) single
>> master writes and many-slave reads on a stock SQL server in that case.
>
> Thanks, Andrew. It appears Faust is concerned about data consistency
> which is usually and easily ensured by suitable SQL data modeling. That
> does not happen to be the forte of a system designed for scalability at
> the expense of consistency.
>
> Faust, there are many places and cases where data can be copied and held
> redundantly in hundreds or thousands of places, and it simply doesn't
> matter. Think email, for example. If you changed the name belonging to
> your email address to "Johann Faust", it wouldn't matter that there are
> mails with the older version of your name in the archive, and they
> wouldn't have to be updated, and they even shouldn't be updated. That
> seems to be an excellent use case for a system like CouchDB.
>
> If, on the other hand, you care about consistency in the way you
> described, you might want to consider using a system that supports
> you in guaranteeing such consistency.
>
> --
> Michael Ludwig
>
Re: About denormalization and keep consistent
Posted by Michael Ludwig <mi...@gmx.de>.
Andrew Melo schrieb am 09.04.2010 um 15:04:59 (-0500)
[Re: About denormalization and keep consistent]:
> > Are there scenarios where writing happens to an SQL server, from
> > where NoSQL replicas are fed and used to serve readers?
>
> Possibly. But, if you're writing to a single SQL master, then you lose
> two benefits of Couch: horizontally scalable writes and not having to
> be restricted by SQL's data model. You could do (for instance) single
> master writes and many-slave reads on a stock SQL server in that case.
Thanks, Andrew. It appears Faust is concerned about data consistency
which is usually and easily ensured by suitable SQL data modeling. That
does not happen to be the forte of a system designed for scalability at
the expense of consistency.
Faust, there are many places and cases where data can be copied and held
redundantly in hundreds or thousands of places, and it simply doesn't
matter. Think email, for example. If you changed the name belonging to
your email address to "Johann Faust", it wouldn't matter that there are
mails with the older version of your name in the archive, and they
wouldn't have to be updated, and they even shouldn't be updated. That
seems to be an excellent use case for a system like CouchDB.
If, on the other hand, you care about consistency in the way you
described, you might want to consider using a system that supports
you in guaranteeing such consistency.
--
Michael Ludwig
Re: About denormalization and keep consistent
Posted by Andrew Melo <an...@gmail.com>.
On Fri, Apr 9, 2010 at 3:00 PM, Michael Ludwig <mi...@gmx.de> wrote:
> Andrew Melo schrieb am 09.04.2010 um 14:24:24 (-0500)
> [Re: About denormalization and keep consistent]:
>
>> On Fri, Apr 9, 2010 at 2:22 PM, faust 1111 <fa...@gmail.com> wrote:
>> >>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?
>>
>> You have to tell it somehow. You can either ninja together some sort
>> of way to do it through couch or do something out-of-band to notify
>> your daemon process of what work it needs to do.
>
> Brave New World of NoSQL :-)
>
> Faust, if you care about data consistency to the extent it appears from
> this thread, you should model your data so that consistency is easy, and
> doesn't require ninjaing together some sort of way to unleash an armada
> of hackery-hoo against inconsistency, which thrives on redundancy and is
> a dreadful enemy if given rope, as in NoSQL land.
>
> I'm new here. Are there scenarios where writing happens to an SQL
> server, from where NoSQL replicas are fed and used to serve readers?
Possibly. But, if you're writing to a single SQL master, then you lose
two benefits of Couch: horizontally scalable writes and not having to
be restricted by SQL's data model. You could do (for instance) single
master writes and many-slave reads on a stock SQL server in that case.
best,
Andrew
> --
> Michael Ludwig
>
--
--
Andrew Melo
Re: About denormalization and keep consistent
Posted by Michael Ludwig <mi...@gmx.de>.
Andrew Melo schrieb am 09.04.2010 um 14:24:24 (-0500)
[Re: About denormalization and keep consistent]:
> On Fri, Apr 9, 2010 at 2:22 PM, faust 1111 <fa...@gmail.com> wrote:
> >>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?
>
> You have to tell it somehow. You can either ninja together some sort
> of way to do it through couch or do something out-of-band to notify
> your daemon process of what work it needs to do.
Brave New World of NoSQL :-)
Faust, if you care about data consistency to the extent it appears from
this thread, you should model your data so that consistency is easy, and
doesn't require ninjaing together some sort of way to unleash an armada
of hackery-hoo against inconsistency, which thrives on redundancy and is
a dreadful enemy if given rope, as in NoSQL land.
I'm new here. Are there scenarios where writing happens to an SQL
server, from where NoSQL replicas are fed and used to serve readers?
--
Michael Ludwig
Re: About denormalization and keep consistent
Posted by Andrew Melo <an...@gmail.com>.
On Fri, Apr 9, 2010 at 2:22 PM, faust 1111 <fa...@gmail.com> wrote:
>>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?
You have to tell it somehow. You can either ninja together some sort
of way to do it through couch or do something out-of-band to notify
your daemon process of what work it needs to do.
best,
Andrew
>
>
> 2010/4/9 J Chris Anderson <jc...@gmail.com>:
>>
>> 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 <jc...@gmail.com>:
>>>>
>>>> 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 <ni...@zxgen.net>:
>>>>>> 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 <fa...@gmail.com> 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 <an...@gmail.com>:
>>>>>>>> On Thu, Apr 8, 2010 at 12:53 PM, faust 1111 <fa...@gmail.com> 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 <an...@gmail.com>:
>>>>>>>>>> On Thu, Apr 8, 2010 at 12:29 PM, faust 1111 <fa...@gmail.com>
>>>>>>> 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 <za...@gmail.com>:
>>>>>>>>>>>> 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 <fa...@gmail.com>
>>>>>>> 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
Re: About denormalization and keep consistent
Posted by faust 1111 <fa...@gmail.com>.
>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 <jc...@gmail.com>:
>
> 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 <jc...@gmail.com>:
>>>
>>> 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 <ni...@zxgen.net>:
>>>>> 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 <fa...@gmail.com> 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 <an...@gmail.com>:
>>>>>>> On Thu, Apr 8, 2010 at 12:53 PM, faust 1111 <fa...@gmail.com> 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 <an...@gmail.com>:
>>>>>>>>> On Thu, Apr 8, 2010 at 12:29 PM, faust 1111 <fa...@gmail.com>
>>>>>> 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 <za...@gmail.com>:
>>>>>>>>>>> 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 <fa...@gmail.com>
>>>>>> 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
>>>>>>>
>>>>>>
>>>>>
>>>
>>>
>
>
Re: About denormalization and keep consistent
Posted by J Chris Anderson <jc...@gmail.com>.
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 <jc...@gmail.com>:
>>
>> 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 <ni...@zxgen.net>:
>>>> 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 <fa...@gmail.com> 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 <an...@gmail.com>:
>>>>>> On Thu, Apr 8, 2010 at 12:53 PM, faust 1111 <fa...@gmail.com> 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 <an...@gmail.com>:
>>>>>>>> On Thu, Apr 8, 2010 at 12:29 PM, faust 1111 <fa...@gmail.com>
>>>>> 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 <za...@gmail.com>:
>>>>>>>>>> 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 <fa...@gmail.com>
>>>>> 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
>>>>>>
>>>>>
>>>>
>>
>>
Re: About denormalization and keep consistent
Posted by Andrew Melo <an...@gmail.com>.
On Fri, Apr 9, 2010 at 1:44 PM, faust 1111 <fa...@gmail.com> 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 <jc...@gmail.com>:
>>
>> 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 <ni...@zxgen.net>:
>>>> 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 <fa...@gmail.com> 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 <an...@gmail.com>:
>>>>>> On Thu, Apr 8, 2010 at 12:53 PM, faust 1111 <fa...@gmail.com> 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 <an...@gmail.com>:
>>>>>>>> On Thu, Apr 8, 2010 at 12:29 PM, faust 1111 <fa...@gmail.com>
>>>>> 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 <za...@gmail.com>:
>>>>>>>>>> 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 <fa...@gmail.com>
>>>>> 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
Re: About denormalization and keep consistent
Posted by faust 1111 <fa...@gmail.com>.
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 <jc...@gmail.com>:
>
> 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 <ni...@zxgen.net>:
>>> 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 <fa...@gmail.com> 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 <an...@gmail.com>:
>>>>> On Thu, Apr 8, 2010 at 12:53 PM, faust 1111 <fa...@gmail.com> 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 <an...@gmail.com>:
>>>>>>> On Thu, Apr 8, 2010 at 12:29 PM, faust 1111 <fa...@gmail.com>
>>>> 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 <za...@gmail.com>:
>>>>>>>>> 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 <fa...@gmail.com>
>>>> 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
>>>>>
>>>>
>>>
>
>
Re: About denormalization and keep consistent
Posted by J Chris Anderson <jc...@gmail.com>.
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 <ni...@zxgen.net>:
>> 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 <fa...@gmail.com> 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 <an...@gmail.com>:
>>>> On Thu, Apr 8, 2010 at 12:53 PM, faust 1111 <fa...@gmail.com> 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 <an...@gmail.com>:
>>>>>> On Thu, Apr 8, 2010 at 12:29 PM, faust 1111 <fa...@gmail.com>
>>> 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 <za...@gmail.com>:
>>>>>>>> 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 <fa...@gmail.com>
>>> 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
>>>>
>>>
>>
Re: About denormalization and keep consistent
Posted by faust 1111 <fa...@gmail.com>.
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.
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?
2010/4/9 Nicholas Orr <ni...@zxgen.net>:
> 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 <fa...@gmail.com> 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 <an...@gmail.com>:
>> > On Thu, Apr 8, 2010 at 12:53 PM, faust 1111 <fa...@gmail.com> 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 <an...@gmail.com>:
>> >>> On Thu, Apr 8, 2010 at 12:29 PM, faust 1111 <fa...@gmail.com>
>> 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 <za...@gmail.com>:
>> >>>>> 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 <fa...@gmail.com>
>> 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
>> >
>>
>
Re: About denormalization and keep consistent
Posted by Nicholas Orr <ni...@zxgen.net>.
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 <fa...@gmail.com> 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 <an...@gmail.com>:
> > On Thu, Apr 8, 2010 at 12:53 PM, faust 1111 <fa...@gmail.com> 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 <an...@gmail.com>:
> >>> On Thu, Apr 8, 2010 at 12:29 PM, faust 1111 <fa...@gmail.com>
> 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 <za...@gmail.com>:
> >>>>> 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 <fa...@gmail.com>
> 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
> >
>
Re: About denormalization and keep consistent
Posted by faust 1111 <fa...@gmail.com>.
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 <an...@gmail.com>:
> On Thu, Apr 8, 2010 at 12:53 PM, faust 1111 <fa...@gmail.com> 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 <an...@gmail.com>:
>>> On Thu, Apr 8, 2010 at 12:29 PM, faust 1111 <fa...@gmail.com> 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 <za...@gmail.com>:
>>>>> 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 <fa...@gmail.com> 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
>
Re: About denormalization and keep consistent
Posted by Andrew Melo <an...@gmail.com>.
On Thu, Apr 8, 2010 at 12:53 PM, faust 1111 <fa...@gmail.com> 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 <an...@gmail.com>:
>> On Thu, Apr 8, 2010 at 12:29 PM, faust 1111 <fa...@gmail.com> 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 <za...@gmail.com>:
>>>> 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 <fa...@gmail.com> 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
Re: About denormalization and keep consistent
Posted by faust 1111 <fa...@gmail.com>.
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.
2010/4/8 Andrew Melo <an...@gmail.com>:
> On Thu, Apr 8, 2010 at 12:29 PM, faust 1111 <fa...@gmail.com> 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 <za...@gmail.com>:
>>> 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 <fa...@gmail.com> 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
>
Re: About denormalization and keep consistent
Posted by Andrew Melo <an...@gmail.com>.
On Thu, Apr 8, 2010 at 12:29 PM, faust 1111 <fa...@gmail.com> 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 <za...@gmail.com>:
>> 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 <fa...@gmail.com> 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
Re: About denormalization and keep consistent
Posted by faust 1111 <fa...@gmail.com>.
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.
2010/4/8 Zachary Zolton <za...@gmail.com>:
> 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 <fa...@gmail.com> 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.
>>
>
Re: About denormalization and keep consistent
Posted by Zachary Zolton <za...@gmail.com>.
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 <fa...@gmail.com> 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.
>