CODEWITHSUNDEEP
javajooq
scadge
scadge

Reputation: 9733

Check the inner type of FieldAlias in jOOQ

Is it possible to check the wrapped type of alias field in jOOQ? Something like field.getWrapped() instanceof AggregateFunction.

Also, I see that the class FieldAlias is not public, so it's not even possible to check field instanceof FieldAlias. What was the motivation for making this class not public?

Upvotes: 1

Views: 236

Answers (1)

Lukas Eder
Lukas Eder

Reputation: 221145

Is it possible to check the wrapped type of alias field in jOOQ? Something like field.getWrapped() instanceof AggregateFunction.

It is currently not possible get a hold of a field's alias through public jOOQ API, because aliasing, just like any other expressions done with jOOQ QueryPart types are all internal API.

There's a low priority pending feature request for this kind of check: https://github.com/jOOQ/jOOQ/issues/2579

The feature request does not yet describe a well-designed feature, so I'm currently not convinced that it will be added to the API soon.

You could work around this limitation by implementing the VisitListener SPI, which allows you to implement callbacks that get called for each QueryPart that is visited by the SQL rendering logic. Using a stack machine similar to the one described in this article, you could then check what expression is contained by an aliasing expression. The VisitListener could be triggered e.g. by calling DSLContext.render(QueryPart).

In fact, it would be interesting to be able to trigger the VisitListener SPI without needing to render the SQL string or collect bind variables. I've created a feature request for this: https://github.com/jOOQ/jOOQ/issues/6735

But in any case, this might be a bit overkill for your real world use-case, which unfortunately, I do not know yet from your question.

What was the motivation for making this class not public?

Simple: It's internal API. There's no reason why anyone should have access to internal API, which is bound to change at any moment, including between patch releases.

There have been a few complaints by a vocal minority on the jOOQ user group about jOOQ internals being package private and/or final. The complaints were mostly motivated by some short term goals like your suggested instanceof check whose motivation you chose not to disclose yet. It is almost always better to discuss the real motivation of a feature request which might translate to an awesome new feature that everyone can use rather than discussing the possibility of opening up just a tiny part of internal API for overriding. This sort of overriding is akin to simply patching the original source code and building the fork oneself. It might work in the short term, but for the community and the library itself, it is not a good solution because it only increases the maintenance pressure from a backwards compatibility perspective while not adding any value in general.

In that sense, it is a very very good idea to close down library internals by making them package private. Likewise, you do not have access to Java 8's Stream implementation classes, because, well, you shouldn't have such access.

More details about this API design motivation here: https://blog.jooq.org/2017/03/20/the-open-closed-principle-is-often-not-what-you-think-it-is/

Upvotes: 3

Related Questions