Since CouchDb is inherently unstructured, there’s no global schema that you manage to control your data’s structure. That’s often a good thing, because it gives you flexibility, but it can also cause problems, for example when you want to access documents without handling against all sorts of different “versions” of your document you might have.
When we first talked about document databases we said:
- no more ORM. Do a search or take a quick look at this list of NoSQL libraries and see if that still stands.
- no more schema constraints. The moment the structure of the data showed signs of evolving too rapidly, we started to look for ways to test document structure for inconsistency
- no more data migrations. Maybe no data migrations, but data versioning might be needed long term.
I think I’ve already written this once, but here it is again: the sum of constraints in a system is constant. The more relaxed the rules are on a component, the more constraints the rest of the components will need to support.
Original title and link: Document Databases and Data Migrations ( ©myNoSQL)
This is a simple example on using MongoDB in Scala using the Casbah driver for MongoDB and Salat as the ODM (Object Document Mapping) as a Maven project and generating the eclipse project files to work with.
What’s wrong with us Java people to consider simple something that requires over a hundred lines of configurations just to be able to do an insert and find?
Original title and link: MongoDB in Scala Using Casbah and Salat Object Document Mapping ( ©myNoSQL)