In CouchDB, if you want to change your schema you just save the new data.
Your code will have to handle the old and the new form, but that is always true. In CouchDB the data is just a JSON document, so handling the changed model is about as easy as it gets.
I'm not sure what your point is. As you say, this is hard, and no one else has a solution either.
But the nature of CouchDB can help here - views can be used to create backward compatible versions of new data, and reading a JSON document with extra fields won't break existing code.
It's true it's not magic, though, if that is what you are after.
Edit: I see now you are working on http://chronicdb.com/ which looks like it tackles this problem.
10 apps connected to the same database. Changing the model breaks 10 apps. And you may not have access to change the code to any of those apps.
"Database as an integration layer" is an antipattern that should always be avoided (except possibly in the case of reporting applications). CouchDB isn't unique there.
In healthcare, when either the database or app go down people literally die.
Yes, and? CouchDB is reliable, distributable, etc etc. If your point is that you should be careful when you upgrade, then yes, I agree.
Adding extra JSON fields can break code if you have matching entity types, say in Java, for example, and its trying to "cast" those JSON objects to that data type I am fairly certain it will throw an exception if the JSON object has a field thats not in the Java type
Views are the reflection of the light at the end of the tunnel, but solve less than half the problem to date. Views work on SELECT, but not on UPDATE/INSERT/DELETE.
Also, what makes you say that database as an integration layer should always be avoided?
Also, what makes you say that database as an integration layer should always be avoided?
15 years of writing software. Every time I've had to deal with a shared database it has caused problems, and every time I've built a system avoiding that antipattern it has worked much better.
Database-as-IPC is about the transport aspect, not the logical integration (which is the problem of back-compatibility).
Ian F Nelson's blog post is about a DB that is tightly-coupled to the app: “my” application is using NHibernate as an ORM layer, so until this invasion we have been able to perform database schema refactorings with relative impunity.
Conventionally, RDB schemas are designed in terms of the data itself, not a particular app. In the Enterprise (where RDB are most used), data typically outlives different applications for the same task over decades, often written in different languages. Typically, the data needs also to be accessed by several different applications.
But here I'm talking about logical back-compatibility (surviving version changes) - the blog makes good points about "caching and application-level security". Where those vary with the application, it makes sense to separate them from the DB. But like Database-as-IPC, they are closer to the transport layer than to logical structure.
That's what versioning is for, isn't it? You still can submit old data under the previous version, and old apps will works just fine as they won't see the new data.
New apps will have to deal with old versions somehow, or some back-end job will produce new data out of the old.
In CouchDB, if you want to change your schema you just save the new data.
Your code will have to handle the old and the new form, but that is always true. In CouchDB the data is just a JSON document, so handling the changed model is about as easy as it gets.
What am I missing?