Malcolm Tredinnick wrote: > I was trying to avoid a hash-based solution because it leads to > unreadable names (and I don't think every database supports unnamed > constraints, so that isn't a universal solution, either). I need to do a > bit of research and them come up with a legal hash construction.
But why not let the backend decide the best way to build the ALTER TABLE/ADD CONSTRAINT statement? Then the MySQL backend could leave them unnamed, avoiding the uniqueness/length issues, and other backends could do it the old way since they aren't affected. It seems this bit of SQL is non-standard enough that it might benefit to move it out of management.py. As you pointed out, the hashing approach will be ugly, and may take a bit of work to get a format that is legal in all DBs. And other approaches that I thought of are worse (query the DB for current constraint names to ensure you don't collide, or scan all apps during syncdb to build a complete list of constraints before running your patch algorithm). -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 -~----------~----~----~----~------~----~------~--~---
