Solved.
It wasn't the OS, django, Python or MySQL versions...
It was the South version. Locally I was using 0.6.2 whereas the on the
development server I had 0.6-pre installed.
btw, if you encounter this and try to "python setup.py install" the
new South - remember to erase the old South folders and egg files from
the site-packages directory... Interestingly enough if you don't do
that in Python's shell you'll get the new South version, whereas in
django's shell you'll get the old south version.
Jonathan
On Dec 19, 1:34 pm, Jonathan wrote:
> I'm using South to migrate a certain field from ForeignField to
> OneToOneField.
> Initial state is that I have model A pointing to model B using a
> ForeignField. Of course there's only one instance of A pointing to a B
> instance.
>
> I wasn't sure if this would work directly, or that I should do a 3-
> stage migration (1- add a different field, 2- copy the id from
> ForeignField to OneToOneField, 3- erase the ForeignField), so I tried
> it and it worked flawlessly on my local machine - Windows\django 1.1.0
> final\Python 2.6.4\MySQL 5.1.41
>
> Unfortunately, I ran the migration on our development server which is
> a Debian\django 1.1.0 beta\Python 2.5.0\MySQL 5.0.32 and the migration
> failed with the following error:
>
> Traceback (most recent call last):
> File "/usr/lib/python2.5/site-packages/South-0.6_pre-py2.5.egg/south/
> migration.py", line 315, in run_migrations
> runfunc(orm)
> File "/usr/share/", line 19, in forwards
> db.create_unique('tree_family_name', ['base_id'])
> File "/usr/lib/python2.5/site-packages/South-0.6_pre-py2.5.egg/south/
> db/generic.py", line 346, in create_unique
> self.execute("ALTER TABLE %s ADD CONSTRAINT %s UNIQUE (%s)" % (qn
> (table_name), qn(name), cols))
> File "/usr/lib/python2.5/site-packages/South-0.6_pre-py2.5.egg/south/
> db/mysql.py", line 29, in execute
> return generic.DatabaseOperations.execute(self, sql, params)
> File "/usr/lib/python2.5/site-packages/South-0.6_pre-py2.5.egg/south/
> db/generic.py", line 70, in execute
> cursor.execute(sql, params)
> File "/usr/lib/python2.5/site-packages/django/db/backends/util.py",
> line 19, in execute
> return self.cursor.execute(sql, params)
> File "/usr/lib/python2.5/site-packages/django/db/backends/mysql/
> base.py", line 84, in execute
> return self.cursor.execute(query, args)
> File "/usr/lib/python2.5/site-packages/MySQLdb/cursors.py", line
> 163, in execute
> self.errorhandler(self, exc, value)
> File "/usr/lib/python2.5/site-packages/MySQLdb/connections.py", line
> 35, in defaulterrorhandler
> raise errorclass, errorvalue
> OperationalError: (1061, "Duplicate key name
> 'tree_family_name_base_id'")
>
> Is this due to the django version? Python version? MySQL version? Any
> thoughts? Should I change to the 3-stage migration model?
--
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to django-us...@googlegroups.com.
To unsubscribe from this group, send email to
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en.
