On Wed, Apr 16, 2008 at 4:37 AM, Jason R. Coombs <[EMAIL PROTECTED]> wrote: > > Gaëtan, > > Would you care to comment on my latest suggestion?
Sorry, it's been on my TODO list for days... And the reason I didn't answer is that it's not a simple "okay, this looks good, I'll apply it"). > I hope I haven't offended you. Hell no. Don't worry :) > On Apr 7, 8:15 pm, "Jason R. Coombs" <[EMAIL PROTECTED]> wrote: > > I've made another update to the elixir trac ticket with another > > proposed patch. (seehttp://elixir.ematia.de/trac/ticket/39). Well, honestly, I don't like this solution for two reasons. First, I don't think it should work by default (ie, if the user doesn't specify anything special) as I think there are more chances to do this by mistake than on purpose, so there should be some kind of safeguard against this. On the other hand that case seem too uncommon to warrant a new option, so I'm a bit stuck. Secondly because the code you propose could produce even more conflicts (the generated name could step on another column) and those would be even more confusing because they happen behind the user's back. The best solution I can come up with, which is incidentally what you described (but rejected) in your comment in the bug report, is to allow the ManyToOne to use one (or more) user-defined column(s). This solution seems both cleaner and more generic. That way, users could simply define the column in any way they like. This could also be useful for other situations and possibly a nicer alternative to the column_kwargs thing which I've always thought it looked a bit awkward. The only problem I see with this approach (I didn't think about it at first but you pointed it out in your comment) is that it's unclear what happens with the ForeignKey. But after some thought, I don't think it's a problem, it's just something we need to decide and clarify in the documentation when we implement that new capability. The suggest the following syntax for this: class B(Entity): a_id = Field(Integer, colname='a', ForeignKey('a.id')) a = ManyToOne('A', column=a_id) or would "field=a_id" be more logical? As for the ForeignKey issue, I suggest that the foreignKey is left to the user to define, though I'm really not sure about this point. I should think more about the pro and cons of this... -- 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 -~----------~----~----~----~------~----~------~--~---
