On Dec 16, 2011, at 11:30 AM, Mark Washenberger wrote:
> "Johannes Erdfelt" said:
>
>> I'm not saying you need to do it, but this is something that doesn't
>> have an obvious design and implementation. It would be easier to
>> understand and discuss with some real meat behind it.
>
> From what
"Johannes Erdfelt" said:
> I'm not saying you need to do it, but this is something that doesn't> have an
> obvious design and implementation. It would be easier to> understand and
> discuss with some real meat behind it.
>From what Monsyne Dragon and Jonathan LaCour have said on this topic, I f
+1
On 12/15/11 3:19 PM, "Johannes Erdfelt" wrote:
On Thu, Dec 15, 2011, Mark Washenberger wrote:
> 1. regular objects (which is what I thought Kevin was talking about. . .
> maybe?)
I think this has been poorly defined so far. I've seen some quick
proposals that include moving instance action
On Thu, Dec 15, 2011, Mark Washenberger wrote:
> 1. regular objects (which is what I thought Kevin was talking about. . .
> maybe?)
I think this has been poorly defined so far. I've seen some quick
proposals that include moving instance actions to an Instance class,
etc.
It's hard to make a goo
On Dec 15, 2011, at 1:27 PM, Devin Carlen wrote:
> Matt, that answer is simple: so we can use things other than sqlalchemy.
>
Except that we don't need to do that to use other things that sqlalchemy.
We can have sqlalchemy map to plain python objects, and use those.
And any other persistence
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" wrote:
>For me, it's not one particular notation versus the other, I'd
The only thing I see that ties us to sqlalchemy is using the model objects
directly. But I think there are actually three choices here: sqlalchemy
objects, dicts, and regular objects. Well really there are four, if we include
sqlalchemy objects that try to act like dicts :-). My preference order
Hm. I've just been going off of this doc string in db/api.py:
"Functions in this module are imported into the nova.db namespace. Call these
functions from nova.db namespace, not the nova.db.api namespace.
All functions in this module return objects that implement a dictionary-like
interface. Cur
"Johannes Erdfelt" said:
> On Thu, Dec 15, 2011, Kevin L. Mitchell 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
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 faul
On Dec 15, 2011, at 8:21 AM, Monsyne Dragon wrote:
> Actually, what we should be working to is using plain python model
> objects, and having the sqlalchemy layer use it's mapper
> functionality (separated from the models) to map db rows to those
> models. THis will allow any persistence layer
Matt, that answer is simple: so we can use things other than sqlalchemy.
On Dec 15, 2011, at 10:35 AM, 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, w
On Dec 15, 2011, at 10:54 AM, Johannes Erdfelt wrote:
What kinds of things?
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
Any direct access to the data within a record should be encapsulated within th
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 wor
On Thu, Dec 15, 2011, Kevin L. Mitchell 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
On Dec 15, 2011, at 1:10 AM, Chris Behrens wrote:
>
> I've seen a number of patches lately that have code like this:
>
> instance = db.instance_get(...)
> instance_uuid = instance.uuid
>
> instead of:
>
> instance_uuid = instance['uuid']
>
> There's a mix of usage throughout the code, and I
-1
By using the dict style access to these records we are tying ourselves to the
internal implementation of those records. If we want to be able to move the
'data model' logic out of the 'process' logic we will need to access the models
as attributes and not dict items.
We should confine the
On Thu, 2011-12-15 at 07:10 +, Chris Behrens wrote:
> There's a mix of usage throughout the code, and I know some people are
> just matching the surrounding code. But, in a number of cases, I've
> asked for these to be corrected to the latter, on assumption that the
> DB layer will be returnin
On Thu, Dec 15, 2011 at 3:29 AM, Rick Harris wrote:
> ++ on moving to a consistent dict-style syntax.
+1 from me, too.
-jay
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.
> I was bringing this up initially as I want to enforce *something* when
> reviewing,
Yeah, I was just thinking that it could be a point of confusion if, for an
extended period, we're in a state where new code has to use dict-style instance
access, while nearby, older code still uses attr-acces
Agree with both #1s as a start. And I wouldn't try to 'rip off the band-aid'
either.
I was bringing this up initially as I want to enforce *something* when
reviewing, but if we want to start 'fixing' things, we can start hitting small
sections of code to limit conflicts. The 'enforce_model' t
Yes, that was what I was saying. :)
On Dec 15, 2011, at 12:06 AM, Soren Hansen wrote:
> 2011/12/15 Jesse Andrews :
>> I agree except I though the preference was for
>>
>>> instance_uuid = instance['uuid']
>>
>> not
>>
>>> instance_uuid = instance.uuid
>>
>> (use dict's and don't assume sqlalc
++ on moving to a consistent dict-style syntax.
We could attempt to rip the Band-Aid off here by:
1. Rejecting any new patches which use the dot-notation
2. Trying to switch out to using dot-notation access all at once in one big
'fix-it-up' patch.
I'm not convinced 2) is possible. Separating
2011/12/15 Jesse Andrews :
> I agree except I though the preference was for
>
>> instance_uuid = instance['uuid']
>
> not
>
>> instance_uuid = instance.uuid
>
> (use dict's and don't assume sqlalchemy)
Yes... That's what Chris is saying, isn't it?
--
Soren Hansen | http://linux2go.dk/
Ubu
I agree except I though the preference was for
> instance_uuid = instance['uuid']
not
> instance_uuid = instance.uuid
(use dict's and don't assume sqlalchemy)
On Wed, Dec 14, 2011 at 11:19 PM, Devin Carlen wrote:
> Yes, we should absolutely push to make this more consistent across the board.
Yes, we should absolutely push to make this more consistent across the board.
We are severely limiting possible future implementations.
So, yea. +1!
Devin
On Dec 14, 2011, at 11:10 PM, Chris Behrens wrote:
>
> I've seen a number of patches lately that have code like this:
>
> instance = db
I've seen a number of patches lately that have code like this:
instance = db.instance_get(...)
instance_uuid = instance.uuid
instead of:
instance_uuid = instance['uuid']
There's a mix of usage throughout the code, and I know some people are just
matching the surrounding code. But, in a numbe
27 matches
Mail list logo
