In general, my point is that libraries don't compose if they have incompatible or hidden representations of the data structures over which they operate, which is the default condition if no one has thought about how the libraries might be used together. A consequence of this is that a framework is much, much greater than the sum of its parts.
A dsl that can abstract away details of building queries (e.g. joins) requires a declared schema. In contrast, the clojure migration tools describe a schema as a series of functions, or sql string literals. It's hard to derive one from the other. You wouldn't want to start trying to parse the sql to deduce the schema, for instance. Consequently you end up repeating the schema. Then you add an administrative UI, and you have the same problem: the pages and forms for the admin depend on the schema. You end up repeating the schema a third time. And so forth. It quickly becomes unmanageable. For this case, migrations, it's easier to derive the sql for the migrations from a declared schema (doing a diff against the previous version) than the other way around (parsing sql to find the schema). This is how django-south works (it automatically generates the sql for the migrations, in most cases), but there's nothing like it for clojure that I'm aware of. Also, the sql dsls in clojure that I've seen cover very little of sql for data model creation, so you can't actually compose them with the migration tools as you suggest: they can't represent migrations. Having a declared schema also makes the code more maintainable. It can be bewildering to work on code where the schema is written as a series of "alter table" statements. Any non-trivial project will have a dozen or two boilerplate tables (users, sessions, settings, etc.). If they are all written as a series of "alter table" statements, there is a huge cognitive load just in figuring out what the tables are, and how they are related. On Tuesday, October 29, 2013 4:09:33 PM UTC-7, Chris Kuttruff wrote: > > Well things were kept separate intentionally. If someone wants to use > Korma or some other DSL within their migrations, they can augment their > migration file to use that to generate the SQL, but having the migrations > set up such that instructions to jdbc are simple clojure strings is very > intentional. This way I don't limit anyone's decision about what other > libraries they use, but complicated migrations can easily be dynamically > generated (since they are being picked up within the context of a clojure > file). > > Not sure I fully understand your point, but this seems like a reasonable > case for modularity. > > > On Tuesday, October 29, 2013 8:49:55 AM UTC-7, Brian Craft wrote: >> >> >> >> On Monday, October 28, 2013 4:36:56 PM UTC-7, Chris Kuttruff wrote: >>> >>> Separate from DSLs like Korma, etc. I have written a simple library for >>> doing database migrations with clojure (clj-sql-up ( >>> https://github.com/ckuttruff/clj-sql-up )). There are also other >>> libraries still maintained along these lines (drift, migratus, ragtime, >>> etc.) >>> >>> >> It's unfortunate that these are separate, because you need the schema >> information not just for migrations, but also for query abstraction (sql >> dsl, etc.). The argument for small, composable libraries only works if they >> can actually be meaningfully composed: if, in this case, a declared schema >> can be used for migrations, and query abstraction, and administrative UI, >> and anything else that requires it. So far there's not much like this in >> clojure that I've found. >> > -- -- 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.
