Open Stack

So so far, everyone seems really positive and psyched about the proposal.

It looks like providing some options for how to use would be best, that is provide decorators and context managers.    

Now the thing with the context manager, it can be as I stated:

    with sql.reader() as session:

or we can even have that accept the “context”:

    with sql.reader(context) as session:

The latter again avoids having to use thread locals.

But can I get a feel for how comfortable we are with using thread local storage to implement this feature?   I had anticipated people wouldn’t like it because it’s kind of a “global” object, even though it will be hidden behind this facade (of course CONF is global as is sys.modules, and I think it is fine).     If I just use a tlocal, this whole thing is pretty simple.

I’m going to do another pass that attempts to unify these three syntaxes - I’m proposing calling the context manager “using_” so that it can be differentiated from the decorator (e.g. so each function doesn’t need to inspect arguments):

@sql.reader
def my_api_method(context, …):
    context.session

def my_api_method(context, …):
   with sql.using_reader(context) as session:
     session , context.session

def my_api_method(…):
   with sql.using_reader() as session:
       session

all three will be fully interchangeable - meaning they will ultimately use thread local storage in any case.    For now I think if sql.using_reader(context) or @sql.reader is called with different context identities in a single call stack, it should raise an exception - not that we can’t support that, but whether it means we should push new state onto the “stack” or not is ambiguous at the moment so we should refuse to guess.




On Oct 8, 2014, at 5:07 PM, Mike Bayer <mbayer at redhat.com> wrote:

> Hi all -
> 
> I’ve drafted up my next brilliant idea for how to get Openstack projects to use SQLAlchemy more effectively.   The proposal here establishes significant detail on what’s wrong with the current state of things, e.g. the way I see EngineFacade, get_session() and get_engine() being used, and proposes a new system that provides a true facade around a managed context.   But of course, it requires that you all change your code!  (a little bit).  Based on just a few tiny conversations on IRC so far, seems like this might be a hard sell.  But please note, most projects are pretty much broken in how they use the database - this proposal is just a first step to making it all non-broken, if not as amazing and cool as some people wish it could be.  Unbreaking the code and removing boilerplate is the first step - with sane and declarative patterns in place, we can then build in more bells and whistles.
> 
> Hoping you’re all super curious now, here it is!  Jump in:  https://review.openstack.org/#/c/125181/
> 
> - mike
> 
> 
> 
> 
> 
> 
> 
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev