openstack team mailing list archive

[Devin Carlen <devin.carlen@xxxxxxxxx>]

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@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp