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):

def my_api_method(context, …):

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:

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 <> 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:  
> - mike
> _______________________________________________
> OpenStack-dev mailing list

OpenStack-dev mailing list

Reply via email to