Ryan D Johnson wrote:
Peter Rabbitson <[EMAIL PROTECTED]> writes:
luke saunders wrote:
The other thing that gets me about this patch is that the max symbol
length isn't something that's specific to the DBIC parser but more the
target database, so should reside in the producers. That way the
producers can set the max lengths to whatever they require, if
anything.
Furthermore, at least one producer (SQLite) defines a shorter
max_symbol length of 30(?), leading to key clashes - they are visible
in the current dbic test suite in a TODO at t/81transactions (when
executed with DBICTEST_SQLT_DEPLOY=1). I did some early work on this 4
days ago, contemplating about moving the code into SQLT, making it a
pluggable utility sub, but got distracted by other stuff.
If we went this route, presumably the DBIC parser would just leave the
name off altogether when creating constraints and indices?
No, I would still generate it in the parser using the stable algorithm
currently in place. However the truncation/uniqueness algorithm is borked both
in the parser and in all the producers (they all use a variation of the same
inefficient algorithm). The test case I mentioned above is a prime example of
the latter case - sqlite's producer ends up generating identically named
constraints.
_______________________________________________
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]
