Gaetan de Menten wrote: > So, basically I wonder what I should do about it: > - keep the feature "as-is" and just document it. > - expand the feature so that options are inherited even if the child > class set some options (obviously if they set an option which is also > set in the parent, that option get overridden). This might be nice as > I find in my models than more often than not an option which apply on > a parent, also applies to its child. By the way, this would be the > behavior we'd have if we had chosen to set option via special class > attributes (like __tablename__ = ...). > - remove that "feature" entirely. This is probably the safest bet. > - only allow option inheritance for some options and not others. This > might be too confusing, but without this, you couldn't set some > options (like tablename) on the parent without setting it on the > child.
Out of these options, I'd go with removing the feature entirely. Its not documented, and the way it works now isn't really practical in my opinion. If we wanted to implement something like this behavior in a documented way, I'd suggest adding an option to using_options that specified that you *want* to "inherit" your options from your parent class. -- Jonathan LaCour http://cleverdevil.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 -~----------~----~----~----~------~----~------~--~---
