> * 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
signature.asc
Description: OpenPGP digital signature
_______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
