Also, introspection on immutable queries would allow for reuse of superset result sets for subset queries, e.g., if the result set for "where x = 1" is in the cache, and if "where x = 1 and y = 2" is queried, then the cache could just iterate over the already cached values "where x = 1", checking the results for "y = 2", without querying the database.
It would be useful to have a static helper method like "Collection<Condition<?>> getSubsetWhereConditions(ImmutableQuery potentialSupersetQuery, BindContext supersetBindContext, ImmutableQuery potentialSubsetQuery, BindContext subsetBindContext)" that would return null if potentialSubsetQuery is not a "subset" query of potentialSupersetQuery (for the two supplied bind contexts), or, if potentialSubsetQuery is a "subset" of potentialSupersetQuery, a Collection<Condition<?>> of the extra Conditions that potentialSubsetQuery has beyond this (if the where clauses & bind contexts were exactly the same, then the returned Collection would have size == 0). On Wednesday, October 14, 2015 at 5:38:09 AM UTC-4, Ross Goldberg wrote: > > 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? > > 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 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.
