Hello (for the record, this discussion is held also on Stack Overflow: http://stackoverflow.com/q/30762177/521799)
I suspect you followed up on our blog post example that we've given here: http://blog.jooq.org/2015/03/26/hack-up-a-simple-jdbc-resultset-cache-using-jooqs-mockdataprovider We've explicitly left out the topic of cache invalidation, because that's obviously the hardest part of caching in general. The nature of the MockDataProvider is very low level. We designed it to work also with non-jOOQ JDBC statements, so you don't have access to jOOQ types like Configuration from within a MockDataProvider. The design is mostly suitable for caching master data that hardly ever changes, or that can be invalidated on scheduled basis, rather than on an event basis. If you really want to implement a fine-grained per-table cache on top of a MockConnection that invalidates every time the underlying table is modified, then you will probably need to implement some tricks using ThreadLocal in order to communicate your table structures to your cache engine. Another option would be to write a VisitListener / ExecuteListener in addition to the MockDataProvider. The VisitListener could be used to extract tables from a query, whereas the ExecuteListener would activate your MockConnection if needed. In both cases, NOTIFY is probably the best way to trigger cache invalidations directly from the database, e.g. via triggers on INSERT, UPDATE, DELETE. Regarding your questions: 2015-06-10 2:44 GMT+02:00 <[email protected]>: > First, how do I determine between reads and writes? > Within a MockDataProvider, you could resort to using string manipulation. E.g. regexes. jOOQ internally tends to use PreparedStatement.execute(), rather than executeQuery() or executeUpdate(), in order to materialise multiple ResultSets and update counts, so on a JDBC level, you can't be really sure. If you're using VisitListeners / ExecuteListeners, then you can detect reads / writes more easily. > Also, is this a correct approach at caching? > Well, you're writing a very sophisticated cache, and if you execute it well, we'll be very happy to merge that into jOOQ :) The question is really: Do you need such a low-level, generic, sophisticated cache, or would a simple service-level cache suffice? > My first thought was to override the fetch() method, but that method is > final, and I'd rather not change something already embedded in Jooq itself > Overriding API might seem like a quick win, but we've evolved this API and its SPIs for a while now, so in the long run, you always want to inject behaviour via SPIs (and request missing features from us). > Keep in mind that I'm new to Jooq, so it's quite possible that I'm missing > something obvious. > Well, you won't be too new to jOOQ after implementing this, that's for sure. A great way to learn about jOOQ's internals! :) Hope this helps for starters. I'm very happy to answer any further, specific questions that you may have. 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.
