Do note that we're working on a few features that will greatly facilitate the row level security use case in the future, without requiring users to go "all in" on SQL transformation using VisitListener. One such improvement is the new Table.where() method, which later allows for creating views in jOOQ: https://github.com/jOOQ/jOOQ/issues/8010. It will be possible, in a future version, to add these predicates dynamically to all tables using new SPI.
On Wed, Aug 7, 2019 at 8:34 PM P R <[email protected]> wrote: > However, I'm curious, what's the motivation for not exposing the ability > to get the query parts. After all jOOQ enables query building and hence one > would expect to be able to get a handle to the constituent parts - similar > to expecting a getXXX() method if one can invoke setXXX() on a class. > You probably mean the fact that we don't expose the data model right now, but hide it in the package private org.jooq.impl classes. So far, this design decision was a very good decision as it allowed us to much more easily maintain those internals. However, we do recognise that a number of users want access to the query object model, including new users of the jOOQ parser. We're currently thinking about the re-design of that object model in a way that will allow us to expose it publicly, and maintain its backwards compatibility. This is a lot of work as it would (probably) require separating the model from the SQL generation, so no promises about that yet. -- 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]. To view this discussion on the web visit https://groups.google.com/d/msgid/jooq-user/CAB4ELO42tTcoP21cK1f3%3D4ZYF%2BTQVYKzV%3D6moTTDvGvj-vGT9Q%40mail.gmail.com.
