Re: [openstack-dev] [oslo.db][nova] NovaObject.save() needs its own DB transaction

2014-11-27 Thread Jay Pipes
On 11/19/2014 01:25 PM, Mike Bayer wrote: OK so here is why EngineFacade as described so far doesn’t work, because if it is like this: def some_api_operation -> novaobject1.save() -> @writer def do_some_db_thing() novaobject2.save() ->

Re: [openstack-dev] [oslo.db][nova] NovaObject.save() needs its own DB transaction

2014-11-20 Thread Dan Smith
> * Flavor.save() makes an unbounded number of db calls in separate > transactions. This is actually part of the design of the original flavors public API. Since we can add and remove projects/specs individually, we avoid ending up with just one or the other group of values, for competing requests

Re: [openstack-dev] [oslo.db][nova] NovaObject.save() needs its own DB transaction

2014-11-20 Thread Matthew Booth
On 19/11/14 18:25, Mike Bayer wrote: >> Whether we wait for the oslo.db updates or not, we need something >> like the above. We could implement this today by exposing >> db.sqla.api.get_session(). > > EngineFacade is hoped to be ready for Kilo and obviously Nova is very > much hoped to be my firs

Re: [openstack-dev] [oslo.db][nova] NovaObject.save() needs its own DB transaction

2014-11-20 Thread Matthew Booth
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 19/11/14 18:39, Dan Smith wrote: >> However, it presents a problem when we consider NovaObjects, and >> dependencies between them. > > I disagree with this assertion, because: > >> For example, take Instance.save(). An Instance has relationships

Re: [openstack-dev] [oslo.db][nova] NovaObject.save() needs its own DB transaction

2014-11-19 Thread Dan Smith
> However, it presents a problem when we consider NovaObjects, and > dependencies between them. I disagree with this assertion, because: > For example, take Instance.save(). An > Instance has relationships with several other object types, one of which > is InstanceInfoCache. Consider the followin

Re: [openstack-dev] [oslo.db][nova] NovaObject.save() needs its own DB transaction

2014-11-19 Thread Mike Bayer
> On Nov 19, 2014, at 12:59 PM, Boris Pavlovic wrote: > > Matthew, > > > LOL ORM on top of another ORM > > https://img.neoseeker.com/screenshots/TW92aWVzL0RyYW1h/inception_image33.png > I know where you sta

Re: [openstack-dev] [oslo.db][nova] NovaObject.save() needs its own DB transaction

2014-11-19 Thread Mike Bayer
> On Nov 19, 2014, at 11:46 AM, Matthew Booth wrote: > > We currently have a pattern in Nova where all database code lives in > db/sqla/api.py[1]. Database transactions are only ever created or used > in this module. This was an explicit design decision: > https://blueprints.launchpad.net/nova/+

Re: [openstack-dev] [oslo.db][nova] NovaObject.save() needs its own DB transaction

2014-11-19 Thread Boris Pavlovic
Matthew, LOL ORM on top of another ORM https://img.neoseeker.com/screenshots/TW92aWVzL0RyYW1h/inception_image33.png Best regards, Boris Pavlovic On Wed, Nov 19, 2014 at 8:46 PM, Matthew Booth wrote: > We currently have a pattern in Nova where all database code lives in > db/sqla/api.p

[openstack-dev] [oslo.db][nova] NovaObject.save() needs its own DB transaction

2014-11-19 Thread Matthew Booth
We currently have a pattern in Nova where all database code lives in db/sqla/api.py[1]. Database transactions are only ever created or used in this module. This was an explicit design decision: https://blueprints.launchpad.net/nova/+spec/db-session-cleanup . However, it presents a problem when we