Kirk Strauser wrote: > > > > But Invoice doesn't have both of those columns. It has a String reference > to > Customer, while BillingInfo has an Integer reference to Customer [1]. > That's > why I ended up with the cyclic relation, and wouldn't otherwise need to > involve Customer at all.
oh, its the string. OK so dont do ForeignKeyConstraint, but definitely add to the Invoice.BillingInfo relation() all the information needed within the primaryjoin to select the correct row. seems like it would be (pseudocode) "invoice.pay2addrid=billing.pay2addrid AND invoice.custinfo=select(customer.stringname).where(customer.id==billing.custid)". The subquery should work and I don't see another way to get around that. Alternatively, you could set "uselist=False" on the Invoice.BillingInfo relation() and then filter it through a descriptor, if the total number of BillingInfo objects per per pay2addrid is not great. > > [1] Again, legacy. The numeric primary key was added *relatively* > recently > and new tables use it. At this exact moment, we have both String and > Integer > references to the Customer table. This whole mess is based on data that > are > copied from Visual FoxPro tables on an hourly basis, and all new code is > written to query PostgreSQL instead of VFP. > -- > Kirk Strauser > > > > --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
