+1 for solution #1 as well.

--
Jorge Godoy     <[email protected]>


On Tue, Jun 30, 2009 at 9:31 AM, Stefano Fontanelli <
[email protected]> wrote:

>
> On Tue, 2009-06-30 at 12:32 +0200, Gaetan de Menten wrote:
> > Hi people,
>
> Hi Gaetan,
>
> > I'm faced with a tough decision. Here is the problem:
>
> [CUT]
>
> > Here are the solutions I could come up:
> >
> > 1) Produce column names which depend on the relation name for all
> > ManyToMany relationships.
> >
> > Pro:
> >   - Seems logical. This is the pattern I wish I had used in the first
> place.
> >
> > Con:
> >   - Massive breakage when upgrading from older Elixir: all ManyToMany
> > (self-referencial or not) relationships are affected. That is, each
> > developer will need to either:
> >      * use old scheme through setting the global variable
> > "elixir.M2MCOL_NAMEFORMAT" before doing anything else with Elixir.
> > Ugly but effective.
> >      * use local_colname AND remote_colname in every ManyToMany
> relationship.
> >      * update all M2M tables
> >   - We cannot easily detect (at Elixir-level) whether there is a
> > problem or not and thus provide "migration help" automatically. That
> > is, people upgrading without reading the release/upgrade notes (and
> > unfortunately I think most people don't) will be hit by strange
> > "missing column" errors without any clear indication of what to do to
> > fix the problem.
> >   - Breaks if the relationship is renamed. This seems logical and IMO
> > acceptable. In that case, the developer can simply use local_colname
> > for the renamed relationship.
>
> [CUT]
>
> > 4) Use a different pattern to generate columns for self-referential
> > relationships than for non self-referential (ie use solution #1 but
> > only for self-referential relationships).
> >
> > Pro:
> >   - Only breaks self-referencial ManyToMany relationships.
> >
> > Con:
> >   - No way to know there is a problem (see #1).
> >   - A slight case of spaghetti code. But this is also true with the
> > current approach.
>
>
> I prefer solution #1 and #4.
> I think the best design solution is the #1, but I understand upgrading
> problems (I don't understand why people upgrade without reading release
> notes) and a good compromise is the solution #4 (probably, but I prefer
> #1).
>
>
> --
> Ing. Stefano Fontanelli
> PhD Student, Scuola Superiore Sant'Anna
> ReTiS Lab c/o CEIIC
> Via G. Moruzzi, 1
> 56124 Pisa (Italy)
> tel: +39 050 5492010, mobile: +39 333 3653294
> skype: stefanofontanelli
>
>
> >
>

--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---

Reply via email to