On Mon, Nov 23, 2009 at 22:16, Jason R. Coombs <[email protected]> wrote: > I don't quite understand the motivation for deprecating column_format > in favor of explicit column names. > > I see the value of local and remote column naming. I also see the > value in M2MCOL_NAMEFORMAT. > > But by deprecating column_format, a gap in functionality is created, > where one might like to specify the local and remote column names per > M2M table, but would like to define them without duplicating content > (i.e. relative to the Entities they reference).
> While I acknowledge that this database design is not regular, it's not > unreasonable to think that such a database might have been engineered. "might have been" is usually not a good enough reason to keep a feature. If you (or anybody) have a real database where this kind of stuff is useful, I'll happily put the feature back. Besides, the only use case where Elixir adds some value (compared to "declarative") is when one generates a new database. So I don't care that much anymore for "legacy" databases, except if they have been generated by Elixir, or if there is a concrete need. > As I understand it, future versions of Elixir will require > column_format to be replaced by explicit remote_colname and > local_colname references, which will create additional dependencies > that will have to be maintained manually for consistency. For example, > if the name of the SuperHero class were to be changed, the > column_format would also have to be changed accordingly, whereas with > column_format, this was not necessary. You are correct: they could need to be changed indeed, but that might not be necessary, or even desirable, if the user don't want to update the database underneath, and even if they need to be changed, I don't see this as a huge problem. > The M2MCOL_NAMEFORMAT option will not help much in this case. It will > allow one class to have column names defined relative to the related > class objects, but all others must be assigned explicitly. While this > option encourages better database design, it teases Elixir users by > when the database can't be made regular by making a format string > available, but only globally. > > Is there a reason that column_format must be deprecated (is the > implementation unnecessarily messy for it)? No, there is no implementation problem. It's rather that: 1) I didn't think about the use case you mentioned above (or I didn't think it would make sense to support, I don't remember) so I thought the feature was obsolete. 2) I'd like to avoid feature creep as much as possible, so I deprecated it. > Is it possible that the > local_colname and remote_colname could also support format strings? That could be an option. Haven't thought about that. For what it's worth, at an undefined point in the future, I'll make all the "pattern options" (such as M2MCOL_NAMEFORMAT) definable on a per-base class basis (or even per entity, not sure yet), so that should alleviate your problem, since you will be able to define an abstract class which store a different set of patterns, and use those as needed. -- 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.
