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 <[email protected]>:
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
