couchdb integration?

[holtzermann17]

#351 talks about using git to facilitate instant revisions. #260 suggests using memcached or a triple store for the XHTML cache.

In principle, we could add (yet?) another storage mechanism -- like CouchDB -- to serve e.g. the latest files -- there's even a contrib module to help with that, although not very popular yet. https://drupal.org/project/couchdb -- this would potentially be more useful/appropriate for large-scale deployments of the system.

MongoDB integration is more popular, https://drupal.org/project/mongodb and cf. http://kkovacs.eu/cassandra-vs-mongodb-vs-couchdb-vs-redis

Oct 7, 2013 - @dginev I guess this is a start to what I was talking about in the PM board mailing list today.

[dginev]

I won't assign this to myself, but just wanted to record my thoughts here.

While working on CorTeX, I also saw a need to have different backends for the different kinds of data that naturally occur in the system - e.g. a triple store for annotations, XML DB for efficiently querying XML documents and a classic SQL store for efficiently managing the system state.

But I also saw a dramatic rise in complexity of the system, and what is infinitely worse - maintenance burden for the developer. Database communication code is a frisky thing and frequently needs robustness and efficiency patches, as well as various extensions as the data you manage increases in complexity or becomes more heterogeneous.

So, for CorTeX, I have currently backed of from using 3 distinct backends and am following the mantra:

• If you can get away with using the file system, do so. (for document storage)
• If you can get away with using entirely MySQL (and even better SQLite) - do so.
• If all else fails, add a separate backend, but do it for the right reasons and maintain it well.

I think adding CouchDB, MongoDB or any of the zoo of other modern well-hyped backends is something to be approached very carefully as it can have a serious impact on our code base and deployment quality. @cprodescu had shared a nice presentation recently from the Instagram team which advised "do the simplest thing first" and add more on top only when it fails.

The current state of Planetary (December 2013) is already too complex to my liking, so I would first try to simplify it as much as possible and making it perform to its best extent before considering new backends.