so i have code that works , i just want to talk about it with other
users and see if this is a good strategy / could be improved.

i had to refactor the caching code to split it into more manageable
chunks and integrate it into the app-config for different environments

this is what came of it...

-   my app has an internal caching api.  it looks like this:
    - - - - - - - - - -
    app.lib.caching
    app.lib.caching.utils ( dogpile setup )
    app.lib.caching.section_a
    app.lib.caching.section_b
    - - - - - - - - - -

- app.lib.caching.utils
    - - - - - - - - - -
    from dogpile.cache import make_region

    # set the initial regions to None
    # we'll update this during application setup
    #
    region_name2id = None

    def initialize_dogpile( config , settings ):
        """ called during app setup
            ensures we have a data directory for file based caches
        """
        customized= { 'data_dir' : settings['data_dir'] }
        mkdir_p( "%(data_dir)s/dogpile" % customized )
        cache_opts = {
            'cache.name2id.backend': 'dogpile.cache.dbm',
            'cache.name2id.expiration_time': '86400',
            'cache.name2id.arguments.filename': '%(data_dir)s/dogpile/
name2id' % customized,
        }
        global region_name2id
        region_name2id = make_region(key_mangler=str)
        region_name2id.configure_from_config( cache_opts ,
'cache.name2id.' )
    - - - - - - - - - -

- app.lib.caching.section_a
    - - - - - - - - - -
    from . import utils

    def user_id_to_username( user_id , dbSession=None , request=None ,
can_use_cache=True  ):
        """ wraps get_user_data
            we stuff the decorator into an 'inner' function, because
the region does not exist until application setup
        """

        @utils.region_name2id.cache_on_arguments()
        def inner( user_id , dbSession , request , can_use_cache ):
            user= get_user_data( user_id , dbSession=dbSession ,
request=request , can_use_cache=can_use_cache )
            if user:
                return user['username']
            return None

        return inner( user_id , dbSession , request , can_use_cache )

    def get_user_data( user_id , dbSession=None , request=None ,
can_use_cache=True ):
        """ gets the user row.
            this will optionally pull from the cache.
            the inner function _sharedcache is called when cached data
is ok...
            ...otherwise we directly query the database.
        """

        def _query(user_id=None):
            user_id = int(user_id)
            useraccount = dbSession.query( model.core.Useraccount.id )
\
                .filter( model.core.Useraccount.id == user_id )\
                .first()
            if useraccount:
                return useraccount[0]
            return None

        @utils.region_name2id.cache_on_arguments()
        def _sharedcache(user_id):
            return _query(user_id)

        if can_use_cache:
            return _sharedcache(user_id)
        return _query(user_id)
    - - - - - - - - - -

generally, i'm wondering if this was the best strategy.

1- I couldn't think-through another strategy of having the cache
regions both configurable by the app config
2- I couldn't think of another way to allow for the decorators to be
used without wrapping them in an inner function.
3- I'm going to assume that the usage of the inner function is giving
me a performance hit, but it's probably really small and not worth
caring about. right?  { i've been avoiding looking into this from fear
of thinking we might need to look at optimizing it }

any feedback ?