On 4/17/07, Michael Bayer [EMAIL PROTECTED] wrote:
On Apr 10, 2007, at 10:22 AM, Gaetan de Menten wrote:
By the way, should I create a ticket for this?
ive created ticket #541 for this,
I had already created ticket #531 for this. Sorry for not mentioning
it here (I thought you'd see it).
On Apr 17, 2007, at 2:49 PM, Gaetan de Menten wrote:
I had already created ticket #531 for this. Sorry for not mentioning
it here (I thought you'd see it). Anyway, it can be closed too now :).
oh crap, sorry, i did a quick search thru track for filtered and
nothing came up. yeah im
On Apr 13, 2007, at 12:51 PM, [EMAIL PROTECTED] wrote:
haven't thought yet of where/how to hack this...
i may have to abandon *-to-many-relations() alltogether, as i don't
want/need them loaded - only filtered at view-time.
or can i make some super- (or sub-) relation thing (propertyLoader?)
On 4/10/07, Michael Bayer [EMAIL PROTECTED] wrote:
hm, why is from_attr a classmethod ?
Because that way, you don't have to specify the related class at all,
and you can specify the parameters as args not kwargs. See my first
initial remark:
* I've implemented Query.from_attr, instead of
is from_attr makeing sense for plain atributes, e.g. integers ot
whatever?
if no, maybe choose something like from_relation or filter_relation or
filter_relation_tomany or similar if it is expected to only work over
relations - and multiple-instances relations; i.e. it is useless over
single
On 4/11/07, svilen [EMAIL PROTECTED] wrote:
is from_attr makeing sense for plain atributes, e.g. integers ot
whatever?
You got a point here. It doesn't work (or even make sense) on plain attributes.
if no, maybe choose something like from_relation
Fine with me.
or filter_relation or
On 3/31/07, Michael Bayer [EMAIL PROTECTED] wrote:
On Mar 31, 2007, at 1:17 PM, Gaetan de Menten wrote:
That's approximately what I did in my patch with the new params
keyword argument, except I only implemented the set operation, not
the add operation on the params. Anyway, what
can u give some exampe, how this is supposed to be used (finaly)?
as relation and/or directly as Query()
On Tuesday 10 April 2007 17:22:45 Gaetan de Menten wrote:
On 3/31/07, Michael Bayer [EMAIL PROTECTED] wrote:
On Mar 31, 2007, at 1:17 PM, Gaetan de Menten wrote:
That's approximately
On 4/10/07, svilen [EMAIL PROTECTED] wrote:
can u give some exampe, how this is supposed to be used (finaly)?
as relation and/or directly as Query()
Attached is a simple example. The setup is done using Elixir but the
actual Query.from_attr usage would be the same with plain SA. If you
really
On Apr 10, 2007, at 10:22 AM, Gaetan de Menten wrote:
In case anybody is interested, here is my patch slightly modified with
what you suggest above. Now it works wonders for both lazy and eager
relationships. There is something ugly about it though: imports. I
have to import the LazyLoader
hm, why is from_attr a classmethod ? not very consistent with all
the other generative methods ? can we have a regular generative
method as well ?
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
sqlalchemy
On Mar 31, 2007, at 1:17 PM, Gaetan de Menten wrote:
That's approximately what I did in my patch with the new params
keyword argument, except I only implemented the set operation, not
the add operation on the params. Anyway, what can/should I do to get
this included? Do you have any
On 3/26/07, Michael Bayer [EMAIL PROTECTED] wrote:
(and whether that be a .query() or Query() or SelectResults not big
difference imo.)
i vote Query().
I tried to implement it but I couldn't do it the way I wanted to. The
problem is: how do I construct a clause from a clause with bind
On 3/23/07, Michael Bayer [EMAIL PROTECTED] wrote:
OK, this is actually something people have asked for a lot. in the
beginning, recently, etc. also for different reasons...i.e.
convenience, or performance, etc. So, first off let me start by
illustrating how this use case is done right
And by the way, if you agree with that direction of things, I'd
happily work on a patch for the query-on-relation thing.
On 3/26/07, Gaetan de Menten [EMAIL PROTECTED] wrote:
On 3/23/07, Michael Bayer [EMAIL PROTECTED] wrote:
OK, this is actually something people have asked for a lot. in
On Mar 26, 2007, at 6:15 AM, Gaetan de Menten wrote:
though, as a user, I'd prefer the first solution.
Wouldn't that be possible? I think it should be. You only need to keep
the deferred approach of the InstrumentedList that I demonstrated in
my patch, so that the whole list is not
i vote Query().
No surprise there ;-)
Me too, +1
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
sqlalchemy group.
To post to this group, send email to sqlalchemy@googlegroups.com
To unsubscribe from this
OK, this is actually something people have asked for a lot. in the
beginning, recently, etc. also for different reasons...i.e.
convenience, or performance, etc. So, first off let me start by
illustrating how this use case is done right now. Assuming your
Address mapper has a
18 matches
Mail list logo
