I agree with this. It was more the idea that we need to move away from Sqlalchemy specifically, and that dictionary access actually solves this problem somehow. Seems like a straw man to me.
On 12/15/11 2:02 PM, "Rick Harris" <[email protected]> wrote: >For me, it's not one particular notation versus the other, I'd be happy >with either--it's having both. It just needlessly complicates things. > >> Now we're complaining that the ORM we likely aren't using >> correctly isn't working for us > >I don't think anyone is complaining that the *ORM* is at fault here. >We're just complaining that our abstraction is leaky, and since we went >through all of the trouble to have this DB API indirection, we may as >well seal it up so we can eventually support other data stores. > >As it stands now, we have all of the complexity of abstraction without >any of the benefits. > >On Dec 15, 2011, at 12:35 PM, Matt Dietz wrote: > >> I have to confess to being confused here. We deliberately chose >> sqlalchemy. Then we mapped everything away so it didn't look like the >>ORM >> in question when in reality, we partially took some of said ORM's job >>away >> from it. Now we're complaining that the ORM we likely aren't using >> correctly isn't working for us. In short, we chose to use an ORM, and >>now >> we're complaining about the O >> >> I'm not seeing what taking everything to a dictionary-centric model buys >> us, and I also don't see anyone actually justifying it. Can we get some >> actual examples of why one approach is better than the other? >> >> >> On 12/15/11 10:54 AM, "Johannes Erdfelt" <[email protected]> wrote: >> >>> On Thu, Dec 15, 2011, Kevin L. Mitchell <[email protected]> >>> wrote: >>>> 2. However, I violently disagree with the idea that the DB layer >>>> must return dicts. It does not, even if you start talking >>>>about >>>> allowing use of other kinds of databases. We can, and should, >>>> wrap these things in objects, upon which we can call methods >>>> that do things‹i.e., we should, you know, actually use >>>> object-oriented programming. >>> >>> What kinds of things? >>> >>> I'm not against returning back a standardized object that provides >>> __getattr__ so we don't have to use dict notation. Any database backend >>> can do something similar easily. >>> >>> I'm just trying to better understand what is object-oriented about the >>> data returned from a database? What methods would we want to use? >>> >>> JE >>> >>> >>> _______________________________________________ >>> Mailing list: https://launchpad.net/~openstack >>> Post to : [email protected] >>> Unsubscribe : https://launchpad.net/~openstack >>> More help : https://help.launchpad.net/ListHelp >> >> >> _______________________________________________ >> Mailing list: https://launchpad.net/~openstack >> Post to : [email protected] >> Unsubscribe : https://launchpad.net/~openstack >> More help : https://help.launchpad.net/ListHelp > _______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : [email protected] Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
