Hello Joseph, I like the way this discussion is developing. Essentially, what you're suggesting is to have an abstract metadata representation of any form, and then the possibility of calculating the diff between two versions, possibly including all the DDL statements that are required to transition between the two.
I had thought about this before: https://github.com/jOOQ/jOOQ/issues/4751 But it's a lot of work, especially if this should work for all the 21 currently supported RDBMS :) I don't think that the best way to represent this meta model would be via CREATE TABLE statements. The semantics of concrete DDL commands is perhaps too specific to the creation of the tables. Any "command" like "removeColumn" would feel unnatural. Also, the existing generated code has been designed specifically to be used in jOOQ's DSL to express queries. It is far from being optimised for use-cases as the one you're describing. While jOOQ's main feature is its close-to-SQL-DSL, I think that any meta model that is used for these kinds of things should be XML based (e.g. this existing schema: http://www.jooq.org/xsd/jooq-meta-3.5.4.xsd). A potential model manipulation API / DSL would just wrap the underlying XML data structure. But again, while these ideas seem interesting, they're lots of work. I don't think that project will be on our roadmap any time soon. Best Regards, Lukas 2016-01-22 0:15 GMT+01:00 <[email protected]>: > Hi > > Does the above reply make any sense? Actually, I fear not, and I fear even > more my previous idea wasn't this great... > > Actually I've forgotten to add something which I had in mind: inside this > metamodel DSL, I would actually use collections, for tables and the likes. > Thus I would expect comparisons between meta models to be easier to > achieve. On the other hand, the generated metamodel is quite sweet as well, > so there I would actually wrap the metamodel pojo around the above > metamodel, for example something along the lines: > class Foo implements Table{ > > private final Table table = new TableBuilder("Foo").addColumn("ID", > SQLDataType.INTEGER.nullable( > false))...().build(); > > public Column<Integer> getID(){ > return table.getColumn("ID"); > } > } > > Eager to see if it's only nonsense :) > > best > joseph > On Thursday, January 21, 2016 at 12:35:59 AM UTC+1, [email protected] > wrote: >> >> Hi Lukas >> >> I was thinking back on the topic and something "hit" me. >> >> What if the DDL was distinct from the generated POJO? >> >> For example, let's say I could write something close from : >> >> Table table = create.createTable("AUTHOR") >> .addColumn("ID", SQLDataType.INTEGER.nullable(false)) >> .addCumn("FIRST_NAME", SQLDataType.VARCHAR.length(50)) >> .column("ADDRESS", SQLDataType.VARCHAR.length(50)) >> .build(); >> >> Then maybe I could do something like ModelUpdater.apply(table); >> >> Then, later on, maybe I could something close to: >> Table tablev1 = table.change().removeColumn("ID").addColumn("IDENTIFIER", >> SQLDataType.INTEGER.nullable(false)).build(); >> >> And then: >> Schema schemaV1 = Schema.of(tablev1); >> Schema changes = Schema.diff().from(Schema.of(table)).to(schemaV1); >> ModelUpdater.apply(changes); >> >> And then maybe I could run something like: >> GenerationTool.generate(configuration, schemaV1); >> >> What's the big deal? >> >> Well, currently DSLContext.createTable() can just be used to directly act >> on the database. >> >> The idea here is to add a Schema in between, which could be used as well >> for generating stuff in the database but also kept as the meta model. >> >> Then later on it could be used as a starting for the updated schema. And >> for sure it could be used as well to generate POJO. These nasty Pojos would >> then be purely "record" description, the schema/meta model being kept to >> describe the model. >> >> Actually, I was thinking that such a "schema", with collections of >> tables, procedures and what's not in it, could make easier migration >> betweens schemas (in the case of generated pojos having as well, hard >> coded, the model definition). >> >> Am I definitely too tired and it's all crap or does it make sense somehow >> ? >> >> >> Back to the ongoing discussion, I wouldn't go for Maven: control of when >> generation happens it too low IMHO. Actions should happen not at install >> time but on startup (for the db migration work) or on demand for the pojo >> part. >> >> I guess I'll some examples at some point (with 3modules : migration, >> domain and application). >> >> thanks again :) >> >> best >> joseph >> > -- > You received this message because you are subscribed to the Google Groups > "jOOQ User Group" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "jOOQ User Group" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
