On Thu, May 15, 2008 at 10:53:20AM -0700, Ryan D Johnson wrote:
> The specific problem with the old naming code was that it was
> unstable. I might have a constraint foo today which tomorrow the sqlt
> layer decided to name foo_2 (because there's a new constraint it wants
> to name foo). This is bad for exactly the same reasons that changing
> from the old naming code to the new naming code sucks.
The SQLT diffing code needs to compare a hash of the -nature- of the
constraint instead of the name.
Then constraints can be renamed at will, and the code can go "well, eh,
the constraint/index is called X here but who cares?". Think of it as
somewhat similar to diff's ignore whitespace option.
Then you can use unstable naming, stable naming, we can bugfix the naming
in future (the new one won't be perfect, it never is first time :), and
who fucking cares.
Fancy having a go? You were right to not try and maintain compat within
the changes you made but we -do- need to fix forward compatibility for the
upgrade path.
--
Matt S Trout Need help with your Catalyst or DBIx::Class project?
Technical Director http://www.shadowcat.co.uk/catalyst/
Shadowcat Systems Ltd. Want a managed development or deployment platform?
http://chainsawblues.vox.com/ http://www.shadowcat.co.uk/servers/
_______________________________________________
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]
