-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 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
For this I think we need to separate the models from the queries. A query
method should be able to populate as many of the models as needed to return the
data collected. I also think separating the queries from the models themselves
will help us make the storage engine replaceable, and will
the hint, why not just populate those models in the
initial query?
Something like
db.instances_by_id_including_fixed_ips(id)
or
db.instances_by_id_including_vifs(id)
or whatever.
Aaron Lee
___
Mailing list: https://launchpad.net/~openstack
Post
I think I missed the larger discussion around why these metrics are getting
published.
tl;dr metrics good; these metrics, maybe not so good
My worry about publishing number of commits by author is that it could make
Gerrit, and our current review process a mess. I agree that smaller commits
5 matches
Mail list logo
