Hi Lukas, Thanks for your reply. See inlined.
On Sunday, September 7, 2014 11:56:16 PM UTC-7, Lukas Eder wrote: > > Hi Josh, > > 2014-09-08 1:53 GMT+02:00 Josh Padnick <[email protected] <javascript:>> > : > >> 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. > My main question was really "what's the value of an offline schema representation?" and this directly answers that. Thanks! > > >> 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. > I should have been more careful with my wording. I was definitely not proposing going direct to DDL. Rather, I was making the point that if your schema design tool already generates SQL, which in turn is used to create your actual database structure, which in turn can be read by jOOQ for code generation, then why bother enabling jOOQ to also import the database structure from an offline representation? You answered that above. > > >> 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. > Agreed, and it's exciting to hear that a beta version of this is coming. Thanks, Jarosław! While you're here, Jarosław, I just played around with Vertabelo for a few minutes and here's some quick feedback: - Overall, I really love the concept. Hopefully, we'll be able to use a tool like this in the future since it's an improvement on our current workflow with DataNamic DeZign. - The one major feature DeZign has that I didn't see -- at least in my few minutes of using your free version -- is the ability to partition the diagram into multiple diagrams. This way, I don't have to have to just one enormous visual diagram of the whole schema. Instead, I can work with one limited area at a time. Perhaps that's what "subject areas" refers to on your website, but I didn't see any details on that, either on the site or in the app. - The versioning/tagging is very cool. Ultimately, for us, each incremental update to the model will exist in the context of a specific GitHub branch and commit, so it'd be nice if there were a direct GitHub integration so that I could, for example, make a commit in a GitHub branch, and then in Vertabelo immediatley tag that commit. It looks like the current versions are a more subversion-style "linear" track, and that you would create branches by "Create a New Model From...". Maybe in practice, that's good enough. - When I generate my SQL in DeZign, I often want to generate only a subset of my model (e.g. all tables in a particular schema), whereas it appears here I can only generate all SQL at once and filter by type (table, indexes, etc.,) but not by table. - It would be nice to divide models by schema. We plan to have several hundred tables in our model, so we divide them by schema to keep them organized, whereas it looks like I would need to view all tables alphabetically. Overall, really cool software, and I'll keep tabs on your progress! Josh > > 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.
