Hi Darren,
2014-01-24 Darren Shepherd <[email protected]>
> Yeah, doesn't exactly seem ideal. But at the end of the day, we're
> not exactly looking for RecordMapper caching, but instead caching of
> reflection information.
The reason I mentioned this is because RecordMapper already does its own
reflection information caching. But that doesn't help, of course, if
RecordMapper is not reused very often.
> Would it be possible to change the annotation
> utils methods, such as getAnnotatedMembers(), to accept a
> Configuration object as an argument, then do something like the
> following:
>
> static final List<java.lang.reflect.Field>
> getAnnotatedMembers(Configuration configuration, Class<?> type, String
> name) {
> if ( configuration instanceof SomeMagicalInterface ) {
> ((SomeMagicalInterface)configuration).getCachedStuff(type,
> name);
> }
> ...
> }
>
> If we are focusing on just providing caching for reflection, it may
> make sense to not specifically tie the interface and logic to the
> record mapper. In fact you could just use Configuration.data(...) as
> your cache.
>
That's not a bad idea at all. jOOQ currently puts all sorts of "local"
flags with the "org.jooq.xxx" namespace in various copies of that map,
mostly for the lifecycle of an ExecuteListener. But having a cache for
arbitrary things in there is likely to work around any class loading issues
that might arise with a static cache.
So essentially, the cache could globally store { org.jooq.Field,
java.lang.Class } => { List<java.lang.reflect.Method>,
List<java.lang.reflect.Field> }, or something similar. Sounds like a plan!
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/groups/opt_out.
