[Dbix-class] SQL::Translator::Parser::DBIx::Class unique symbol change

[luke saunders]

On Thu, May 15, 2008 at 1:48 PM, Ash Berlin <ash_cpan at firemirror.com> wrote:
>
> On 15 May 2008, at 13:28, luke saunders wrote:
>
>> The change shown here:
>>
>> http://dev.catalyst.perl.org/svnweb/bast/diff/DBIx-Class/0.08/trunk/lib/SQL/Translator/Parser/DBIx/Class.pm?rev1=4247;rev2=4248
>>
>> Is causing many constraint add/drops in our schema diff such as:
>>
>> ALTER TABLE table_name DROP FOREIGN KEY table_name_fk_fk_user_id,
>>          ADD CONSTRAINT table_name_fk_fk_user_id_fk_battle_id
>> FOREIGN KEY (fk_user_id, fk_battle_id) REFERENCES other_table
>> (fk_user_id, fk_battle_id) ON DELETE CASCADE;
>>
>> Because the constraint names have all changed in a way that isn't
>> backwards compatible. This is undesirable as running many of these on
>> a large production database is time consuming.
>>
>> So what is the goal of this change? There already exists code in the
>> MySQL producer for ensuring the foreign key names are unique, would we
>> not be better off extending that to apply across all constraints and
>> indexes? Other producers should then have similar code to meet their
>> own requirements.
>
> Yes but it didn't work. There were cases where it would still attempt to
> produce duplicate names.
>

What were these cases? Is that not just a bug with the unique symbol
generator in the producer?

> My personal feeling is that this code should stay, and that you'd either
> need to manually name all your constraints (if its even possible?) Or more
> likely, given the size of your schema, add some switch to bring back the old
> behavour?

A switch would do but isn't ideal. Kind of feels that we're hacking
around the problem here though.