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
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
> 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
> 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:
- plain SQL API
- 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.
You received this digest because you're subscribed to updates for this group. You can change your settings on the group membership page.
To unsubscribe from this group and stop receiving emails from it send an email to [hidden email].