* James Reeves <ja...@booleanknot.com> [2013-11-14 17:17 +0000]: > For instance, database migrations. This was something I thought about a lot > a few years ago, until I gradually realised that I wasn't finding myself in > any situations where I needed them.
I agree with much of what you write James - I'm paid to write rails and node.js code, and I'm finding that node is encouraging me to compose small components and basically sidestep a lot of the issues that rails is designed to address. But migrations, or more particularly, schema version management, is still something I need for databases which are schema based. How do you deal with that? Do you tend to use schemaless databases? Or maybe keep a native schema dump under version control? If you use a relational db, how do you make and track changes? I have recently encountered a large project which includes several distinct and separately deployed components, but which shares a single data model. A lack of schema management in this case has seriously impeded the project's ability to move forward quickly. Maybe the answer in that case is that those components should own their own data models, communicate through clearly defined interfaces, and never share a database. Maybe that's the way to deal with this - decompose a system until data model management is trivial for any given component. I'm interested to know what strategies people use for this, and what tooling (if any) is useful. cheers, J -- -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.