Closed mattiaslevin closed 9 years ago
I think I am done. -I decided to move the CacheConfig annotation to Mardao in order to control cache expiration -If the @Cached annotation is set on the domain the dao generation will overload and annotate crud methods for caching -If Cached(cachePage=true) the queryPage method will be annotated for caching as well but with a special namespace and shorter expiration -The DaoBean will also get the CacheDefaults annotation with a namespace set to the domain class
Unit tests added to make sure the generation work (all the right annotations in the right place). I do not plan on testing the actual caching here since it is outside the responsibly of Mardao.
The solution feels more decoupled and flexible then before since using jsr107 annotations and code generation. The only thing I do not like so much is that I had to move the CacheConfig (the reason I need CacheConfig is that CacheDefaults does not have a expiration property).
Your latest commit broke the Travis build.
Sorry, it was just the notification from Travis that got lost or wrong
I'll be damed
Can you please take an initial look?
It is not complete so do not merge yet: -Add unit tests -Add @CacheValue and @CacheKey annotation on generated cache methods
Questions: -Should the generated methods be in the Generate..DaoImpl or the Dao file? If it is in the Dao file the user can more easily understand what happened and add more directives to the file (like @CacheConfig) to control cache configuration -There is a need to put a shorter cache expiration on page query methods. But this annotation (@CacheConfig) is currently in Guja, should I move it?