Hi Christopher, Interesting questions...
2013/5/26 Christopher Deckers <[email protected]> > Hi Lukas, > > This discussion stems from what was said on schema validators: > https://github.com/jOOQ/jOOQ/issues/2476 > > In short: how does jOOQ help when we want/need multiple database support? > > When using jOOQ, the sequence seems to be: > 1. Have a database with a particular schema. > 2. Generate a JOOQ model for that database. > 3. Use JOOQ API to execute request using the dialect of the database. > > I see several cases where multiple database support can be of interest: > 1. When the application is installed on existing client systems and we > offer multiple tested possibilities (like SQL Server, Oracle, MySQL). > 2. When having a production database and mock database for testing (SQL > Server and H2). > 3. When we have a single production database but don't want to get too > tied in case we have to switch in the future (develop for MySQL, but don't > want to close the door for a switch to MariaDB or Postgres). > > In such a multi database scenario, the sequence is more: > 1. Use a model that is not too tied to a particular database. > 2. Use a generic SQL API that knows the dialect of the database to adapt > types (e.g. boolean), with occasional dialect specific operations. > > Currently, and correct me if I am wrong, jOOQ does not allow flexibility > of the database type that it is working on because the model comes from an > actual database. > The model itself is pretty much database-agnostic, although the current code generator only allows generating the model from an actual database. So, yes, you're right. However, some users have taken these things to the extreme. This thread may be of interest to you: https://groups.google.com/d/msg/jooq-user/tBG1CLrwkRU/rrIEPlc49HAJ > I wonder if jOOQ could add support for that scenario, or could make > official some best practices to simplify such support. > > So the first thing is to define which SQL types are garanteed to work on > all databases. This can be done by documenting a particular subset of > existing SQL types that are supported on all databases, or have new > datatypes (conceptual types) that jOOQ can map to real types on whatever > database. > Yes, I guess this is what will have to be done by users, first. > The next step is how to generate the model because in multiple database > developement, a specific database schema is generally not the source. If > jOOQ allowed to create a representation of a database structure from which > the model is generated, that structure could easily be created by code. > Could that also be the purpose of: > https://github.com/jOOQ/jOOQ/issues/2371 ? > It could. Or https://github.com/jOOQ/jOOQ/issues/1464. This issue is a collection of ideas that should allow to provide custom data sources for database models to the code generator. I haven't been working much on this, though. > If so, can we create such structure programmatically and generate the > model from it? > That would be great. In fact, you can already now. Implement all the interfaces in jOOQ-meta, and provide that to the code generator. Cheers Lukas Developers could even base part of the database creation from that > structure they defined programmatically. > > Cheers, > -Christopher > > -- > 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. > > > -- 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.
