Hi Friso, I'm happy to hear that jOOQ helped you fix this issue so quickly, short before going to production.
*Long term solution:* That's an interesting idea you have. In a future release (I'm hoping 3.12, but no promises), jOOQ will be able to replace (composite) key columns by a single synthetic column with a synthetic key type. At first, this will work out of the box for single-column keys: https://github.com/jOOQ/jOOQ/issues/6124 And then should be extended to composite keys, including non-key column groups: https://github.com/jOOQ/jOOQ/issues/2530 The code generator would then hide the fact that a composite key is really composite, and your mistake would be impossible. The details still need to be defined, of course. *Short term checker using VisitListener:* In the meantime, you could indeed implement a check that verifies if, in the presence of a predicate on a composite key's first column, there is also a predicate on the composite key's second column. One way to do that would be by implementing a VisitListener. Getting it right may be non-trivial, but getting it working could be rather simple: Your VisitListener would have to look for predicates, and then for the columns inside of those predicates, and then, if the column is part of a composite key, push that info in some stack and make sure that at the end of the SQL generation, the entire composite key is represented by some predicate. This might be sufficient for you, although again, getting it right is harder, because you would have to make sure that by all boolean logic, the key is really queried correctly. E.g. -- Good (KeyA, KeyB) = (1, 2) KeyA = 1 AND KeyB = 2 KeyA = 1 AND KeyB IN (2, 3) KeyA = 1 AND (KeyB = 2 OR KeyB = 3) -- Bad KeyA = 1 OR KeyB = 2 KeyA = 1 AND (KeyB = 2 OR Something = 3) So, again, by hiding the composite key's individual columns, a future jOOQ will make it impossible to form any of the bad predicates, but also some of the good ones... 2018-06-07 9:59 GMT+02:00 <[email protected]>: > Hi, > > I just fixed a bug (luckily before production use), where I did an update > to a table that has a unique index over two fields. I forgot one of those > in the where clause. Thanks to jOOQ, I can just look at everywhere the > given field is used and fix any more missing. > > That got me wondering: would it be possible to have some execute listener > (or something better that I didn't think of) that inspect a query and > reports that part of an index is being used, but not the whole thing? > > Groeten, > > Friso > > -- > 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/d/optout. > -- 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/d/optout.
