Hi Joseph, I'll comment inline
2017-05-03 23:30 GMT+02:00 <[email protected]>: > Thanks again Lukas > > Well, I explored the matcher option and generated the v1 model with it and > the v3 model with the PrefixingGeneratorStrategy (hard coded prefix for > now) [1]. > > I'm doing the matcher this way: > MatchersTableType matchersTableType = new MatchersTableType(); > MatcherRule versionPrefixer = new MatcherRule().withExpression("v" > + currentVersion + "_$1"); > matchersTableType > .withExpression("^(.*)$") > .withTableClass(versionPrefixer) > .withTableIdentifier(versionPrefixer) > .withRecordClass(versionPrefixer) > .withPojoClass(versionPrefixer) > .withDaoClass(versionPrefixer) > .withInterfaceClass(versionPrefixer) > ; > > The PrefixingGeneratorStrategy is like this: > public class PrefixingGeneratorStrategy extends DefaultGeneratorStrategy { > > @Override > public String getJavaClassName(final Definition definition, final Mode > mode) { > return "v3_" + super.getJavaClassName(definition, mode); > } > > @Override > public String getJavaIdentifier(Definition definition) { > return "v3_" + super.getJavaIdentifier(definition); > } > > } > > It turns out that the matcher option prefixes less stuff than the > PrefixingGeneratorStrategy, notably the keys and sequences aren't prefixed. > So the PrefixingGeneratorStrategy wins the best prefix option award :) > Yeah, you'll have to specify the sequenceIdentifier as well, I guess. But indeed, the Keys can't be prefixed with the matcher strategy. Nice catch. I've registered a feature request for this: https://github.com/jOOQ/jOOQ/issues/6182 > However this one could still be better on 2 points: > 1 - prefixing the DefaultCatalog, Keys, Sequences and Tables classes as > well > -- currently only the the Schema is prefixed > => can it be done somehow? > No, I'm afraid these are currently hard wired in the JavaGenerator. Another feature request: https://github.com/jOOQ/jOOQ/issues/6183 > 2 - using the PrefixingGeneratorStrategy with various runtime prefixes > would require to use some global state (static, java properties) > -- this saddens me deeply :( Well, I guess you won't change it soon... But > at least the eternal law of xsd is respected: it always comes back to bit > in the a** (IMHO). Would you choose it (or something similar) again if you > could redo this part? Or would you stick to one language (Java in this > case) and its paradigms (DDD powa)? ^^ > Absolutely! I don't share your opinion here. The XSD approach allowed jOOQ's code generator to work with: - Standalone XML configuration - Maven XML configuration - Gradle XML-DSL configuration mapping (e.g. using the https://github.com/etiennestuder/gradle-jooq-plugin) - Programmatic configuration Sure, there are limitations. We cannot use all the types of the universe in this configuration, because ultimately, it's just XML. But that's a good thing too. It makes the whole thing much more maintainable, and it was only limiting in edge cases. Note, in your PrefixingGeneratorStrategy, you get a Definition argument, which references a Database which might give you access to some other resources you could use for a better workaround? 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.
