i have some heretical thought about this...
my context is: i have a many2many relation, which is always used as a
one to many for one particular item; i.e. an additionaly filtered
many2many by a runtime argument. e.g. imagine those users <->
addresses, but always used as "addresses for a particular user", and
not used backwards.
so... there is a relation that contains vast number of items, but only
a subset of that is visible/used, at any certain scope of usage.
so i thought that a similar pattern is already there with the mappers:
u have a mapper over whatever local-table, but when used for
selection, it uses another selectable instead (maybe a
subset/superset of the localtable).
Thus said, can i define a relation which has the usual primaryjoin +
whatever full-description, and has some additional runtime filtering
criteria - or replacement primaryjoin - or whole replacement query -
to be used for viewing/reading (once initialised, and fallback to
query-everything when no filter)
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?)
that does the above?
Any opinions?
svilen
On Wednesday 11 April 2007 22:36:43 Michael Bayer wrote:
> On Apr 11, 2007, at 4:50 AM, Gaetan de Menten wrote:
> > looks better, is shorter and is more readable than:
> >
> > Query('Address', instance=someuser, attr_name='addresses')
>
> Ive no problem with the classmethod being present and i dont want
> people using Query's constructor in general.
>
> > And second, I think it could be quite confusing for a user.
> > Imagine that Query(A).from_attr(inst, 'rel') could return
> > instances of B (or whatever class is attached to the relation)...
> > Probably not what you'd expect.
>
> that should raise an exception, if the given instance/relationship
> pair does not match the query's main entity. theres also the
> possibility that we could "add" the entity in using add_entity()
> but lets not go there for now.
>
> generally, any method on Query which generates a SQL clause is
> potentially useful in a generative sense...since any SQL clause is
> always useful as part of a larger SQL clause.
>
> > And by the way, from_attr doesn't sound like a generative method,
> > so if you want it, what about "filter_from_attr", or something
> > similar?
>
> what it really is, is like "with_parent" (to paraphrase an
> SQLElixer term). using the standard User->Address relation, I say
> session.query(Address).with_parent(someuser, relation='addresses').
> additionally, the "addresses" string which marks the name of the
> attribute on User that points to Address should be optional, if it
> can be automatically determined from the existing relationships
> between User and Address. (if there is *any* ambiguity though,
> like two relations on user that point to address, it should raise
> an error). So people can say (as I myself find myself wanting to
> say), session.query(Address).with_parent(someuser).filter_by
> (email='[EMAIL PROTECTED]'). right now I have mentioned the "trick" that
> uses backrefs to get the same effect, this is more convenient since
> it isnt forcing a backref to exist just to generate a certain
> query.
>
>
>
>
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"sqlalchemy" group.
To post to this group, send email to [EMAIL PROTECTED]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/sqlalchemy?hl=en
-~----------~----~----~----~------~----~------~--~---
