openstack team mailing list archive
-
openstack team
-
Mailing list archive
-
Message #06159
Re: using objects returned from DB layer
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" <johannes@xxxxxxxxxxx> wrote:
>On Thu, Dec 15, 2011, Kevin L. Mitchell <kevin.mitchell@xxxxxxxxxxxxx>
>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 : openstack@xxxxxxxxxxxxxxxxxxx
>Unsubscribe : https://launchpad.net/~openstack
>More help : https://help.launchpad.net/ListHelp
Follow ups
References