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 <mba...@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@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
