> > Hi Lukas, > > I want to create a cache layer on top of Jooq. For now, I only have > thought on how I want the cache layer to behave and how it should connect > to Jooq. I would like to have your opinion on the layer "architecture". > Moreover I would like to have an advice on how I could extract the table > names used in a Jooq query : I have found 2 solutions, but none of them are > satisfactory. > > Let's start with the code generation. I want for a table named "user" to > generate this hierarchy : > beans > *User*.java (extends UserPojo, generated only if the file does not > exist) > daos > *UserDao*.java (extends AbstractUserDao<User>, generated only if the > file does not exist) > generated > table > daos > *AbstractUserDao*.java (public abstract class AbstractUserDao<T > extends UserPojo> extends CachedDAOImpl<UserRecord, T, Long>) > interfaces > *IUser*.java (remain the same) > pojos > * UserPojo*.java (only the class name change, I want to distinct > the "real" User object from the generated ones) > records > *UserRecord*.java (remain the same) > *UserTable*.java (only the class name change, I want to distinct the > "real" User object from the generated ones) > *Keys*.java (remain the same) > *Tables*.java (remain the same) > *BaseName*.java (remain the same) > > To summarize, I want to change two things from the original Jooq codegen : > - One time generation of the User and UserDao classes. It enables to > extend the generated AbstractUserDao and UserPojo classes. > - UserPojo and UserTable rename. It enables to easily distinct each > generated classes. I don't like having many public classes with the same > name in a project. > > Now the real layer : CachedDAOImpl class. This class should inherit the > original DAOImpl class. It should add : > - a useCache() method overridable (default implementation returns false), > - the possibility to cache a query result, > - the clearCache() method. > If the useCache() method returns true, all "simple" accesses should be > cached, ie fetchById and fetchOneByUniqueField. The cache properties > (maxSize, expire etc) should be parametrized in the application, but it > could be good to be able to override the default cache properties in the > Dao. Anyway, when an object is cached with fetchById, the cache is clean > for the id "k", if the row with the id "k" is updated or removed (works > only if the delete, or update methods are called from the Dao). That part > is easy. > Now comes the problematic part. I want to provide a way to cache any > queries with possibly Joins. To cache a query like that, I need to : > - identify the query : DSLContext.renderNamedParams(query), > - concatenate all the query parameters to create the cache entry : > DSLContext.extractBindValues(query), > - identify the table names used in the query (to be able to clear the > cache for the query when any of the tables used in the query are being > updated). > I have found two ways to cache a query result in the dao : > - adding selectFromCached(Table) and selectCached(Fields) methods. It > would returned a slightly modified SelectImpl. However, the delegate class > (currently SelectQueryImpl), will be replaced. This way I can get the table > names with the getFrom() method and I can override the fetch() method from > AbstractResultQuery to be able to either execute the query or return the > cached result. Wait, the fetch() method is final, it cannot be overridden > :'(. I have to directly override the AbstractResultQuery class to remove > the final modifier :/. > - the second solution is to provide methods like fetchCached(Select > query): List<User>. This way I have to hack though the query with Java > reflection to get the from table names. > I would prefer to use the first solution. However, if you specified the > fetch() method as final in the AbstractResultQuery class, I think you had a > reason. So it would be wrong to just override the AbstractResultQuery class > to remove the final keyword. > What would you do to provide a way to easily cache a query ? > > Thank you for your time. I would be very happy to have a Jooq cache layer > working :) > > Aurélien > > PS: About caching, I am well aware that too much caching kills the cache > system. An application cache system should be set up only if the > application really needs it. However, caching DB query results is often a > very simple way to increase the application execution speed. >
-- 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/groups/opt_out.
