Comments (8)
I'm not sure if I understand. Today, there is the SchemaMapping functionality as documented here:
http://www.jooq.org/manual/ADVANCED/SchemaMapping/
http://lukaseder.wordpress.com/2011/11/09/development-schema-production-schema/
Besides, there is an open feature request to give users of jooq-codegen more flexibility in choosing their own naming schemes:
https://sourceforge.net/apps/trac/jooq/ticket/618
But a much more interesting approach was proposed by a user who is currently implementing a Groovy Templating extension. I'm also thinking about an XSLT code generator that transforms an intermediate XML schema definition:
https://sourceforge.net/apps/trac/jooq/ticket/911
Are any of those ideas what you had in mind? In any case, thanks a lot for the feedback! Feel free, to participate also in the news group to get discussions with other users going:
https://groups.google.com/forum/#!forum/jooq-user
Cheers
Lukas
from jooq.
Hey Lukas,
Thanks for your reply.
We use system properties to specify where the database we want to generate code for is. I guess I'm looking for an option to explicitly specify the class name for the schema in the generated code so that this can always be reliable, regardless of what database is being used. Something like schemaClassName here:
...
<jdbc>
<schema>${schemaLocalName}</schema>
</jdbc>
<generator>
<target>
<schemaClassName>SchemaReliableName</schemaClassName>
</target>
</generator>
...
This solves the compile time half of the problem that mapping solves for us at runtime.
Does that explain it better?
Thanks,
- Dan
from jooq.
I see, that's an interesting idea. I filed it as feature request #958:
https://sourceforge.net/apps/trac/jooq/ticket/958
Can you elaborate a bit more on your use-case, so I can get this right, especially in the documentation. In runtime SchemaMapping, it's possible to re-write schema names and table names. The use case is usually that the development or integration test schema (= code generation schema) has different namings from the (various) production schemata.
When does it happen that the code generation schema is different? Do you build the generated classes several times, once in every environment? Do you think, re-writing table names at code generation time is useful, too?
from jooq.
For us the schema / database is a matter of environment configuration. Each developer may have several databases with the same DDL loaded, but different data. Also our integration server runs many builds that require databases for their tests, and we may have e.g. two different branches of the same app with their own build jobs. In this case they'll need their own databases too, even though the table structure is the same.
from jooq.
I see, that makes sense. In the short term, I can see how your suggested feature will help. It should be easy to implement in jooq-codegen
In the long term, though, I prefer what was discussed in this thread here with Sergey Epik:
https://groups.google.com/forum/#!topic/jooq-user/4-iZMVDtkGA
This is about separating the code-generation phase from the schema introspection phase, meaning that the schema meta-data is first transformed into XML (or some other format), whereas code generation is based precisely on that database-independent XML source.
from jooq.
I'm closing this GitHub issue. It will be further tracked in Trac:
https://sourceforge.net/apps/trac/jooq/ticket/958
from jooq.
The configuration will be
<configuration>
<jdbc>
... the schema here is deprecated. it'll be removed later
<schema>${schemaLocalName}</schema>
</jdbc>
<generator>
<database>
... the input schema is used for reading data in jooq-meta
<inputSchema>${schemaLocalName}</inputSchema>
... the output schema is used for code generation
<outputSchema>SchemaReliableName</outputSchema>
I'll create a sample configuration in the jooq-codegen-maven-example Maven artefact. Both code generation and runtime will be integration tested in a new integration test suite.
from jooq.
Awesome, looks great.
Thanks!
from jooq.
Related Issues (20)
- Memory leak in DefaultCacheProvider when large amounts of arbitrary projections are mapped with DefaultRecordMapper - Merge [#16315]
- Memory leak in DefaultCacheProvider when large amounts of arbitrary projections are mapped with DefaultRecordMapper - Merge [#16315]
- Memory leak in DefaultCacheProvider when large amounts of arbitrary projections are mapped with DefaultRecordMapper - Merge [#16315]
- Kotlin 2.0.0 warns about Kotlin Record class annotation on "is" property HOT 4
- Settings.transformPatternsUnnecessaryScalarSubquery produces wrong SQL when subquery column is aliased HOT 1
- Settings.transformPatternsUnnecessaryScalarSubquery produces wrong SQL when subquery column is aliased - Merge [#16702]
- Settings.transformPatternsUnnecessaryScalarSubquery produces wrong SQL when subquery column is aliased - Merge [#16702]
- Pattern replacement activates RETURNING clause of DELETE / UPDATE statements HOT 3
- Pattern replacement activates RETURNING clause of DELETE / UPDATE statements - Merge [#16705]
- Pattern replacement activates RETURNING clause of DELETE / UPDATE statements - Merge [#16705]
- Settings.transformPatternsUnnecessaryScalarSubquery produces wrong SQL when subquery column is an embeddable HOT 2
- Settings.transformPatternsUnnecessaryScalarSubquery produces wrong SQL when subquery column is an embeddable - Merge [#16708]
- Settings.transformPatternsUnnecessaryScalarSubquery produces wrong SQL when subquery column is an embeddable - Merge [#16708]
- Wrong SQL generated when projecting inline derived table based on to-one implicit join path
- Inline derived tables have no effect when used as explicit join paths
- Error related to unsupported implicit to-many join caused by internal hash function
- Add Kotlin and Scala code generator support for synonyms via type aliases
- Add Functions.let(T1, T2, ..., TN, Function[N]<? super T1, ? super T2, ..., ? super TN, ? extends R>) utilities HOT 2
- Generate MyTable.let(Function<? super MyTable, ? extends R>) utilities on generated tables HOT 5
- Jooq codegen doesnt generate POJO for one table HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from jooq.