Johannes Erdfelt johan...@erdfelt.com 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
On Dec 16, 2011, at 11:30 AM, Mark Washenberger wrote:
Johannes Erdfelt johan...@erdfelt.com 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.
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 devin.car...@gmail.com wrote:
Yes, we should absolutely push to make this more
2011/12/15 Jesse Andrews anotherje...@gmail.com:
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 |
++ 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
Yes, that was what I was saying. :)
On Dec 15, 2011, at 12:06 AM, Soren Hansen wrote:
2011/12/15 Jesse Andrews anotherje...@gmail.com:
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
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'
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
On Thu, Dec 15, 2011 at 3:29 AM, Rick Harris rick.har...@rackspace.com 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
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 returning
-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 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 know some
On Thu, Dec 15, 2011, Kevin L. Mitchell kevin.mitch...@rackspace.com 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,
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
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 to
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
Johannes Erdfelt johan...@erdfelt.com said:
On Thu, Dec 15, 2011, Kevin L. Mitchell kevin.mitch...@rackspace.com 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
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.
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
On Thu, Dec 15, 2011, Mark Washenberger mark.washenber...@rackspace.com 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,
+1
On 12/15/11 3:19 PM, Johannes Erdfelt johan...@erdfelt.com wrote:
On Thu, Dec 15, 2011, Mark Washenberger mark.washenber...@rackspace.com 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
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
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 =
23 matches
Mail list logo
