2015-06-17 22:56 GMT+02:00 <[email protected]>: > Hey, > > I do have invalidation set up (the cache uses Redis, so the ThreadLocal > trick didn't end up being necessary), and this did end up working. Your > method works like a charm for INSERT/UPDATE/DELETE/MERGE queries, making > invalidation by table easy. Right now I'm trying to make it work similarly > with arbitrarily nested SELECT queries, which I can already grab tables > from using a recursive string-parsing method, but this would be cleaner. > Otherwise, my current implementation, using a > MockConnection/MockConnectionProvider/MockDataProvider, an ExecuteListener > and VisitListener, and Jedis (java client for Redis), is fully functional > with table-based invalidation and result storage and works on all types of > queries. Thanks for all the help! >
Sounds excellent! :) Do you plan on publishing this work? E.g. via GitHub, or via a blog post? I think it would be very useful for the community. Do you have any suggestions on getting the tables of nested select queries > (and from joins in those queries) through the VisitListener? Or should I > just stick to my string parsing methods? > As promised, we've blogged about a similar use-case using a VisitListener to implement row-level security here: http://blog.jooq.org/2015/06/17/implementing-client-side-row-level-security-with-jooq This implementation adds predicates to queries (and subqueries) every time a given table is encountered, in order to protect access to it. Perhaps that's similar to what you've had in mind? Or what is the use-case of "getting the tables of nested select queries" in your case? Could you provide an example, please? Cheers, 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 [email protected]. For more options, visit https://groups.google.com/d/optout.
