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

[John Goulah]

On Thu, May 15, 2008 at 9:40 AM, luke saunders <luke.saunders at gmail.com> wrote:
> On Thu, May 15, 2008 at 2:24 PM, Ash Berlin <ash_cpan at firemirror.com> wrote:
>>
>> On 15 May 2008, at 14:08, luke saunders wrote:
>>>
>>> What were these cases? Is that not just a bug with the unique symbol
>>> generator in the producer?
>>
>> I'm not sure of the exact cause any more, but I think it was to do with
>> multi-col unique constraints and FKs - i.e. if you have a unique across two
>> cols, and one of those is a FK constraint also, it would just barf - the 2nd
>> and 3rd changes in the diff. Previously it was just using the first column
>> name, which caused problems.
>>
>
> So presumably it was barfing because the names were the same right?
> Which would be fixed if the producer just named the duplicate '*_2'.
> It already does that with FK names so shouldn't be hard to enforce the
> same rule globally.
>

Right, the general problem was that it emitted two indexes with the
same name. I believe there were two cases:

-  a duplicate index name emitted because the same field was used in a
unique constraint and a foreign constraint
-  a two-field foreign key to one table where one of the fields was
also fk to another table


When I helped rdj through fixing this, I encouraged him to keep
backward compatibility which he didn't do.   I'd say breaking backward
compat is a -really bad idea-  for large production databases.
Dropping and re-adding constraints is not a fast operation on large
tables.

Thanks,
John