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 <milu71@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
>>
|