On Wed, Oct 1, 2008 at 4:16 PM, alex bodnaru <[EMAIL PROTECTED]> wrote: > hi gaetan, > > On Wed, Oct 1, 2008 at 5:10 PM, Gaetan de Menten <[EMAIL PROTECTED]> wrote: >> >> On Wed, Oct 1, 2008 at 4:02 PM, alex bodnaru <[EMAIL PROTECTED]> wrote: >>> On Wed, Oct 1, 2008 at 1:22 PM, Gaetan de Menten <[EMAIL PROTECTED]> wrote: >>>> On Wed, Oct 1, 2008 at 8:47 AM, alex bodnaru <[EMAIL PROTECTED]> wrote: >>>>> On Wed, Oct 1, 2008 at 9:26 AM, alex bodnaru <[EMAIL PROTECTED]> wrote: >>>>>> >>>>>> how could a foreign key reference a unique (but not primary kyey) >>>>>> column combination? >>>>> >>>>> i found it in alchemy: >>>>> >>>>> ForeignKeyConstraint(['invoice_id', 'ref_num'], >>>>> ['invoices.invoice_id', 'invoices.ref_num']) >>>>> >>>>> posted on elixir list too, but expressing it in elixir would help a >>>>> lot, too :) . >>>> >>>> You couldn't do that in Elixir until just now. I just commited a patch >>>> to implement a new target_column argument on ManyToOne (in trunk). >>>> Though I have to warn you, it currently has an important limitation: >>>> it will only work if the target entity is declared before the entity >>>> holding the ManyToOne. I'll have to rethink the whole Elixir's setup >>>> process to allow the other way round. >>>> >>>> See: http://elixir.ematia.de/trac/changeset/405 >>>> >>>> Hope it helps, >>>> >>> hi gaetan, >>> >>> thanks for your prompt answer, with a good solution. >>> that's what i was thinking to try too (well, just the first part with >>> selecting the target columns >>> and creating the source ones that way). >>> >>> i was just wondering, whether invokation of >>> target_desc.create_non_pk_cols() wouldn;t help before >>> copying the target_columns, in the non pk scenario. >> >> That'd be too easy unfortunately... You could end up in an infinite >> loop if you have ManyToOne in both directions between two entities >> (which is a perfectly valid situation). >> > ok, just a superficial thought :) . > >>> next, since the target_columns are not automatically the tarket pk, >>> i'd ask to save them with the >>> relationship. >> >> I don't understand what you mean... >> > i would like the target_columns list of names to be saved in the relationship,
It's already the case: relationship.target_column > so an inverse relationship could be auto made by my inverse_orphans extension. > btw: would complementary non-pk onetomany relationship work too? Haven't tested that yet (I should have but well... forgot to), but there is no reason it wouldn't work, as long as you respect the limitation above. I'll add a test... -- Gaëtan de Menten http://openhex.org --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "SQLElixir" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sqlelixir?hl=en -~----------~----~----~----~------~----~------~--~---
