Join GitHub today
TagTreeModel not compatible with MySQL #1
Thanks for finding that! There are a couple of options, but the main issue this raises for me is that of slug and path length limits.
To fix this issue we could change it to a CharField and make the maximum length of a path 255, or simply remove the
For now, I've hand-edited my migration to change the field to a
I agree that the path field probably doesn't need to be unique, but if it
On Fri, Oct 16, 2015 at 9:44 AM, Richard Terry email@example.com
Sorry, on mobile, hit comment instead of the text box! Orig comment continues:
Nobody should be trying to modify their path directly, and it will be overwitten by
Which leads me to the issue of maximum slug/path length. Think that's a different issue, so have opened as #2.
Based on my thoughts for #2, I think the best solution would just be to remove uniqueness. You should be fine with your migration fix though, and the upgrade notes will say if you need to do anything special in the future.
This also shows the tests need to run against different database types.
All unique fields have a max-length of 191 characters (because MySQL max key length in 767 bytes and utf8mb4 reserves 4 bytes per character, thus 767/4 = 191)
If slug and name could both have configurable max-lengths (which should default to 255 if not defined), that would be great.
oh, and label should probably max out at the same size as 'name'
In our case, our maximum name length right now is 60 chars (with 3 levels in the tree), so 130 more chars should be (famous last words) plenty of headroom.
Note that my PR adds the MAX_LENGTH options and changes path from Text to Char field (since path should usually be the same length as name, this seems to be reasonable)
Thus, the MySQL problem is addressed as you suggested by removing the TextField and then by documenting the need for MAX_LENGTH settings dependent on your MySQL character encoding.