for the record, if anyone wants doing such stuff:
there is a many to one reference A.b to B. one day it becomes
bitemporal, i.e. an association A.b to B via A2B table, which
contains other columns that cannot be invented by default values
(timestamps, disabled, etc). Hence, the association has to be
explicit via assoc.object. Still, for the sake of querying across A.b
to B, noone cares about those columns, and the code contains lots of
that plain usage... (in my case there are hundreds of references in
hundreds of classes that became bitemporal...)
a) create the explicit assoc A2B, say b_exp
b) create a descriptor that will handle __get__, __set__, __del__ etc
of single values using the explicit association b_exp
c) create an implicit assoc via same A2B table, view_only=True, say
b_imp; it seems usable that the original backref (if any) is put
here;
d) add synonym() property of the implicit assoc, via the descriptor
above
so the result is:
- print a.b #single B, via the descriptor, in my case latest
non-disabled version
- a.b = someb #works and appends a link to someb using explicit_assoc
- ...
- query(A).join('b') #gives all Bs, jumping across the assoc)
- query(A).filter( A.b.contains(someb)) #works ok
- query(A).join('b_exp') #gives all A2Bs for whatever querying
- a.b_exp.append( ... ) for manual adding of A2B links
thus simulating the single-reference behaviour. for complete
simulation, it needs query(A).filter_by(b=someb) to work. Which needs
a comparator inheriting PropLoader.Comparator, for which _eq_
does .contains() for many2many relations, and eventualy .has
does .any.
may look too magical and too automatic but fits the bill..
all this will go into dbcook.sf.net soon anyway, so check there.
ciao
svilen
On Wednesday 17 December 2008 00:35:03 Michael Bayer wrote:
> On Dec 16, 2008, at 3:04 PM, a...@svilendobrev.com wrote:
> > hi
> > i have a relation say, foo. i want to have another descriptor,
> > bar that does certain other things around that relation, but can
> > be used just in same way as foo can in the aspects of expressions
> > and query-joins.
> >
> > i.e. query(A).join( A.foo) and query(A).join( A.bar)
> > to produce same thing; as well as
> > query(A).filter( A.foo == x) and query(A).filter( A.bar == x).
>
> this is the use case for synonym().
>
> > i managed to get the latter by simulating the PropComparator
> > interface, and i sort of managed to get the join working...
> > but my relation is to an explicit association and i want to hide
> > the explicitness. so i want query(A).join( A.bar)
> > to behave same as
> > query(A).join( A.bar).join( FooAssoc.otherside),
> > or actualy as query(A).join( A.foo) as IF foo was implicit
> > association via secondary table.
>
> ignoring the "A.bar would be 'the same' as A.bar.otherside" portion
> of what you said, since that doesn't make any sense, it seems
> you're asking for A.foo to mean the same thing as A.bar.otherside.
> this seems something like associationproxy plus a
> comparable_property(). have you tried that ?
>
--~--~---------~--~----~------------~-------~--~----~
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 group, send email to
sqlalchemy+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/sqlalchemy?hl=en
-~----------~----~----~----~------~----~------~--~---
