On Thu, May 15, 2008 at 9:40 AM, luke saunders <[EMAIL PROTECTED]> wrote: > On Thu, May 15, 2008 at 2:24 PM, Ash Berlin <[EMAIL PROTECTED]> 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 _______________________________________________ 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]
