My add_assoc function now looks like:
def add_assoc(name, own, other, on_table):
table = own.mapper.tables[-1]
other_table = other.mapper.tables[-1]
primaryjoin = table.join(on_table).onclause
secondaryjoin = other_table.join(on_table).onclause
relation = sqla.relation(other.mapper, on_table, primaryjoin=primaryjoin,
secondaryjoin=secondaryjoin, lazy=False)
own.mapper.add_property(name, relation)
Btw. I've got a really strange caching issue in conjunction with this.
To give you a picture. I've got content beeing the base of everything I build an
url for. So this has a title. I derive page and from page I derive linklist.
Linklist references pages. When I go to a specific linkist which gets its title
from the content table, the title doesn't get updated when I change the content
on the database. It's as if the base-class association isn't fetched but
cached.
Quoting Michael Bayer <[EMAIL PROTECTED]>:
> upon reflection (no pun intended), trying to guess the primaryjoin/
> secondaryjoin for these kinds of relationships would require, well I
> dont even know what it would require since I can always think of more
> cases that its ambiguous...so I have instead implemented a check that
> will tell you the join conditions have been determined to be
> ambiguous, and it will include what those conditions are, the
> philosophy being "simple things more automatic, complicated things
> more manual, always detect/raise exceptions to indicate manual is
> needed".
>
> so after reading the conditions it figured out on its own, you can
> just specify the one condition that it isnt figuring out correctly.
> the unit tests now have just the "primaryjoin" specified for a couple
> of the relationships and thats it.
>
>
> On Mar 8, 2006, at 3:56 PM, Michael Bayer wrote:
>
> > OK, I have committed a large group of changes regarding your test
> > case and the test itself is committed in test/inheritance.py
> > InheritTest3, in two versions. committing the objects works,
> > selecting them back works, doing a get_by also works, and compares
> > to the original object. explicit primaryjoin and secondaryjoin
> > conditions are still required at this time, will see what I can do
> > on that front.
> >
> > On Mar 8, 2006, at 12:49 PM, Florian Boesch wrote:
> >
> >> Yes right I tried it just now. Altough taking away lazy=False
> >> makes the
> >> exceptions go out of my face, it is still not correct. The join
> >> over the
> >> intermediate table gives me all entries from the intermediate
> >> instead of just
> >> the ones associated with the one instance I'm querying them from.
> >>
> >> Quoting Michael Bayer <[EMAIL PROTECTED]>:
> >>
> >>> Your test program, which is also becoming a unit test, works if you
> >>> convert the eager loads to lazy loads. both problems are related to
> >>> the formulation of an eager load against a parent object, which also
> >>> has an inheritance relationship to the thing you are eager
> >>> loading...there are a few places it gets confused. its not related
> >>> to Oracle.
> >>>
> >>> now the tricky part, is getting the eager loads to work. I will
> >>> have
> >>> to do some more tinkering with the fundamentals of "mapper
> >>> inheritance" to get it going.
> >>>
> >>> On Mar 8, 2006, at 9:52 AM, Florian Boesch wrote:
> >>>
> >>>> Hi, I've analyzed my previous problem and boiled it down to a test
> >>>> program
> >>>> (atached).
> >>>> There's two issues connected to it both visible in the test
> >>>> programm as
> >>>> appended tracebacks.
> >>>>
> >>>> To the basic principle. I have three tables, one base table, one
> >>>> table that in
> >>>> herits base and antother table that inherits the one that inherits
> >>>> from base.
> >>>> Expressed in more simple terms, I've got A, B inheriting A, C
> >>>> inheriting B.
> >>>>
> >>>> On why I do such wicked things: Say I've got something like
> >>>> content. So there's
> >>>> page content. But there can be different kinds of pages, like a
> >>>> Link list, a
> >>>> news teaser etc. So page would inherit content, and news teaser
> >>>> would inherit
> >>>> page. On the other hand there can be products, which also inherit
> >>>> content. So
> >>>> there you are.
> >>>>
> >>>> Cheers,
> >>>> Florian
> >>>> <inheritance_test.py>
> >>>
> >>>
> >>
> >>
> >>
> >>
> >> -------------------------------------------------------
> >> This SF.Net email is sponsored by xPML, a groundbreaking scripting
> >> language
> >> that extends applications into web and mobile media. Attend the
> >> live webcast
> >> and join the prime developer group breaking into this new coding
> >> territory!
> >> http://sel.as-us.falkag.net/sel?
> >> cmd=lnk&kid=110944&bid=241720&dat=121642
> >> _______________________________________________
> >> Sqlalchemy-users mailing list
> >> Sqlalchemy-users@lists.sourceforge.net
> >> https://lists.sourceforge.net/lists/listinfo/sqlalchemy-users
> >
> >
> >
> > -------------------------------------------------------
> > This SF.Net email is sponsored by xPML, a groundbreaking scripting
> > language
> > that extends applications into web and mobile media. Attend the
> > live webcast
> > and join the prime developer group breaking into this new coding
> > territory!
> > http://sel.as-us.falkag.net/sel?
> > cmd=lnk&kid=110944&bid=241720&dat=121642
> > _______________________________________________
> > Sqlalchemy-users mailing list
> > Sqlalchemy-users@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/sqlalchemy-users
>
>
-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
_______________________________________________
Sqlalchemy-users mailing list
Sqlalchemy-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sqlalchemy-users
