<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">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).<div><br></div><div>Waldon</div><div><br></div><div><br><div><div>On Nov 29, 2011, at 10:52 AM, Devin Carlen wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">Hey Soren,<div><br></div><div><div><div>On Nov 29, 2011, at 7:20 AM, Soren Hansen wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div>SQLAlchemy does support looking these things up on the fly. In fact,<br>AFAIK, this is its default behaviour. We just override it with<br>joinedload options, because we don't use scoped sessions.<br></div></blockquote><blockquote type="cite"><div><font class="Apple-style-span"><br></font>My fake db driver looks stuff like this up on the fly (so the<br>assertEquals after the virtual_interface_create will fail with that db<br>driver).<br><br>So my question is this: Should this be<br><br>a) looked up on the fly,<br>b) looked up on first key access and then cached,<br>c) looked up when the parent object is loaded and then never again,<br>d) or up to the driver author?<br><br>Or should we do away with this stuff altogether? I.e. no more looking up<br>related objects by way of __getitem__ lookups, and instead only allow<br>lookups through db methods. So, instead of<br>network['virtual_interfaces'], you'd always do<br>db.virtual_interfaces_get_by_network(ctxt, network['id']). Let's call<br>this option e).<br></div></blockquote><div><br></div><div>I think a simpler expectation of what the data objects should be capable of enables a much wider variety of possible implementations.</div><div><br></div><div>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.</div><div><br></div><blockquote type="cite"><div>I'm pretty undecided myself. If we go with option e) it becomes clear to<br>consumers of the DB api when they're pulling out fresh stuff from the DB<br>and when they're reusing potentially old results. Explicit is better<br>than implicit, but it'll take quite a bit of work to change this.<br></div></blockquote><div><br></div><div>Well, this is the way nova *used* to work. I'm not exactly sure when and if that changed.</div><br><blockquote type="cite"><div><br>If we go with one of options a) through d), my order of preference is<br>(from most to least preferred): a), d), c), b).<br><br>Option e) is also easy to explain and do reviews for, btw.<br><br>It seems I've talked myself into preferring option e). It's too much<br>work to do on my own, though, and it's going to be disruptive, so we<br>need to do it real soon. I think it'll be worth it, though.<br><br>-- <br>Soren Hansen | <a href="http://linux2go.dk/">http://linux2go.dk/</a><br>Ubuntu Developer | <a href="http://www.ubuntu.com/">http://www.ubuntu.com/</a><br>OpenStack Developer | <a href="http://www.openstack.org/">http://www.openstack.org/</a><br><br>_______________________________________________<br>Mailing list: <a href="https://launchpad.net/~openstack">https://launchpad.net/~openstack</a><br>Post to : <a href="mailto:openstack@lists.launchpad.net">openstack@lists.launchpad.net</a><br>Unsubscribe : <a href="https://launchpad.net/~openstack">https://launchpad.net/~openstack</a><br>More help : <a href="https://help.launchpad.net/ListHelp">https://help.launchpad.net/ListHelp</a><br></div></blockquote></div><br></div></div>_______________________________________________<br>Mailing list: <a href="https://launchpad.net/~openstack">https://launchpad.net/~openstack</a><br>Post to : <a href="mailto:openstack@lists.launchpad.net">openstack@lists.launchpad.net</a><br>Unsubscribe : <a href="https://launchpad.net/~openstack">https://launchpad.net/~openstack</a><br>More help : <a href="https://help.launchpad.net/ListHelp">https://help.launchpad.net/ListHelp</a><br></blockquote></div><br></div></body></html>