openstack team mailing list archive

[Duncan McGreggor <duncan@xxxxxxxxxxxxx>]

I'm really glad to hear all these votes for e), 'cause that's what I'd
like to see too :-)

d

On 29 Nov 2011 - 11:18, Brian Waldon wrote:
> 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@xxxxxxxxxxxxxxxxxxx
> >> Unsubscribe : https://launchpad.net/~openstack
> >> More help   : https://help.launchpad.net/ListHelp
> >
> > _______________________________________________
> > Mailing list: https://launchpad.net/~openstack
> > Post to     : openstack@xxxxxxxxxxxxxxxxxxx
> > Unsubscribe : https://launchpad.net/~openstack
> > More help   : https://help.launchpad.net/ListHelp
>

> _______________________________________________
> Mailing list: https://launchpad.net/~openstack
> Post to     : openstack@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp