Hello Lukas, You mentioned in this GitHub comment<https://github.com/jOOQ/jOOQ/issues/2665#issuecomment-22241049>that I should post my use cases here for discussion regarding #2665.
I am in the early phases of replacing an in-house DB framework sitting atop a legacy schema which cannot be modified. JOOQ fits well here providing modern mechanisms for type safe interaction with the DB without trying to shoehorn the entire schema into an ORM (or the ORM onto the schema). The replacement framework should encapsulate some of the redundant details of our DML profile, while maintaining the expressiveness of your DSL. The features included in #2665 would (as far as I can tell) allow me to accomplish this end. I will list a couple of my use cases, perhaps there are other ways of dealing with this until 3.2 is released? 1.) Multi-tenant partitioning via discriminator column This is the big one. DML statements run against partitioned tables must include the discriminator in the WHERE clause. Failure to do so is nothing short of catastrophic, so I would like to enforce it for all DML generated through the DSL. Unfortunately not all tables are partitioned, so a global implementation would need to inspect the statement to determine if any of the tables affected contain a discriminator column. The ExecuteListener Interface and the ExecuteContext provided Query does not expose enough information to adequately make this determination and append the condition. Perhaps you see an alternative? 2.) Soft-delete flags I can't imagine that I am the only one facing this dilemma: How can I provide DRY style consideration of soft-delete flags while using the DSL? It would be great if I could implement a Listener interface and check if the queried tables have a soft delete flag, and when yes, append a condition regarding it. Again, it seems the current API does not provide enough query introspection to accomplish this in a listener. 3.) Insert/Update timestamps It would be nice if this could also be centrally enforced for tables containing the supporting columns. Obviously some of the above mentioned points could be solved at the RDBMS level, but unfortunately my options are quite limited in that area. Perhaps the "Listener" approach is the wrong one for my cases, although at first glance it appears correct. I look forward to hearing any thoughts/ideas you may have. Sam -- 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]. For more options, visit https://groups.google.com/groups/opt_out.
