changeset 2221 addresses the pattern youre doing in test_case3. it
required SA is more strict about matching foreignkey columns in a
relatoinship into the primary join condition, luckily all the unit
tests still pass. this is because youre doing self-referential
relationships on polymorphic mappers...so all the involved tables are
everywhere and its a big mess to figure out what points where.
other random factoids:
lazy=True is the default.
correlate=False not needed in most cases.
foreignkey not needed in most cases. it tells a relationship which
column in the primaryjoin condition is "foreign".
the idea behind SA flags is to start with as few flags as possible
and add in as needed. this conflicts with what youre trying to do,
which involves getting a mapping to work with no manual
experimentation phase. in particular a flag like "post_update"
should only be used if absolutely needed, so it will take some fancy
logic to guess things like that (not to mention, using primaryjoin on
a concrete table mapping...now you need a distinct relation() +
primaryjoin on each concrete mapper, etc.)
concrete inheritance is also hardly implemented, in rev 2221 above i
added a basic unit test thats been hanging around for concrete +
polymorphic. it required i stick a kind of hacky thing in the mapper
to get it to work. which generally means that new variations on
concrete are going to keep failing until a more general method is
worked out. in particular the big issue with concrete is that you
cant really inherit a relation(), since the primaryjoin condition is
going to be different for each submapper. the current method of
relation propigation between inheriting mappers in the 0.3 series is
more or less broken for concrete inheritance....which implies any
real relation propigation with concrete mappers (since im sure youre
going to stick a relation() on a concrete mapper's base mapper if not
already) is going to require major surgery inside the mapper
compilation and a whole boatload of new tests. also i need to get an
SA release out before any work like that starts. unit tests for
concrete are going to live in test/orm/inheritance4.py to start.
as far as "typecolname" i dont like that flag much. using an
explicit setup means you know exactly what youre doing:
p = polymorphic_union({
'foo':select([footable, column("footype").label
('type')]),
'bar':bartable
})
also i tried your polymorphic_union, but since you changed its API it
doesnt pass any of the unit tests. polymorphic_union is intended for
the end-user to manually configure, so it wouldnt have arguments like
"allow_empty_typecolname". however, one reason i like having the
function separate from mapper config is so folks can do exactly what
you did; come up with some other way to make their selection criterion.
On Jan 19, 2007, at 7:32 AM, svilen wrote:
>> and that change is in rev 2214, your two test scripts run
>> unmodified now.
>
> without these changes (pure 0.3.3), adding explicit foreignkey=...
> on all relations worked OK in all 39 cases.
>
> With new changes (trunk/2216), B pointing to A (manager pointing to
> employee) does not work. B pointing to B is ok, A pointing to A or
> B is ok.
> sqlalchemy.exceptions.ArgumentError: Cant determine relation
> direction for 'manager' on mapper 'Mapper|Manager|Manager' with
> primary join '"Manager".manager_id = "Employee".id' - foreign key
> columns are present in both the parent and the child's mapped
> tables. Specify 'foreignkey' argument.
>
> regardless that foreignkey= argument is there.
>
> see attach.
>
> ------
> Thanks for the other changes. Here's a fixed polumunion.py. It is
> best if typecolname there is always given - it will be used only if
> needed (concrete). But by default i've made it fit your present
> protocol.
>
> >
> <test_case3.py>
> <polymunion.py>
--~--~---------~--~----~------------~-------~--~----~
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 [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/sqlalchemy?hl=en
-~----------~----~----~----~------~----~------~--~---
