on deprecation of ManyToMany column_format

[Jason R. Coombs]

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).

For example,

class Movie(Entity):
# primary keys and fields defined here

class Director(Entity):
# primary keys and fields defined here
movies = ManyToMany('Movie', column_format="%(key)s")

class SuperHero(Entity):
# primary keys and fields defined here
movies = ManyToMany('Movie', column_format="%(key)s_%(entity)s")

While I acknowledge that this database design is not regular, it's not
unreasonable to think that such a database might have been engineered.

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.

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)? Is it possible that the
local_colname and remote_colname could also support format strings?

Or is it possible that I've misunderstood the usage, and this
deprecation isn't an issue at all?

[Gaetan de Menten]

On Mon, Nov 23, 2009 at 22:16, Jason R. Coombs <jar...@jaraco.com> 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

[Jason R. Coombs]

On Nov 24, 2:43 am, Gaetan de Menten <gdemen...@gmail.com> wrote:
> On Mon, Nov 23, 2009 at 22:16, Jason R. Coombs <jar...@jaraco.com> 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.