(Replying to PARENT post)
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
👤devs1010🕑14y🔼0🗨️0
(Replying to PARENT post)
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?
👤matc🕑14y🔼0🗨️0
(Replying to PARENT post)
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.