On Thu, May 15, 2008 at 1:48 PM, Ash Berlin <[EMAIL PROTECTED]> 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. _______________________________________________ List: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/dbix-class IRC: irc.perl.org#dbix-class SVN: http://dev.catalyst.perl.org/repos/bast/DBIx-Class/ Searchable Archive: http://www.grokbase.com/group/[EMAIL PROTECTED]
