I think option e is our best bet. It's the *only* option if we want to efficiently separate our services (as Jason has pointed out).
Waldon On Nov 29, 2011, at 10:52 AM, Devin Carlen wrote: > Hey Soren, > > On Nov 29, 2011, at 7:20 AM, Soren Hansen wrote: > >> SQLAlchemy does support looking these things up on the fly. In fact, >> AFAIK, this is its default behaviour. We just override it with >> joinedload options, because we don't use scoped sessions. >> >> My fake db driver looks stuff like this up on the fly (so the >> assertEquals after the virtual_interface_create will fail with that db >> driver). >> >> So my question is this: Should this be >> >> a) looked up on the fly, >> b) looked up on first key access and then cached, >> c) looked up when the parent object is loaded and then never again, >> d) or up to the driver author? >> >> Or should we do away with this stuff altogether? I.e. no more looking up >> related objects by way of __getitem__ lookups, and instead only allow >> lookups through db methods. So, instead of >> network['virtual_interfaces'], you'd always do >> db.virtual_interfaces_get_by_network(ctxt, network['id']). Let's call >> this option e). > > I think a simpler expectation of what the data objects should be capable of > enables a much wider variety of possible implementations. > > The main advantage to option e) is that it is simple both from an > implementation and from a debugging point of view. You treat the entire db > layer as though it's just dumb dictionaries and then you enable a wider > support of implementation. Sure sqlalchemy supports lookups on __get__item, > but maybe other potential implementations won't. > >> I'm pretty undecided myself. If we go with option e) it becomes clear to >> consumers of the DB api when they're pulling out fresh stuff from the DB >> and when they're reusing potentially old results. Explicit is better >> than implicit, but it'll take quite a bit of work to change this. > > Well, this is the way nova *used* to work. I'm not exactly sure when and if > that changed. > >> >> If we go with one of options a) through d), my order of preference is >> (from most to least preferred): a), d), c), b). >> >> Option e) is also easy to explain and do reviews for, btw. >> >> It seems I've talked myself into preferring option e). It's too much >> work to do on my own, though, and it's going to be disruptive, so we >> need to do it real soon. I think it'll be worth it, though. >> >> -- >> Soren Hansen | http://linux2go.dk/ >> Ubuntu Developer | http://www.ubuntu.com/ >> OpenStack Developer | http://www.openstack.org/ >> >> _______________________________________________ >> Mailing list: https://launchpad.net/~openstack >> Post to : openstack@lists.launchpad.net >> Unsubscribe : https://launchpad.net/~openstack >> More help : https://help.launchpad.net/ListHelp > > _______________________________________________ > Mailing list: https://launchpad.net/~openstack > Post to : openstack@lists.launchpad.net > Unsubscribe : https://launchpad.net/~openstack > More help : https://help.launchpad.net/ListHelp
_______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp