> 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

Reply via email to