Yes, exactly. Currently, korma's data modeling occurs via macros that create data structures which aren't exactly part of the public API. So, your options are to wrap all the macros in a way that exposes the data model, or to try to interpret the data structures that it creates, without any guarantee that they'll be the same in the next release.
On Wednesday, October 30, 2013 4:22:33 PM UTC-7, Manuel Paccagnella wrote: > > 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.
