Hi Josh, 2014-09-08 1:53 GMT+02:00 Josh Padnick <[email protected]>:
> Lukas, > > I enjoyed your recent blog post at > http://blog.jooq.org/2014/09/05/importing-your-erd-export-into-jooq/#respond. > I've been using DataNamic DeZign, which is a really great program, but not > available for my Mac, doesn't support all Postgres data types, and has > several other limitations. So Vertabelo and the concept of SaaS ERD tools > was a revelation! > > One question I have from your post is what's the value of streamlining how > jOOQ imports your data model from the ERD tool if you have to generate the > SQL for your database itself anyway? > Being able to import "offline" schema representations of your database has been a repeated feature request over the past years and up until recently, it would've been rather difficult to implement. In the mean time, the added value of the feature definitely pulls its weight. Once "offline" schema representations can be imported, it is easy to see the benefit of being able to produce an export/import chain with an ERD tool. This doesn't mean that we mainly encourage using an ERD tool to generate such an "offline" representation. ERD tools are just one possible source. Another might be an export from your SQL database to this intermediary format. Because often, the build server generating the database might not have access to any live database, which is why an intermediary "offline" representation may help. This is also particularly useful when you want to support several databases and do not want to base code generation on only one of them. > Moreover, wouldn't you be better off seeding jOOQ with the raw SQL using > the code generator to avoid any edge case mismatches between the SQL > generation and the export-to-import conversion? > If I understand this correctly, you're suggesting to feed raw DDL statements to the jOOQ code generator? This would imply implementing parsers that understand the semantics of DDL of all 17 supported RDBMS. We wouldn't want to go through that hassle, I believe. > In general, I would say that one aspect of our design workflow that is not > very streamlined is going from "add a table in our ERD" to "update our > FlyWay scripts and re-run the jOOQ code generator." > I understand, but I believe that this doesn't really have anything to do with the jOOQ code generation, which just introspects a snapshot of your database schema. The actual migration is much more complex and should be handled separately from anything that jOOQ does. I'm actually not sure if Vertabelo supports database migrations (i.e. exports of delta SQL snippets). It would certainly be awesome if it did. I'll ask the product manager (whom I've met at a conference) to join in to this discussion. Best Regards, 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/d/optout.
