Open Stack

> * 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.

But as I said before, your point is entirely valid for the cases where
it's relevant.

> * Instance.save() cascades saves to security groups, each of which is
> saved in a separate transaction.
> 
> We can push these into the db layer, but it is my understanding that
> NovaObjects are supposed to manage their own mapping of internal state
> -> db representation. If we push this into the db api, we're violating
> the separation of concerns. If we're going to do this, we'd better
> understand, and be able to articulate, *why* we don't want to allow
> NovaObjects to manage a db transaction when required. The pattern I
> outlined below is very simple.

The DB API isn't a stable interface, and exists purely to do what we
need it to do. So, if pushing the above guarantees into the DB API works
for the moment, we can do that. If we needed to change something about
it in the future, we could. If you look at it right now, it has some
very (very) specific queries and updates that serve very directed
purposes. I don't see pushing atomicity expectations into the DB API as
a problem.

> I'm proposing a pattern which is always safe and is simple to reason
> about. I would implement it everywhere. I don't think there are any
> downsides.

Cool, sounds like a spec. I'd say propose it and we'll see where it goes
in review.

Thanks!

--Dan

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: OpenPGP digital signature
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20141120/be30516b/attachment.pgp>