Malcolm Tredinnick wrote: > > That is also possible, but I was trying to avoid another reliance on the > backend (things like "sqlall" start to get complex). Still, it's > probably only a single proxy function call, so not too hard to maintain. > > I'm sure if I keep coming up with bad implementations, you'll keep > pounding. So one day it will be perfect. :-)
Easy for me to throw out ideas when I'm not the one doing the maintenance! I'm actually fine with the hashing idea. Constraints don't really need to have nice names since you rarely see them and don't reference them during normal SQL usage. And the MySQL bug I referenced earlier actually had to do with the auto-generated constraint names: MySQL still uses table/column names to generate them and adds a number on the end like in your patch. If tables have really long names, it can generate constraint names that exceed the 64-character limit. So maybe leaving the logic in management.py and getting it right there _is_ the better way to go. One thing I did notice on the current algorithm: it uses the source column name but not the source table name. I actually think that's backwards. It should use the table names, not the column names, which would result in a unique constraint name, the one exception being when you have two FK columns in the same table. But that's much more rare (although still possible). Anyway, we've beat this horse to death. I'm interested to see what you come up with... -Dave --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers -~----------~----~----~----~------~----~------~--~---
