Hi Ross, Yes, you're absolutely right and we're aware of that. Unfortunately, early design decisions in jOOQ made immutability a difficult-to-achieve goal. We're planning to review much of jOOQ's design in jOOQ 4.0, where immutability will play a major role. The relevant issue for this is: https://github.com/jOOQ/jOOQ/issues/2198
Some more comments inline: 2015-10-14 11:38 GMT+02:00 Ross Goldberg <[email protected]>: > It would be useful to have immutable versions of jOOQ query objects that > do not have values bound to bind variables. > > Such immutable queries could be reused, and a bind context could be > supplied whenever the query is run. > Does jOOQ support anything like this? > You can already reuse queries if you make sure that you won't modify them after you've created them. The RenderContext and BindContext types do not affect the query AST. > It would also be useful to be able to introspect on such immutable > queries, to iterate through the various steps in the query, and to see > explicitly affected tables, columns, etc. (there could also be implicitly > affected tables, columns, etc. due to triggers, cascading foreign keys, > etc. but that's outside the scope of this request), as well as what columns > are used in included where clauses. > > These features would all be especially useful for creating an immutable > object cache on top of jOOQ supporting efficient cache invalidation, etc. > An immutable query object could be attached to a caching context, in which > case the caching context could return a wrapped version of the immutable > query that would first check the cache for that query for the supplied bind > context whenever it was run, and, if a result set is already present in the > cache, then it would return an immutable version of that instead of > performing the query, > > Obviously, cache invalidation would have to be performed, and > introspection of the query to know what columns are used in the where > clauses of a query would be useful for limiting the extent of cache > invalidation (of course, this ignores potential issues like a view column > being calculated from other columns, but, this should still be useful for > many common situations, and ways of handling the exceptional cases could be > devised over time; e.g., maybe jOOQ could read comments on view columns > which could be used to specify the underlying columns on which they depend, > or there could be a programmatic method / config file for this in jOOQ, > etc.). > You can also do this, via the VisitListener SPI. This SPI has been specified to implement custom SQL transformation: - http://www.jooq.org/doc/latest/manual/sql-building/queryparts/custom-sql-transformation The main drivers for this functionality are the ability to implement row-level security: - http://stackoverflow.com/q/17324524/521799 - http://blog.jooq.org/2015/06/17/implementing-client-side-row-level-security-with-jooq/ ... or caching, as you are planning to do: - http://aakashjapi.com/caching-with-jooq-and-redis/ - https://groups.google.com/d/msg/jooq-user/ayTAxqTXozw/WWc3LI8kIxoJ Note, that a built-in result cache is on our roadmap: - https://github.com/jOOQ/jOOQ/issues/2751 As you can see, immutability is not strictly required to implement these things, although it helps guarantee that nothing goes wrong. I hope this helps already to get you started. We're very interested in pushing these features further towards a simpler integration for our users. Right now, you'll have to do all the "hard work" of SQL transformation yourself via VisitListener. We'd love to implement row-level security and result caching out of the box. So, any feedback that you can provide us will be greatly appreciated to help us get going in the right direction. Looking forward to hearing from you again, 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.
