> limited to non_primary mapper ? creating relationships with > non_primary mapper is a bad idea. the "foreignkey" error really > means, "cant find a foreignkey *that I recognize as part of the > parent or child tables*".
i think i found it... i make another plain non-polymorphic non-primary mapper_A1 and use a table_A.select( type=='A').alias() as its localtable. Then, if i add the A's relations to this second mapper, session.query( mapper_A1).select() gives the above error. if i don't add _any_ relations, all seems to work. Beat me why. Does it mean different mappers for same class share _one_ set of relations, of the primary-one? (Looking at sql, they seems to come through the union/primary-mapper, which is correct) okay, i'll keep it like this... Executing above select through the main polymorphic mapperA works too, but the resulting sql is awful as it does the whole union + the select by type. So i stick with having a non-primary. ciao and happy new release ;-) svil just FYI - the tescase (non-primary-mapper-relations.py); see the "if 1:#removing-this-fixes-it"/line 55 inside. $ python non-primary-mapper-relations.py echo > On Jan 23, 2007, at 12:43 PM, svilen wrote: > > while on polymorphic-union mappers vs non-polymorphic.. > > > > i have 3 kinds of type-queries: query_ALL-instances, > > quiery_BASE-instances, quiery_SUB-instances. > > > > First gives me all instances of a class or subclasess thereof, > > and is matching the main polymorphic-union mapper. The 3rd is a > > .select( table.c.typecolumn != base-type), piped through that > > too. > > > > For the 2nd one - getting the direct instances only (no > > subclasses) - i have a choice: > > a) have another non-primary mapper with some select( > > table.c.typecolumn==class_discriminator) as a table > > b) pipe this same select through the the main mapper > > > > So far i'm going the first way, but i'm not sure which one is > > better. Can u give any suggestion? If there are no big penalties > > for b), i will prefer that one; building another mapper was a > > tricky thing - and it does not work right now, for rev 2233. e.g. > > > > For a very simple case, B inh A, A points to self: > > > > ArgumentError: Cant determine relation direction for 'linkA' on > > mapper 'Mapper|A|bz4A|non-primary' with primary join '"bz4A". > > "linkA_id" = "A".db_id' - foreign key columns are present in both > > the parent and the child's mapped tables. Specify 'foreign > > key' argument. > > > > Although the foreignkey _is_ there. i rmember this same error > > hapened before on some other occasion and then it disappeared. > > > > Anyway, if b) will work, i'll abandon it and not debug it to find > > why it breaks - unless you want it found and fixed. > > > > ciao > > svil > > --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
sa_gentestbase.py
Description: application/python
non-primary-mapper-relations.py
Description: application/python
