Brian Candler wrote:
However, performing this resolution on every single read is a complete PITA for the client side to implement, and easy to forget. To centralise and enforce this you really need some sort of proxy layer between the client and the database so that every doc read and view read has this logic performed.
It strikes me that there is a rich opportunity for the creation of HTTP middleware to add functionality on top of CouchDB, like sharding, replication, access control, transactional features, etc. (obviously not all at the same time).
I'm starting to wonder where these apps are. It would be quite straightforward for someone to start prototyping in PHP or Rails or whatever.
This is where I think the introductory material on couchdb.apache.org does CouchDB a big disservice by overhyping: it implies strongly that distributed, replicated applications are easy to write with CouchDB, but I don't think the reality matches that, at least not yet.
The pitch of CouchDB and the slacker databases is that you pay your technical debt very early in the project, writing more code for data management, and you get dividends later when you can grow more easily. Although I wouldn't go as far as "disservice" since it is true that the data requirements for many web applications is no longer a perfect fit with the relational model.
P.S. Should we move this to u...@? -- Jason Smith Proven Corporation Bangkok, Thailand http://www.proven-corporation.com
