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