Hi Darren, These are interesting thoughts. I have given it some time to settle, and I'm afraid I don't have an easy solution for you.
While it is possible for your users to add tables to their own schema or to yours and then generate code only for their own tables, the relevant meta data connecting the base schema with the user schema (e.g. foreign key information) won't be available. This isn't a show stopper per se, but it's quite inconvenient and may lead to unexpected behaviour. 2014-04-25 16:07 GMT+02:00 Darren S <[email protected]>: > I've created a platform for IaaS (you can see it at http://cattle.io) > that's heavily based on jooq. It's a very flexible platform intended to be > extended and repackaged for other purposes. I'm running into a general > problem with code generation in jooq though. > > People who extend the platform are free to add new DB tables to the > schemas. The platform ships with a base schema and the code generated for > the base schema. If somebody adds a new table, I'd really like them to be > able to just generate the code for the new table they added. That only > works if the new table doesn't reference any table in the base schema. > What I'm having to do now is if somebody adds a new table, they have to > regenerate the code for the entire schema and then package the schema jar > first in the classpath. > > Any ideas on how to improve this? It ends up being quite fragile because > if a change is made in the base schema and the person extending the > platform doesn't regenerate the overwritten schema, bad bad things happen > at runtime. > I would need to understand a bit more about what users will effectively change in your base schema. Can you give a meaningful example of such a change? In other words, would cattle.io itself be affected by changes made by your users? > It seems like this would be a major change to the codegen stuff to support > this. I was trying to at least come up with a fail fast approach that if > somebody forgot to regenerate the code it would detect it at runtime and > fail. One thing that makes that difficult is that for sane upgrades it's > required that old code can always run against a newer schema. So a simple > version stamp isn't possible. > > Darren > > -- > 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.
