Updating documents for a change in application model

[Benjamin Eberlei <ko...@beberlei.de>]

Hello,

i have searched the net for a while now and haven't found a good resource on how to handle large scale refactorings in the application model with a CouchDB backend.

So far I thought about using one of the following two different approaches:

1. Eventually migrate the data when it comes "into memory" by saving a version field for example. This however does not work for refactorings that change keys in views. Also it leads to lots of IF version then else code in your model that is really ugly to maintain in the long-run.
2. Use _all_docs to iterate over all documents, detect the ones that need changes and do them. This can probably take a while if you have lots of documents and never trigger all_docs during the "normal" application lifetime.

The first approach may sound good at the beginning but i only see very few use-cases for it other than changing names of fields that are not part of a view key.

Can someone maybe share his experience with regard to point 2 or variations of point 2? Additionally, are there solutions for refactoring CouchDB documents I forgot?

greetings,
Benjamin

Re: Updating documents for a change in application model

[Ladislav Thon <la...@gmail.com>]

Hi,

wrote quite a portion of text, then realized it's all about what you already
described, so deleted it. Only one thought:

2. Use _all_docs to iterate over all documents, detect the ones that need
> changes and do them. This can probably take a while if you have lots of
> documents and never trigger all_docs during the "normal" application
> lifetime.
>

A variation of this might be to create a view that will be keyed by version
(and type, another "necessary" field in every document) and use that for
migrations, not _all_docs. You can be pretty sure that keys of this view
won't change.

In large databases (which I have no experience with), you probably can't
afford running migrations off-line, so you have to deal with older versions
of documents at runtime. Some sort of your approach 1 will probably be
needed. Same applies when using replication.

LT