On Thu, Aug 10, 2023 at 6:23 PM Jarkko Miettinen <eon...@gmail.com> wrote:
> Thanks! > > It seems that VisitListener is indeed the way to go. > > It seems that Clauses will get removed at some point, so would it be best > to do the same inference using QueryPart-subinterfaces? > Clauses were flawed in a way that they are very hard to formalise forward compatibly. For example, assume a jOOQ version where GROUP BY only supported simple grouping sets. So GROUP BY would immediately contain fields. But then, suddenly, it would start supporting GROUPING SETS, which can be nested. This would require new clauses, probably? But how to communicate this to client code? With QueryPart only checks, you can't really know "where you are" within a query. E.g. when you're visiting a Condition from within a Select, is it a WHERE, HAVING, QUALIFY condition? So, with Clause being deprecated, the goal was to move towards the new experimental model API. You won't wait until you reach a Condition within a Select to make transformations. Instead, you transform the Select itself, depending on its Condition. It's only at the level of the Select object where you have complete information allowing to decide what to do. If you're waiting for the Condition visit event, then you'd need some stack maintenance to "remember" what the Select was, and that's way more complicated. The blog post I've linked to is complicated as well. It is "clause aware", i.e. it tries to remember whether WHERE has already been rendered. That's because the VisitListener is triggered during the rendering of your SQL query. It would be much simpler to just transform the Select object itself (which you can do from within a VisitListener, btw). This is why I said a combination of both VisitListener and replacement API will offer the simplest solution. > I'll also take a look into the replacement API. > > Direct support sounds great but I guess it's somewhere a bit further in > the future? > "Somewhere", yes. I don't think it'll make it in jOOQ 3.19, as that is already quite the release and I'd love to ship implicit path correlations and to-many paths: https://www.jooq.org/doc/dev/manual/sql-building/sql-statements/select-statement/implicit-path-correlation/ But it's a high priority for me as I think it would add a lot of value, and I haven't seen many other ORMs capable of doing such things. Best Regards, 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 jooq-user+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jooq-user/CAB4ELO5E46AyHxGs1bc1JjhUhCrT392ZsTHwvY5-1KJa75PC5w%40mail.gmail.com.
