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