A probably simplistic consideration: maybe there should be a data model expressed as a data structure so that it can be leveraged by arbitrary libs. This way there would be a single representation, but no explicit dependencies between single libs. Here probably Datomic could be an example.
Il giorno mercoledì 30 ottobre 2013 01:12:25 UTC+1, Brian Craft ha scritto: > > 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.
