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
-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
_ip)
If you are including 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/~o
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 allo
om as the last editor.
Looks like there's work at standardizing vocabulary there.
Anne
On Thu, Oct 20, 2011 at 6:53 AM, Aaron Lee
mailto:aaron@rackspace.com>> wrote:
Adding dependancies between tests is going to create a maintenance and
communication headache later. If the
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 ar
6 matches
Mail list logo
