> On Nov 13, 2014, at 5:47 AM, Matthew Booth <mbo...@redhat.com> wrote: > > Unfortunately this model doesn't apply to Nova objects, which are > persisted remotely. Unless I've missed something, SQLA doesn't run on > Nova Compute at all. Instead, when Nova Compute calls object.save() this > results in an RPC call to Nova Conductor, which persists the object in > the DB using SQLA. Compute wouldn't be able to use common DB > transactions without some hairy lifecycle management in Conductor, so > Compute apis need to be explicitly aware of this.
So just a note to Dan, this is an example of where I keep hearing this about Nova objects. I’ve discussed this with Dan and if I understand him correctly, I think the idea is that a Nova Compute call can be organized such that the objects layer interacts with the database layer in a more coarse-grained fashion, if that is desired, so if you really need several things to happen in one DB transaction, you should organize the relevant objects code to work that way. Still for me to get my head around is how often we are in fact organizing the bridge between objects / database such that we are using the database most effectively, and not breaking up a single logical operation into many individual transactions. I know that Nova objects doesn’t mandate that this occur but I still want to learn if perhaps it tends to “encourage” that pattern to emerge - it’s hard for me to make that guess right now because I haven’t surveyed nova objects very much at all as I’ve been really trying to stick with getting database patterns sane to start with. _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
