[DBIx-Class-Devel] [dbsrgits/sql-translator] Add index length option for MySQL (#68)

[M Conrad]

(gave it a review)

Well, I would say that the one change to the public API is that Index->fields can now return hashrefs, so it isn't 100% backward compatible.  Someone could be trying to special-case something by grepping the list of fields for a string and that code would stop working.

It's not necessarily a bad incompatibility though.  The hashrefs only show up if there were details in the index spec that were previously missing, which is current buggy behavior that most people should be happy to have fixed.

Two small bugs - I think the comparison of fields in Index.pm ```around => 'equals'``` should just do a deep-equals instead of enumerating attributes, and you left a ```print STDERR``` in Index.pm ```fields_with_lengths```.

Also, I noticed on the Producer/SQLite.pm that it has a comment of stripping off ```\(\d+\)``` from field names.  Does that mean some parsers include the sizes in the text of the field names?  If so, the parsers need updated.

Further food-for-thought, what do you think about making the index fields into objects that stringify into the field name?  (or stringify into the same string that was passed to the constructor, for more precise backward compatibility?)  Then existing code that does string compares would continue to work, and the 'equals' behavior could be implemented on the object.  The downside is that it would affect all fields and be more likely to break someone's special cases when inspecting ``->fields``

-- 
Reply to this email directly or view it on GitHub:
https://github.com/dbsrgits/sql-translator/pull/68#issuecomment-1597418360
You are receiving this because you are subscribed to this thread.

Message ID: <dbsrgits/sql-translator/pull/68/c1597418360 at github.com>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.scsys.co.uk/pipermail/dbix-class-devel/attachments/20230619/26233e7a/attachment.htm>