You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
By default, jOOQ generates bind parameters for all client values that are passed to the DSL, which is a sane choice in most cases.
In some cases, however, defaulting to inlining the value might be more reasonable, specifically the LIMIT clause, which is unlikely to have tons of different possible values. Mostly, people are limiting their queries to 1 or some N, without modifying the value of N between executions.
A new setting could allow to govern this behaviour, inlining LIMIT values by default (it is still possible to create explicit bind parameters using DSL.val()).
Other clauses might be affected by this flag as well. This needs further design
The text was updated successfully, but these errors were encountered:
Do you really want to change the default behaviour for this particular case? It's a matter of consistency. Right now I know that bind parameters are created for all client values. That's fine. I use DSL.literal() if I do not like it.
I consider using literals instead of bind parameters when a) the values change per execution and b) the changes affects the cardinality strongly. If this is not the case then a bind variable is usually not harmful. The optimizer will find a good execution plan based on bind variable peeking.
So, what exactly is the benefit of changing the default behaviour in this particular case?
I didn't say that the default behaviour will be changed by default :-) There will be a setting that allows to change the default.
Also, just because this idea is here on the roadmap doesn't mean it's going to be implemented. I will still need more traction for this idea to actually add it.
By default, jOOQ generates bind parameters for all client values that are passed to the DSL, which is a sane choice in most cases.
In some cases, however, defaulting to inlining the value might be more reasonable, specifically the
LIMIT
clause, which is unlikely to have tons of different possible values. Mostly, people are limiting their queries to1
or someN
, without modifying the value ofN
between executions.A new setting could allow to govern this behaviour, inlining
LIMIT
values by default (it is still possible to create explicit bind parameters usingDSL.val()
).Other clauses might be affected by this flag as well. This needs further design
The text was updated successfully, but these errors were encountered: