On 6/2/07, Michael Bayer [EMAIL PROTECTED] wrote:
On Jun 2, 2007, at 6:02 AM, Gaetan de Menten wrote:
Hmmm, after some more thoughts there is one little aspect of that
which bothers me: once you joined to something, you can't add
filtering criteria on the initial table/class. This is
On Jun 3, 2007, at 8:10 AM, Gaetan de Menten wrote:
- ClauseElement support would be removed from filter_by(). you can
just use filter() for those. the older _by() methods, which i want
to deprecate, would be left alone for backwards compatibility.
What do you replace order_by with?
oh,
IMHO, this solves my use case nicely. It's slightly longer than what I
proposed but doesn't reach my internal this_is_too_long_to_type
threshold and it's more explicit...
So for me it's a +1 for that solution (along with documenting the
joinpoint behavior ;-)).
On 6/2/07, Michael Bayer [EMAIL
On 6/2/07, Gaetan de Menten [EMAIL PROTECTED] wrote:
IMHO, this solves my use case nicely. It's slightly longer than what I
proposed but doesn't reach my internal this_is_too_long_to_type
threshold and it's more explicit...
So for me it's a +1 for that solution (along with documenting the
On Jun 2, 2007, at 6:02 AM, Gaetan de Menten wrote:
Hmmm, after some more thoughts there is one little aspect of that
which bothers me: once you joined to something, you can't add
filtering criteria on the initial table/class. This is actually one of
the features I disliked about the
what about adding a docopy=True (or dont_copy=False) to all methods
that could be both copy_generative and modify-in-place?
via some generic self=self.copy_if_required() func?
Then one can choose at which point to split+copy
let me summarize things that im thinking we do:
- we want to go
what about adding a docopy=True (or dont_copy=False) to all
methods that could be both copy_generative and modify-in-place?
via some generic self=self.copy_if_required() func?
Then one can choose at which point to split+copy
well if you have switches that are dynamically modifying the
On Jun 1, 2007, at 12:39 PM, Gaetan de Menten wrote:
This enables things like so (see attached elixir-based example for
more):
A.query().filter_by_via('b', name='b2').filter_by_via('c',
name='c2')
To Michael: I'm ready to document that myself, but I just don't want
to do it for
On Jun 1, 2007, at 1:24 PM, Michael Bayer wrote:
and we can even bring back a modified version auto-descend in that
case:
query(A).filter_by(C, lala=5)
since above its not ambiguous.
actually, scratch that. C can be related to multiple times. also
its ambigious if you want autojoin
OK, irc continues, now i see what youre getting at, its this:
query.filter_by(['a', 'b', 'c'], foo=bar)
query.filter_by('c', foo=bar)
i didnt pick up on the list part from the example.
that feature specifically starts to look like a django join. the
'join list' at the front is contained
On Friday 01 June 2007 21:38:15 Michael Bayer wrote:
On Jun 1, 2007, at 1:24 PM, Michael Bayer wrote:
and we can even bring back a modified version auto-descend in
that case:
query(A).filter_by(C, lala=5)
since above its not ambiguous.
actually, scratch that. C can be related to
On Jun 1, 2007, at 5:33 PM, [EMAIL PROTECTED] wrote:
heh, if i remember how whole-heartly u defended this autodescend thing
some months ago...
we didnt have generative behavior built into query so there was no
way to conveniently get at an attribute based on a join.
and more IMO, i
plus *another* option to think about here, which was actually my
first (suppressed) instinct, but now i just saw that Hibernate sort
of does this, is to *keep* the joinpoint in and just have the
join function reset the joinpoint on each invocation.
so,
session.query(User).join(['orders',
13 matches
Mail list logo
