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?

_______________________________________________
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]

Reply via email to