2011/11/29 Jay Pipes :
> On Tue, Nov 29, 2011 at 3:43 PM, Soren Hansen wrote:
>> 2011/11/29 Jay Pipes :
Besides, we don't really use transactions. I could easily read the
same data from two separate nodes, make different (irreconcilable)
changes on both nodes, and write them back, a
On Tue, Nov 29, 2011 at 3:43 PM, Soren Hansen wrote:
> 2011/11/29 Jay Pipes :
>>> Besides, we don't really use transactions. I could easily read the
>>> same data from two separate nodes, make different (irreconcilable)
>>> changes on both nodes, and write them back, and the last one to write
>>>
2011/11/29 Jay Pipes :
> On Tue, Nov 29, 2011 at 2:58 PM, Soren Hansen wrote:
>> 2011/11/29 Jay Pipes :
>>> There's a very good reason this hasn't happened so far: handling
>>> highly relational datasets with a non-relational data store is a bad
>>> idea. In fact, I seem to remember that is exactl
On Nov 29, 2011, at 11:55 AM, Vishvananda Ishaya wrote:
… some stuff I agree with, then...
> something like db.interfaces_get_by_instance(id, hint='fixed_ip'),
This is very similar to ActiveRecord. In a case like this you would say
Instance.find(id, :include => :fixed_ip)
If you are includin
On Tue, Nov 29, 2011 at 2:58 PM, Soren Hansen wrote:
> 2011/11/29 Jay Pipes :
>> There's a very good reason this hasn't happened so far: handling
>> highly relational datasets with a non-relational data store is a bad
>> idea. In fact, I seem to remember that is exactly how Nova's data
>> store st
2011/11/29 Jay Pipes :
> There's a very good reason this hasn't happened so far: handling
> highly relational datasets with a non-relational data store is a bad
> idea. In fact, I seem to remember that is exactly how Nova's data
> store started out life (*cough* Redis *cough*)
To be fair, we're on
On 29 Nov 2011 - 13:15, Jay Pipes wrote:
> On Tue, Nov 29, 2011 at 10:49 AM, Jason K??lker
> wrote:
> > On Tue, 2011-11-29 at 16:20 +0100, Soren Hansen wrote:
> >>
> >> It seems I've talked myself into preferring option e). It's too much
> >> work to do on my own, though, and it's going to be dis
2011/11/29 Vishvananda Ishaya :
> On Nov 29, 2011, at 11:16 AM, Soren Hansen wrote:
>> The way I'd attack these expensive-if-done-one-at-a-time-but-dirt-cheap-
>> if-done-as-one-big-query is to have a method in the generic layer that
>> is taylored for this use case. E.g.
>>
>> def instances_get_al
Inline
On Nov 29, 2011, at 11:16 AM, Soren Hansen wrote:
> 2011/11/29 Vishvananda Ishaya :
>> e) is the right solution imho. The only reason joinedloads slipped in is
>> for efficiency reasons.
>>
>> In an ideal world the solution would be:
>>
>> 1) (explicitness) Every object or list of rela
2011/11/29 Chris Behrens :
> e) sounds good as long as we don't remove the ability to joinload up
> front. Sometimes we need to join. Sometimes we can be lazy. With
> 'list instances with details', we need to get all instances from the
> DB and join network information in a single DB query. Doi
2011/11/29 Vishvananda Ishaya :
> e) is the right solution imho. The only reason joinedloads slipped in is for
> efficiency reasons.
>
> In an ideal world the solution would be:
>
> 1) (explicitness) Every object or list of related objects is retrieved with
> an explicit call:
> instance = db.i
+1 on the thoughts here. Exactly what I meant by my reply. Not sure what the
interface should look like for #2, but we must be able to do it somehow.
- Chris
On Nov 29, 2011, at 11:55 AM, Vishvananda Ishaya wrote:
> e) is the right solution imho. The only reason joinedloads slipped in is for
I like e).
I know it's heresy in some circles, but this approach can also support
the use of SqlAlchemy core, without the use of the SQLAlchemy ORM.
It's more work in some respects, but does allow writing very efficient
queries.
mike
On Tue, Nov 29, 2011 at 9:55 AM, Vishvananda Ishaya
wrote:
>
On 29 Nov 2011 - 17:54, Aaron Lee wrote:
> For this I think we need to separate the models from the queries.
+1
> 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
+10
On Tue, Nov 29, 2011 at 12:55 PM, Vishvananda Ishaya
wrote:
> e) is the right solution imho. The only reason joinedloads slipped in is for
> efficiency reasons.
>
> In an ideal world the solution would be:
>
> 1) (explicitness) Every object or list of related objects is retrieved with
> an
On Tue, Nov 29, 2011 at 10:49 AM, Jason Kölker wrote:
> On Tue, 2011-11-29 at 16:20 +0100, Soren Hansen wrote:
>>
>> It seems I've talked myself into preferring option e). It's too much
>> work to do on my own, though, and it's going to be disruptive, so we
>> need to do it real soon. I think it'l
e) is the right solution imho. The only reason joinedloads slipped in is for
efficiency reasons.
In an ideal world the solution would be:
1) (explicitness) Every object or list of related objects is retrieved with an
explicit call:
instance = db.instance_get(id)
ifaces = db.interfaces_get_by
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
I'm really glad to hear all these votes for e), 'cause that's what I'd
like to see too :-)
d
On 29 Nov 2011 - 11:18, Brian Waldon wrote:
> I think option e is our best bet. It's the *only* option if we want to
> efficiently separate our services (as Jason has pointed out).
>
> Waldon
>
>
> On Nov
e) sounds good as long as we don't remove the ability to joinload up front.
Sometimes we need to join. Sometimes we can be lazy. With 'list instances
with details', we need to get all instances from the DB and join network
information in a single DB query. Doing 1 + (n*x) DB queries to suppo
On Tue, 2011-11-29 at 16:20 +0100, Soren Hansen wrote:
> It seems I've talked myself into preferring option e). It's too much
> work to do on my own, though, and it's going to be disruptive, so we
> need to do it real soon. I think it'll be worth it, though.
(e) sounds right to me. But hopefully d
I think option e is our best bet. It's the *only* option if we want to
efficiently separate our services (as Jason has pointed out).
Waldon
On Nov 29, 2011, at 10:52 AM, Devin Carlen wrote:
> Hey Soren,
>
> On Nov 29, 2011, at 7:20 AM, Soren Hansen wrote:
>
>> SQLAlchemy does support looking
Hey Soren,
On Nov 29, 2011, at 7:20 AM, Soren Hansen wrote:
> SQLAlchemy does support looking these things up on the fly. In fact,
> AFAIK, this is its default behaviour. We just override it with
> joinedload options, because we don't use scoped sessions.
>
> My fake db driver looks stuff like t
On Tue, 2011-11-29 at 16:20 +0100, Soren Hansen wrote:
>
> It seems I've talked myself into preferring option e). It's too much
> work to do on my own, though, and it's going to be disruptive, so we
> need to do it real soon. I think it'll be worth it, though.
I agree. This will also make it eas
Soren:
On Nov 29, 2011, at 10:20 AM, Soren Hansen wrote:
[snip]
>
> Or should we do away with this stuff altogether? I.e. no more looking up
> related objects by way of __getitem__ lookups, and instead only allow
> lookups through db methods. So, instead of
> network['virtual_interfaces'], you'd
Hi, guys.
Gosh, this turned out to be long. Sorry about that.
I'm adding some tests for the DB api, and I've stumbled across something
that we should probably discuss.
First of all, most (if not all) of the various *_create methods we have,
return quite amputated objects. Any attempt to access r
26 matches
Mail list logo
