On Nov 24, 2:43 am, Gaetan de Menten <[email protected]> wrote: > On Mon, Nov 23, 2009 at 22:16, Jason R. Coombs <[email protected]> wrote: > > > 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.
I use Elixir to connect to a database which is legacy in the sense that it's not defined canonically in the Python model, but is rather defined by another framework and used secondarily by this package for maintenance and power scripting (something Java doesn't do well). I had the column format used in two ManyToMany definitions in the model. As it turns out, the M2MCOL_NAMEFORMAT will work in this situation, but even making that determination was non-local. I had to search the model and consider the implications. Furthermore, since the canonical schema is defined elsewhere, as the Elixir admin, I would like to have the ability to keep the schema in sync with as little repetition as possible. This is why I chose Elixir in the first place. > > 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. Indeed. It's not a huge problem, but it seems to me contrary to the goals of Elixir, particularly the DRY principle that attracted me to it in the first place. If the information can be inferred from information already present, I think that's a good idea. > > 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. That's entirely reasonable and desirable. Furthermore, I guess edge cases like I've described could be handled with a subclass of ManyToMany. > > 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. I would say that either of these approaches would certainly suit my needs and not offend my sensibilities at all. I'm over-committed with other open source efforts at the moment, or I'd offer to help. I mostly just wanted to express my concern with the deprecation, as it was a feature I found elegant and powerful. As always, thanks for maintaining Elixir. -- 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.
