Hi Shorn, Thank you very much for your message.
That's a very good question, and unfortunately, there's not a very easy answer. In particular, you probably left out at least another case of where your table could be used, namely where the AccountRecord is used, or the Account (POJO). If you're looking only for DSL API usage (without the records, POJOs, etc.), then I'd go for the constructor calls of the table and recurse in the call hierarchy, because ultimately, those static constants: - Reference each other as in case 1) - Create a new table instance, as in case 2) More comments inline 2017-10-16 1:48 GMT+02:00 <[email protected]>: > For example, can I tell JOOQ not to generate the static constants, such > that using the Account constructor is the only way to refer to the table? > Yes, you can specify <globalObjectReferences>false</globalObjectReferences> to turn off all references such as the ones in Tables.java, or <globalTableReferences>false</globalTableReferences> to turn off just the ones in Tables.java I realise that the above flags are not documented on this page: https://www.jooq.org/doc/latest/manual/code-generation/codegen-globals For details, see the XSD: https://www.jooq.org/xsd/jooq-codegen-3.10.0.xsd > Failing existince of a JOOQ feature to help with this, it wouldn't be too > hard for me to remove the features during the code generation stage - but > would that even do the job though? Are the above three "reference types" > the only code-based ways to refer to DB objects, or other there other ways > I don't know about yet? > Ultimately, you have to track the constructor calls. All constructors are essential: One is used to create the static table reference (or your own references if you call it yourself), and the other is used to alias the table, which you should also match in your search. Of course, once you start working with the meta data APIs, you could also access tables from: - Constraints - org.jooq.Meta - plain SQL API - InformationSchema - Other ways? Yes, I understand this won't help me with views/functions, etc. that are > textually defined to use tables etc. > That's an interesting thought, though. I wonder if jOOQ could offer something in this area, in the long term. > I'm aware I could put in place some kind of static analysis to enforce > usage of a single type of table reference. But I'm asking if I can use > JOOQ to eliminate the possibility of using different types. > One more thing: You could patch the code generator to generate only private table constructors. That way, you couldn't instantiate them yourself anymore and you'd be forced to use the static singleton instance. Together with turning off the <globalTableReferences/>, you'd have a single point of contact with each table. Hope this helps, 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.
