[Dbix-class] SQL::Translator::Parser::DBIx::Class unique symbol change

[Peter Rabbitson]

Ryan D Johnson wrote:
> Peter Rabbitson <rabbit+list at rabbit.us> 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.