>> I don't see the immediate use-case for that. Could you explain, please? >> Note that I think that that these "extreme" customisation ideas are >> best implemented by allowing for complete code generation >> customisation, which is what jOOQ 3.0 should implement. > > One use case is a large model where you might want to split tables into Java > packages. In our app, the table names are prefixed with module names, so the > strategy must be able to turn ADM_USER into *.adm.User.
OK, I see. You can indicate the package name of a generated object using GeneratorStrategy.getJavaPackageName(...). > Depending on time/pressure, I'll try to create a pull request for a new code > generator but since my time is limited, I'll probably write it in Xtend. > That wouldn't add any runtime dependencies on jOOQ, it would only add 2-3 > runtime dependencies on the code generator. As you wish. As a rule of thumb, a large pull request is less likely going to make it into the codebase than a small one (due to the risk of breaking things). I understand that with your project schedule, pull requests may not be useful at this time... Cheers Lukas
