> "Merging" sounds easy, but it isn't :-) Consider merging licenses, >> copyrights, ownership, responsibility, mission statements, etc. etc. >> > Sorry, for the confusion: by merging I just mean the merging of the > metadata/connection handling (or come up with some common interface). >
I think that a common interface will require a couple of "organisational merging" first as a common interface is a contract that multiple parties will have to adhere to. Besides, I have some doubts that such an interface will be easy to evolve. Sooner or later, a common interface between jOOQ, QueryDSL, JPA, Liquibase, Flyway, etc. would be "useful", too. But don't get me wrong, I'm sure there is potential for writing adapters for a better integration! Specifically, once such an integration is started, lots of new feature requests and ideas might arise, for jOOQ as well. > So in a more realistic scenario, the two tools could improve cooperation. >> Could you be specific about your use-cases? Where do you run into trouble, >> when meta data info is duplicated? How could this be improved (on the jOOQ >> side, on the Liquibase side?) >> > We use both tool to create an abstraction over the database specific > syntax. We cannot generate classes with JOOQ (as schema is on the fly > constructed) and we do not use change-set management feature of the > liquibase. > One of the usage scenario: we import csv like files into a database: > -- process the file: metadata like column names, types (and length), table > names are inferred > -- the table is created with the help of liquibase > --- we convert column names to liquibase.database.structure.Column and use > the its TypeConverter class to get the right type mapping > --- then we create the table > -- the content is loaded by jooq > --- we convert column names to org.jooq.Field and lookup the type > representation in org.jooq.impl.SQLDataType > --- then we load the data > So from what I understand, there is a bit of potential here, in writing adapters for these types: LB Database <-> jOOQ Executor (previously, jOOQ Factory) LB ForeignKey <-> jOOQ ForeignKey LB PrimaryKey / UniqueConstraint <-> jOOQ UniqueKey LB Schema <-> jOOQ Schema LB Sequence <-> jOOQ Sequence LB Table / View <-> jOOQ Table LB Column <-> jOOQ Field LB DataType <-> jOOQ DataType LB TypeConverter <-> jOOQ Converter In a first step, I'd suggest that a Liquibase adapter for jOOQ would be written. This would cover your use-case, as the master meta-information is managed by Liquibase. This could then be further evolved into a "both-ways" adapter solution, if possible. I have filed a feature request for this: https://github.com/jOOQ/jOOQ/issues/2286 I'll evaluate feasibility and usefulness of such an addition for jOOQ 3.1. I'll keep you posted. Any further implementation hints, partial contributions are very welcome, of course Cheers Lukas -- 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/groups/opt_out.
