Subject API backed by local RDMBS cached data

Jeffrey F Williams: (paraphrase)
I want to  display a user's manager as an attribute when you look them up in Grouper.  I resolve the manager attribute ( from the Subject filter) which is a DN of the manager user object (person), but I'd rather have their displayName from the Manager user object.

Carey Black: 
I have been tempted ( but have not yet enough to actually do it ) to cache the LDAP data into a DB table structure and just refresh the DB tables a few times a day. And flip the LDAP Subject API into a JDBC Subject API.

I would loose the "instant discovery" of hitting the LDAP source directly, but I would gain the ability to stash more attributes too. And in Jeffrey's case, he could create a view that would auto include the Manager details with the "employee" data too. ( Views are really good at join conditions. Ldap filter, not so much. )

@mchyzer  If you want to make an enhancement....  Ready to bump the Subject api from v1 ? 
How about a Subject API that allows you to cache data into Grouper RDBMS tables.
         Such that the subject resolution would check the tables, If the date on the cached data is "to old" (config value for the Subject source) would then fall through and do a "refresh LDAP search" (and update the RDBMS cache) then return results from a configuration driven RDBMS view?  Meaning, update the cache for the subject then go look in a view for the "final answer".  ( I can have all of what I want that way. And so can Jeffrey too!  )