On 23/01/15 19:47, Mike Bayer wrote: > > > Doug Hellmann <[email protected]> wrote: > >> >> >> On Fri, Jan 23, 2015, at 12:49 PM, Mike Bayer wrote: >>> Mike Bayer <[email protected]> wrote: >>> >>>> Ihar Hrachyshka <[email protected]> wrote: >>>> >>>>> On 01/23/2015 05:38 PM, Mike Bayer wrote: >>>>>> Doug Hellmann <[email protected]> wrote: >>>>>> >>>>>>> We put the new base class for RequestContext in its own library because >>>>>>> both the logging and messaging code wanted to influence it's API. Would >>>>>>> it make sense to do this database setup there, too? >>>>>> whoa, where’s that? is this an oslo-wide RequestContext class ? that >>>>>> would >>>>>> solve everything b.c. right now every project seems to implement >>>>>> RequestContext themselves. >>> >>> >>> so Doug - >>> >>> How does this “influence of API” occur, would oslo.db import >>> oslo_context.context and patch onto RequestContext at that point? Or the >>> other way around? Or… ? >> >> No, it's a social thing. I didn't want dependencies between >> oslo.messaging and oslo.log, but the API of the context needs to support >> use cases in both places. >> >> Your case might be different, in that we might need to actually have >> oslo.context depend on oslo.db in order to call some setup code. We'll >> have to think about whether that makes sense and what other dependencies >> it might introduce between the existing users of oslo.context. > > hey Doug - > > for the moment, I have oslo_db.sqlalchemy.enginefacade applying its > descriptors at import time onto oslo_context: > > https://review.openstack.org/#/c/138215/30/oslo_db/sqlalchemy/enginefacade.py > > https://review.openstack.org/gitweb?p=openstack/oslo.db.git;a=blob;f=oslo_db/sqlalchemy/enginefacade.py;h=3f76678a6c9788f62288c8fa5ef520db8dff2c0a;hb=bc33d20dc6db2f8e5f8cb02b4eb5f97d24dafb7a#l692 > > https://review.openstack.org/gitweb?p=openstack/oslo.db.git;a=blob;f=oslo_db/sqlalchemy/enginefacade.py;h=3f76678a6c9788f62288c8fa5ef520db8dff2c0a;hb=bc33d20dc6db2f8e5f8cb02b4eb5f97d24dafb7a#l498
May I suggest that we decouple these changes by doing both? Oslo's RequestContext object can have the enginefacade decorator applied to it, so any project which uses it doesn't have to apply it themselves. Meanwhile, the decorator remains part of the public api for projects not using the oslo RequestContext. I suggest that we'll probably stay with a decorator within oslo, anyway. It doesn't lend itself well to a Mixin, as we need a reference to a specific _TransactionContextManager, and moving code directly into RequestContext would be a very invasive coupling. Matt -- Matthew Booth Red Hat Engineering, Virtualisation Team Phone: +442070094448 (UK) GPG ID: D33C3490 GPG FPR: 3733 612D 2D05 5458 8A8A 1600 3441 EA19 D33C 3490 __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
