I added a couple of columns and fields to my Django model and was able to run South commands such as:
$ python manage.py schemamigration [model_name] --auto
$ python manage.py migrate
fine on local machine without any error. However, when I switch to the server, pulled all new migration+code files and stuff there and did this:
$ python manage.py migrate
It gives me the following error pasted below. I use version MySQL 5.6 (with InnoDB), if that is going to be a useful info. I've tried looking around online and Stackoverflow to find out how to solve this (e.g., this post comes pretty close to helping me understand the issue, but is not exactly what I'm facing...), but I cannot seem to find the solution to this.
What should I try now to successfully proceed the migration?
[root#server: t4s (develop)]$ python manage.py migrate
Running migrations for accounts:
- Migrating forwards to 0012_auto__add_timelimit.
> accounts:0005_auto__add_twilioaccount
> accounts:0006_auto__add_field_twilioaccount_created_at__add_field_twilioaccount_crea
> accounts:0007_auto__del_twilioaccount
> accounts:0008_auto__add_twilioaccount
> accounts:0009_auto__chg_field_twilioaccount_created_by__add_unique_twilioaccount_cre
> accounts:0010_auto__del_twilioaccount
> accounts:0011_auto__add_twilioaccount
> accounts:0012_auto__add_timelimit
- Loading initial data for accounts.
Installed 0 object(s) from 0 fixture(s)
Running migrations for smsmessages:
- Nothing to migrate.
- Loading initial data for smsmessages.
Installed 0 object(s) from 0 fixture(s)
Running migrations for organizations:
- Nothing to migrate.
- Loading initial data for organizations.
Installed 0 object(s) from 0 fixture(s)
Running migrations for campaigns:
- Migrating forwards to 0003_auto__add_field_taskqueue_twilio.
> campaigns:0003_auto__add_field_taskqueue_twilio
! Error found during real run of migration! Aborting.
! Since you have a database that does not support running
! schema-altering statements in transactions, we have had
! to leave it in an interim state between migrations.
! You *might* be able to recover with: - no dry run output for delete_foreign_key() due to dynamic DDL, sorry
= ALTER TABLE `campaigns_taskqueue` DROP COLUMN `twilio_id` CASCADE; []
! The South developers regret this has happened, and would
! like to gently persuade you to consider a slightly
! easier-to-deal-with DBMS (one that supports DDL transactions)
! NOTE: The error which caused the migration to fail is further up.
Error in migration: campaigns:0003_auto__add_field_taskqueue_twilio
Traceback (most recent call last):
File "manage.py", line 10, in <module>
execute_from_command_line(sys.argv)
File "/usr/lib/python2.6/site-packages/django/core/management/__init__.py", line 399, in execute_from_command_line
utility.execute()
File "/usr/lib/python2.6/site-packages/django/core/management/__init__.py", line 392, in execute
self.fetch_command(subcommand).run_from_argv(self.argv)
File "/usr/lib/python2.6/site-packages/django/core/management/base.py", line 242, in run_from_argv
self.execute(*args, **options.__dict__)
File "/usr/lib/python2.6/site-packages/django/core/management/base.py", line 285, in execute
output = self.handle(*args, **options)
File "/usr/lib64/python2.6/site-packages/south/management/commands/migrate.py", line 111, in handle
ignore_ghosts = ignore_ghosts,
File "/usr/lib64/python2.6/site-packages/south/migration/__init__.py", line 220, in migrate_app
success = migrator.migrate_many(target, workplan, database)
File "/usr/lib64/python2.6/site-packages/south/migration/migrators.py", line 254, in migrate_many
result = migrator.__class__.migrate_many(migrator, target, migrations, database)
File "/usr/lib64/python2.6/site-packages/south/migration/migrators.py", line 329, in migrate_many
result = self.migrate(migration, database)
File "/usr/lib64/python2.6/site-packages/south/migration/migrators.py", line 133, in migrate
result = self.run(migration, database)
File "/usr/lib64/python2.6/site-packages/south/migration/migrators.py", line 114, in run
return self.run_migration(migration, database)
File "/usr/lib64/python2.6/site-packages/south/migration/migrators.py", line 8
migration_function()
File "/usr/lib64/python2.6/site-packages/south/migration/migrators.py", line 6
return (lambda: direction(orm))
File "/opt/dev/t4sfeature/t4sdev/t4s/campaigns/migrations/0003_auto__add_field
keep_default=False)
File "/usr/lib64/python2.6/site-packages/south/db/generic.py", line 47, in _ca
return func(self, table, *args, **opts)
File "/usr/lib64/python2.6/site-packages/south/db/generic.py", line 418, in ad
self.execute(sql)
File "/usr/lib64/python2.6/site-packages/south/db/generic.py", line 282, in ex
cursor.execute(sql, params)
File "/usr/lib/python2.6/site-packages/django/db/backends/util.py", line 69, i
return super(CursorDebugWrapper, self).execute(sql, params)
File "/usr/lib/python2.6/site-packages/django/db/backends/util.py", line 53, i
return self.cursor.execute(sql, params)
File "/usr/lib/python2.6/site-packages/django/db/backends/mysql/base.py", line
return self.cursor.execute(query, args)
File "/usr/lib64/python2.6/site-packages/MySQLdb/cursors.py", line 175, in exe
if not self._defer_warnings: self._warning_check()
File "/usr/lib64/python2.6/site-packages/MySQLdb/cursors.py", line 89, in _war
warn(w[-1], self.Warning, 3)
_mysql_exceptions.Warning: TIME/TIMESTAMP/DATETIME columns of old format have been upgraded
When I tried running python manage.py migrate again, I got a slightly different error as follows.
[root#server: t4s (develop)]$ python manage.py migrate
Running migrations for accounts:
- Nothing to migrate.
- Loading initial data for accounts.
Installed 0 object(s) from 0 fixture(s)
Running migrations for smsmessages:
- Nothing to migrate.
- Loading initial data for smsmessages.
Installed 0 object(s) from 0 fixture(s)
Running migrations for organizations:
- Nothing to migrate.
- Loading initial data for organizations.
Installed 0 object(s) from 0 fixture(s)
Running migrations for campaigns:
- Migrating forwards to 0003_auto__add_field_taskqueue_twilio.
> campaigns:0003_auto__add_field_taskqueue_twilio
FATAL ERROR - The following SQL query failed: ALTER TABLE `campaigns_taskqueue` ADD COLUMN `twilio_id` integer NULL;
The error was: (1060, "Duplicate column name 'twilio_id'")
! Error found during real run of migration! Aborting.
! Since you have a database that does not support running
! schema-altering statements in transactions, we have had
! to leave it in an interim state between migrations.
! You *might* be able to recover with: - no dry run output for delete_foreign_key() due to dynamic DDL, sorry
= ALTER TABLE `campaigns_taskqueue` DROP COLUMN `twilio_id` CASCADE; []
! The South developers regret this has happened, and would
! like to gently persuade you to consider a slightly
! easier-to-deal-with DBMS (one that supports DDL transactions)
! NOTE: The error which caused the migration to fail is further up.
Error in migration: campaigns:0003_auto__add_field_taskqueue_twilio
Traceback (most recent call last):
File "manage.py", line 10, in <module>
execute_from_command_line(sys.argv)
File "/usr/lib/python2.6/site-packages/django/core/management/__init__.py", line 399, in execute_from_command_line
utility.execute()
File "/usr/lib/python2.6/site-packages/django/core/management/__init__.py", line 392, in execute
self.fetch_command(subcommand).run_from_argv(self.argv)
File "/usr/lib/python2.6/site-packages/django/core/management/base.py", line 242, in run_from_argv
self.execute(*args, **options.__dict__)
File "/usr/lib/python2.6/site-packages/django/core/management/base.py", line 285, in execute
output = self.handle(*args, **options)
File "/usr/lib64/python2.6/site-packages/south/management/commands/migrate.py", line 111, in handle
ignore_ghosts = ignore_ghosts,
File "/usr/lib64/python2.6/site-packages/south/migration/__init__.py", line 220, in migrate_app
success = migrator.migrate_many(target, workplan, database)
File "/usr/lib64/python2.6/site-packages/south/migration/migrators.py", line 254, in migrate_many
result = migrator.__class__.migrate_many(migrator, target, migrations, database)
File "/usr/lib64/python2.6/site-packages/south/migration/migrators.py", line 329, in migrate_many
result = self.migrate(migration, database)
File "/usr/lib64/python2.6/site-packages/south/migration/migrators.py", line 133, in migrate
result = self.run(migration, database)
File "/usr/lib64/python2.6/site-packages/south/migration/migrators.py", line 114, in run
return self.run_migration(migration, database)
File "/usr/lib64/python2.6/site-packages/south/migration/migrators.py", line 84, in run_migration
migration_function()
File "/usr/lib64/python2.6/site-packages/south/migration/migrators.py", line 60, in <lambda>
return (lambda: direction(orm))
File "/opt/dev/t4sfeature/t4sdev/t4s/campaigns/migrations/0003_auto__add_field
keep_default=False)
File "/usr/lib64/python2.6/site-packages/south/db/generic.py", line 47, in _ca
return func(self, table, *args, **opts)
File "/usr/lib64/python2.6/site-packages/south/db/generic.py", line 418, in ad
self.execute(sql)
File "/usr/lib64/python2.6/site-packages/south/db/generic.py", line 282, in ex
cursor.execute(sql, params)
File "/usr/lib/python2.6/site-packages/django/db/backends/util.py", line 69, i
return super(CursorDebugWrapper, self).execute(sql, params)
File "/usr/lib/python2.6/site-packages/django/db/backends/util.py", line 53, i
return self.cursor.execute(sql, params)
File "/usr/lib/python2.6/site-packages/django/db/utils.py", line 99, in __exit
six.reraise(dj_exc_type, dj_exc_value, traceback)
File "/usr/lib/python2.6/site-packages/django/db/backends/util.py", line 53, i
return self.cursor.execute(sql, params)
File "/usr/lib/python2.6/site-packages/django/db/backends/mysql/base.py", line
return self.cursor.execute(query, args)
File "/usr/lib64/python2.6/site-packages/MySQLdb/cursors.py", line 173, in exe
self.errorhandler(self, exc, value)
File "/usr/lib64/python2.6/site-packages/MySQLdb/connections.py", line 36, in
raise errorclass, errorvalue
django.db.utils.OperationalError: (1060, "Duplicate column name 'twilio_id'")
The lastest south migration file (named 0003_auto__add_field_taskqueue_twilio.py) regarding campaigns models has this:
u'campaigns.taskqueue': {
'Meta': {'object_name': 'TaskQueue'},
'campaign': ('django.db.models.fields.related.ForeignKey', [], {'to': u"orm['campaigns.Campaign']"}),
'created_at': ('django.db.models.fields.DateTimeField', [], {'auto_now_add': 'True', 'blank': 'True'}),
'created_by': ('django.db.models.fields.related.ForeignKey', [], {'to': u"orm['auth.User']"}),
'groups': ('django.db.models.fields.related.ManyToManyField', [], {'to': u"orm['organizations.Group']", 'symmetrical': 'False'}),
u'id': ('django.db.models.fields.AutoField', [], {'primary_key': 'True'}),
'launch_time': ('django.db.models.fields.DateTimeField', [], {}),
'status': ('django.db.models.fields.CharField', [], {'default': "'pending'", 'max_length': '30'}),
'twilio': ('django.db.models.fields.related.ForeignKey', [], {'to': u"orm['accounts.TwilioAccount']", 'null': 'True'})
},
As far as I remember, I just added this line to the campaigns/models.py file:
class TaskQueue(models.Model):
campaign = models.ForeignKey(Campaign)
launch_time = models.DateTimeField()
twilio = models.ForeignKey(TwilioAccount, null=True) # new line recently added
created_at = models.DateTimeField(auto_now_add=True)
created_by = models.ForeignKey(User)
and TwilioAccount model is like this:
class TwilioAccount(models.Model):
name = models.CharField(max_length=50, blank=True)
number = models.CharField(max_length=16, blank=True)
sid = models.CharField(max_length=100, blank=True)
token = models.CharField(max_length=100, blank=True)
created_at = models.DateTimeField(auto_now_add=True)
Thank you very much for your answers.
I found a solution to this. I read through South's migration file and git commit logs as well as checked my DB tables and realized there's a column named twilio already created (not sure when and how). After ensuring everything looks good, I used the recommendation of this very useful post (provided in the question above) by doing:
$ python manage.py migrate 0003 --fake
That allowed me to skip the migration #3 (I don't need it because I already have twilio column created in my DB) and proceed to next steps in coding. I hope someone who face the same error will find this useful.
Related
When running
python3 manage.py migrate
I was asked what the default value of 'id' should be and entered 1. I had read
https://docs.djangoproject.com/en/1.9/howto/writing-migrations/#migrations-that-add-unique-fields
but that was a bit too complicated for me so tried 1.
Now when I run
python3 manage.py migrate
I get the following error:
vagrant#vagrant-ubuntu-trusty-64:/vagrant/grader$ python3 manage.py migrate
Operations to perform:
Apply all migrations: admin, core, contenttypes, auth, sessions
Running migrations:
Rendering model states... DONE
Applying core.0002_auto_20160103_1302...Traceback (most recent call last):
File "/usr/local/lib/python3.4/dist-packages/django/db/backends/utils.py", line 64, in execute
return self.cursor.execute(sql, params)
psycopg2.ProgrammingError: multiple default values specified for column "id" of table "core_student"
The above exception was the direct cause of the following exception:
Traceback (most recent call last):
File "manage.py", line 10, in <module>
execute_from_command_line(sys.argv)
File "/usr/local/lib/python3.4/dist-packages/django/core/management/__init__.py", line 350, in execute_from_command_line
utility.execute()
File "/usr/local/lib/python3.4/dist-packages/django/core/management/__init__.py", line 342, in execute
self.fetch_command(subcommand).run_from_argv(self.argv)
File "/usr/local/lib/python3.4/dist-packages/django/core/management/base.py", line 348, in run_from_argv
self.execute(*args, **cmd_options)
File "/usr/local/lib/python3.4/dist-packages/django/core/management/base.py", line 399, in execute
output = self.handle(*args, **options)
File "/usr/local/lib/python3.4/dist-packages/django/core/management/commands/migrate.py", line 200, in handle
executor.migrate(targets, plan, fake=fake, fake_initial=fake_initial)
File "/usr/local/lib/python3.4/dist-packages/django/db/migrations/executor.py", line 92, in migrate
self._migrate_all_forwards(plan, full_plan, fake=fake, fake_initial=fake_initial)
File "/usr/local/lib/python3.4/dist-packages/django/db/migrations/executor.py", line 121, in _migrate_all_forwards
state = self.apply_migration(state, migration, fake=fake, fake_initial=fake_initial)
File "/usr/local/lib/python3.4/dist-packages/django/db/migrations/executor.py", line 198, in apply_migration
state = migration.apply(state, schema_editor)
File "/usr/local/lib/python3.4/dist-packages/django/db/migrations/migration.py", line 123, in apply
operation.database_forwards(self.app_label, schema_editor, old_state, project_state)
File "/usr/local/lib/python3.4/dist-packages/django/db/migrations/operations/fields.py", line 62, in database_forwards
field,
File "/usr/local/lib/python3.4/dist-packages/django/db/backends/base/schema.py", line 396, in add_field
self.execute(sql, params)
File "/usr/local/lib/python3.4/dist-packages/django/db/backends/base/schema.py", line 110, in execute
cursor.execute(sql, params)
File "/usr/local/lib/python3.4/dist-packages/django/db/backends/utils.py", line 79, in execute
return super(CursorDebugWrapper, self).execute(sql, params)
File "/usr/local/lib/python3.4/dist-packages/django/db/backends/utils.py", line 64, in execute
return self.cursor.execute(sql, params)
File "/usr/local/lib/python3.4/dist-packages/django/db/utils.py", line 95, in __exit__
six.reraise(dj_exc_type, dj_exc_value, traceback)
File "/usr/local/lib/python3.4/dist-packages/django/utils/six.py", line 685, in reraise
raise value.with_traceback(tb)
File "/usr/local/lib/python3.4/dist-packages/django/db/backends/utils.py", line 64, in execute
return self.cursor.execute(sql, params)
django.db.utils.ProgrammingError: multiple default values specified for column "id" of table "core_student"
How can I recover from this failed migration? I went into the psql command promt and typed
SELECT * FROM core_students
It returned 0 rows so I don'w know why I have a problem.
Shouldn't Django automatically make the 'id' field be unique numbers?
EDIT:
The id has been auto generated by the Django migration.
student model:
class Student(models.Model):
created = models.DateTimeField(auto_now_add=True)
updated = models.DateTimeField(auto_now=True)
owner = models.ForeignKey('auth.User', related_name='students')
identity_number = models.CharField(max_length=50)
first_name = models.CharField(max_length=50)
last_name = models.CharField(max_length=50)
I often run into a similar problem where a migration fails for whatever reason, and only part of it gets applied to the database.
In theory you should be able to go into the database and run queries to finish the migration, but knowing what exact queries to run and what parts of the migration haven't been run is difficult in my experience.
The most dependable way I've found to fix it is to fake the migration, then back up the model, comment it out in models.py, then make a migration to delete it, then fake that as well. Then I can go into the database, drop the table, and then make a new migration to recreate it the way I now want to be.
Here are the commands I run:
python manage.py migrate --fake [appname] #fake the failed migration
#comment out the model in models.py and back up the data
python manage.py makemigrations [appname]
python manage.py migrate --fake [appname] #fake the migration to delete
the table
python manage.py dbshell
#drop the table. Mysql would be: DROP TABLE [appname]_[modelname];
#exit dbshell
#Uncomment the model in models.py adding in whatever changes were originally wanted
python manage.py makemigrations [appname]
python manage.py migrate #assuming your model change is valid, this should work this time.
#reload your data into the table
No, it's not elegant, but it gets django migrations working again without having to guess how far django got through a migration before it failed.
I hoping that you can help me out. I currently have Django1.7 running on windows7/Java7/Jython2.7/Postgresql9.3/postgresql-9.3-1102.jdbc41.
I learned today that on Django 1.7 there is no reason to install the South package for migrations because 1.7 has makemigrations and migrate commands built in. But even so when I try to apply those commands in that order I am getting some sort of error. How can I resolve this error?
For more information on django migrations.
Django 1.7 Migrations
For more details about django on jython and the database settings.
postgresql on jython-django
My settings are:
DATABASES = {
'default': {
'ENGINE': 'doj.db.backends.postgresql',
'NAME': 'lwc',
'USER': 'lwc',
'PASSWORD': 'lwc',
'HOST': '127.0.0.1',
'PORT': '5432',
}
}
This is my models.py file and I am trying to add ip_address when I do the makemigrations and migrate commands.
from django.db import models
class Join(models.Model):
email = models.EmailField()
ip_address = models.CharField(max_length=120, null=True) #This is the new field
timestamp = models.DateTimeField(auto_now_add = True, auto_now=False)
updated = models.DateTimeField(auto_now_add = False, auto_now=True)
def __unicode__(self):
return "%s" %(self.email)
Here is the error that I get from running the migrate command:
C:\Users\mike\workspace\lwc>jython manage.py migrate
←[36;1mOperations to perform:←[0m
←[1m Apply all migrations: ←[0madmin, sessions, joins, auth, contenttypes
←[36;1mRunning migrations:←[0m
Applying joins.0003_join_ip_address...Traceback (most recent call last):
File "manage.py", line 10, in <module>
execute_from_command_line(sys.argv)
File "C:\jython2.7b2\Lib\site-packages\django-1.7c3-py2.7.egg\django\core\mana
gement\__init__.py", line 385, in execute_from_command_line
utility.execute()
File "C:\jython2.7b2\Lib\site-packages\django-1.7c3-py2.7.egg\django\core\mana
gement\__init__.py", line 377, in execute
self.fetch_command(subcommand).run_from_argv(self.argv)
File "C:\jython2.7b2\Lib\site-packages\django-1.7c3-py2.7.egg\django\core\mana
gement\base.py", line 288, in run_from_argv
self.execute(*args, **options.__dict__)
File "C:\jython2.7b2\Lib\site-packages\django-1.7c3-py2.7.egg\django\core\mana
gement\base.py", line 338, in execute
output = self.handle(*args, **options)
File "C:\jython2.7b2\Lib\site-packages\django-1.7c3-py2.7.egg\django\core\mana
gement\commands\migrate.py", line 160, in handle
executor.migrate(targets, plan, fake=options.get("fake", False))
File "C:\jython2.7b2\Lib\site-packages\django-1.7c3-py2.7.egg\django\db\migrat
ions\executor.py", line 63, in migrate
self.apply_migration(migration, fake=fake)
File "C:\jython2.7b2\Lib\site-packages\django-1.7c3-py2.7.egg\django\db\migrat
ions\executor.py", line 97, in apply_migration
migration.apply(project_state, schema_editor)
File "C:\jython2.7b2\Lib\site-packages\django-1.7c3-py2.7.egg\django\db\migrat
ions\migration.py", line 107, in apply
operation.database_forwards(self.app_label, schema_editor, project_state, ne
w_state)
File "C:\jython2.7b2\Lib\site-packages\django-1.7c3-py2.7.egg\django\db\migrat
ions\operations\fields.py", line 35, in database_forwards
schema_editor.add_field(
File "C:\jython2.7b2\Lib\site-packages\django-1.7c3-py2.7.egg\django\db\backen
ds\schema.py", line 411, in add_field
self.execute(sql, params)
File "C:\jython2.7b2\Lib\site-packages\django-1.7c3-py2.7.egg\django\db\backen
ds\schema.py", line 98, in execute
cursor.execute(sql, params)
File "C:\jython2.7b2\Lib\site-packages\django-1.7c3-py2.7.egg\django\db\backen
ds\utils.py", line 81, in execute
return super(CursorDebugWrapper, self).execute(sql, params)
File "C:\jython2.7b2\Lib\site-packages\django-1.7c3-py2.7.egg\django\db\backen
ds\utils.py", line 65, in execute
return self.cursor.execute(sql, params)
File "C:\jython2.7b2\Lib\site-packages\django-1.7c3-py2.7.egg\django\db\utils.
py", line 94, in __exit__
six.reraise(dj_exc_type, dj_exc_value, traceback)
File "C:\jython2.7b2\Lib\site-packages\django-1.7c3-py2.7.egg\django\db\backen
ds\utils.py", line 65, in execute
return self.cursor.execute(sql, params)
File "C:\jython2.7b2\Lib\site-packages\django_jython-1.7.0b2-py2.7.egg\doj\db\
backends\__init__.py", line 180, in execute
self.cursor.execute(sql, params)
django.db.utils.Error: ERROR: could not determine data type of parameter $1 [SQL
Code: 0], [SQLState: 42P18]
I ran sqlmigrate because I understand that this is the sql calls that it is suppose to attempt to run. And I am not a DBA, but they don't look right to me. Anybody out there know SQL for Postgresql really well?
C:\Users\mike\workspace\lwc>jython manage.py sqlmigrate joins 0002_join_ref_
id
BEGIN;
ALTER TABLE `joins_join` ADD COLUMN `ref_id` varchar(120) DEFAULT "ABC" NOT NULL
;
ALTER TABLE `joins_join` ALTER COLUMN `ref_id` DROP DEFAULT;
COMMIT;
I tried running that command in the Postgresql Query tool and I got the following error:
ERROR: column "ABC" does not exist
********** Error **********
ERROR: column "ABC" does not exist
SQL state: 42703
So, then this looks like a bug with Django 1.7. Has anyone else had this issue? What is the correct SQL statement? How could I create a workaround or resolve this issue?
I have connected django with sql anywhere 11 database, I have follow the instructions on the page SQL Anywhere Django Driver from github.
I have created the database with this command:
C:\>dbinit -z UCA django.db --> (database created successful)
I have started the Database Server with command:
C:\>dbsrv11 django.db --> (database server started successful)
I have created my project with:
C:\>django-admin.py startproject mysite (at this point all it's ok)
I have edited the file mysite/mysite/settings.py and I have changed the DATABASES setting with this:
DATABASES = {
'default': {
'ENGINE': 'sqlany_django',
'NAME': 'django',
'USER': 'dba',
'PASSWORD': 'sql',
'OPTIONS': {'eng': 'django'}
}
}
When I want to sync database using this command:
c:/mysite>python manage.py syncdb
the prompt show me a error message (the error message is shown below)
I have connected Sybase Central to django.db I see the tables was created.
but when I try save data to the tables this data wasn't recorded
even when I have created the superuser with this command:
c:\mysite>python manage.py createsuperuser --username=joe --email=joe#example.com
Password:123
Password (again):123
Superuser created successfully.
I querying the datebase with:
select * from auth_user
No rows are shown
The data aren't saved
I have an environment for test with this features:
O.S.: Windows XP
DB Engine: SQL Anywhere 11 with EBF 3069
Python 2.7
Django 1.6.1
Setuptools installed
PIP installed
sqlanydb installed
sqlany-django installed
Here is the error message
C:\mysite>python manage.py syncdb
Creating tables ...
Creating table django_admin_log
Creating table auth_permission
Creating table auth_group_permissions
Creating table auth_group
Creating table auth_user_groups
Creating table auth_user_user_permissions
Creating table auth_user
Creating table django_content_type
Creating table django_session
Creating table Personal_persona
Traceback (most recent call last):
File "manage.py", line 10, in <module>
execute_from_command_line(sys.argv)
File "C:\Python27\lib\site-packages\django\core\management\__init__.py", line
399, in execute_from_command_line
utility.execute()
File "C:\Python27\lib\site-packages\django\core\management\__init__.py", line
392, in execute
self.fetch_command(subcommand).run_from_argv(self.argv)
File "C:\Python27\lib\site-packages\django\core\management\base.py", line 242,
in run_from_argv
self.execute(*args, **options.__dict__)
File "C:\Python27\lib\site-packages\django\core\management\base.py", line 285,
in execute
output = self.handle(*args, **options)
File "C:\Python27\lib\site-packages\django\core\management\base.py", line 415,
in handle
return self.handle_noargs(**options)
File "C:\Python27\lib\site-packages\django\core\management\commands\syncdb.py"
, line 112, in handle_noargs
emit_post_sync_signal(created_models, verbosity, interactive, db)
File "C:\Python27\lib\site-packages\django\core\management\sql.py", line 216,
in emit_post_sync_signal
interactive=interactive, db=db)
File "C:\Python27\lib\site-packages\django\dispatch\dispatcher.py", line 185,
in send
response = receiver(signal=self, sender=sender, **named)
File "C:\Python27\lib\site-packages\django\contrib\auth\management\__init__.py
", line 101, in create_permissions
auth_app.Permission.objects.using(db).bulk_create(perms)
File "C:\Python27\lib\site-packages\django\db\models\query.py", line 356, in b
ulk_create
self._batched_insert(objs_without_pk, fields, batch_size)
File "C:\Python27\lib\site-packages\django\db\models\query.py", line 835, in _
batched_insert
using=self.db)
File "C:\Python27\lib\site-packages\django\db\models\manager.py", line 232, in
_insert
return insert_query(self.model, objs, fields, **kwargs)
File "C:\Python27\lib\site-packages\django\db\models\query.py", line 1511, in
insert_query
return query.get_compiler(using=using).execute_sql(return_id)
File "C:\Python27\lib\site-packages\django\db\models\sql\compiler.py", line 90
3, in execute_sql
cursor.execute(sql, params)
File "C:\Python27\lib\site-packages\django\db\backends\util.py", line 69, in e
xecute
return super(CursorDebugWrapper, self).execute(sql, params)
File "C:\Python27\lib\site-packages\django\db\backends\util.py", line 53, in e
xecute
return self.cursor.execute(sql, params)
File "C:\Python27\lib\site-packages\django\db\utils.py", line 99, in __exit__
six.reraise(dj_exc_type, dj_exc_value, traceback)
File "C:\Python27\lib\site-packages\django\db\backends\util.py", line 53, in e
xecute
return self.cursor.execute(sql, params)
File "C:\Python27\lib\site-packages\sqlany_django\base.py", line 87, in execut
e
ret = self.cursor.execute(trace(query), trace(args))
File "C:\Python27\lib\site-packages\sqlanydb.py", line 714, in execute
self.executemany(operation, [parameters])
File "C:\Python27\lib\site-packages\sqlanydb.py", line 685, in executemany
bind_count = self.api.sqlany_num_params(self.stmt)
File "C:\Python27\lib\site-packages\sqlanydb.py", line 619, in __stmt_get
self.handleerror(*self.parent.error())
File "C:\Python27\lib\site-packages\sqlanydb.py", line 613, in handleerror
eh(self.parent, self, errorclass, errorvalue)
File "C:\Python27\lib\site-packages\sqlanydb.py", line 342, in standardErrorHa
ndler
raise errorclass(errorvalue)
django.db.utils.OperationalError: Syntax error near ',' on line 1
Sorry, but the SQL Anywhere Django driver requires SQL Anywhere v12 or higher; you cannot use it with SQL Anywhere v11. I have confirmed that the driver uses features of the database server that were not supported in version 11.
Disclaimer: I work for SAP in SQL Anywhere engineering.
I'm currently trying to get familiarized with django and I got stuck with an error I can't fix. My django version is 1.7a2 (from developer).
My model is quite simple:
from django.db import models
class dataset(models.Model):
ID = models.CharField("ID of current dataset", max_length=20, primary_key=True)
date = models.DateTimeField('Date of current dataset')
name = models.CharField("Name of current dataset", max_length=20)
value = models.FloatField("Value of current dataset")
But when I run 'python manage.py syncdb' command for the second time I get this error:
$ python manage.py syncdb
Operations to perform:
Synchronize unmigrated apps: admin, contenttypes, auth, sessions
Apply all migrations: display
Synchronizing apps without migrations:
Creating tables...
Installing custom SQL...
Installing indexes...
Running migrations:
Applying display.0001_initial...Traceback (most recent call last):
File "manage.py", line 10, in <module>
execute_from_command_line(sys.argv)
File "/usr/local/lib/python2.7/dist-packages/django-trunk/django/core/management/__init__.py", line 427, in execute_from_command_line
utility.execute()
File "/usr/local/lib/python2.7/dist-packages/django-trunk/django/core/management/__init__.py", line 419, in execute
self.fetch_command(subcommand).run_from_argv(self.argv)
File "/usr/local/lib/python2.7/dist-packages/django-trunk/django/core/management/base.py", line 287, in run_from_argv
self.execute(*args, **options.__dict__)
File "/usr/local/lib/python2.7/dist-packages/django-trunk/django/core/management/base.py", line 336, in execute
output = self.handle(*args, **options)
File "/usr/local/lib/python2.7/dist-packages/django-trunk/django/core/management/base.py", line 531, in handle
return self.handle_noargs(**options)
File "/usr/local/lib/python2.7/dist-packages/django-trunk/django/core/management/commands/syncdb.py", line 22, in handle_noargs
call_command("migrate", **options)
File "/usr/local/lib/python2.7/dist-packages/django-trunk/django/core/management/__init__.py", line 167, in call_command
return klass.execute(*args, **defaults)
File "/usr/local/lib/python2.7/dist-packages/django-trunk/django/core/management/base.py", line 336, in execute
output = self.handle(*args, **options)
File "/usr/local/lib/python2.7/dist-packages/django-trunk/django/core/management/commands/migrate.py", line 145, in handle
executor.migrate(targets, plan, fake=options.get("fake", False))
File "/usr/local/lib/python2.7/dist-packages/django-trunk/django/db/migrations/executor.py", line 60, in migrate
self.apply_migration(migration, fake=fake)
File "/usr/local/lib/python2.7/dist-packages/django-trunk/django/db/migrations/executor.py", line 94, in apply_migration
migration.apply(project_state, schema_editor)
File "/usr/local/lib/python2.7/dist-packages/django-trunk/django/db/migrations/migration.py", line 97, in apply
operation.database_forwards(self.app_label, schema_editor, project_state, new_state)
File "/usr/local/lib/python2.7/dist-packages/django-trunk/django/db/migrations/operations/models.py", line 28, in database_forwards
schema_editor.create_model(model)
File "/usr/local/lib/python2.7/dist-packages/django-trunk/django/db/backends/schema.py", line 253, in create_model
self.execute(sql, params)
File "/usr/local/lib/python2.7/dist-packages/django-trunk/django/db/backends/schema.py", line 95, in execute
cursor.execute(sql, params)
File "/usr/local/lib/python2.7/dist-packages/django-trunk/django/db/backends/utils.py", line 77, in execute
return super(CursorDebugWrapper, self).execute(sql, params)
File "/usr/local/lib/python2.7/dist-packages/django-trunk/django/db/backends/utils.py", line 61, in execute
return self.cursor.execute(sql, params)
File "/usr/local/lib/python2.7/dist-packages/django-trunk/django/db/utils.py", line 93, in __exit__
six.reraise(dj_exc_type, dj_exc_value, traceback)
File "/usr/local/lib/python2.7/dist-packages/django-trunk/django/db/backends/utils.py", line 61, in execute
return self.cursor.execute(sql, params)
File "/usr/local/lib/python2.7/dist-packages/django-trunk/django/db/backends/sqlite3/base.py", line 475, in execute
return Database.Cursor.execute(self, query, params)
django.db.utils.OperationalError: duplicate column name: ID
Does anyone have any idea what I am doing wrong?
Thanks in advance.
I tried removing the db.sqlite3 file inside my django root directory and it didn't work, but then I removed the content of the /migration/ inside the application folder where my model is and it worked without showing any other error.
It seems to me some kind of bug, since it does not update the migration folder once the model changed...
You cannot create an entry with the name ID.
Event if you remove ID it will show errors.
Here is how I fixed it.
Delete the Migrations Directory
Rename ID to some thing else
python manage.py makemigrations
python manage.py migrate
Hopefully this will fix it.
I am relatively new to django. I have defined my db schema and validated it with no errors (manage.py validate reports 0 errors found).
Yet when I run ./manage.py syncdb
I get the following stack trace:
Creating table demo_foobar_one
Creating table demo_foobar_two
<snip>...</snip>
Traceback (most recent call last):
File "manage.py", line 11, in <module>
execute_manager(settings)
File "/usr/local/lib/python2.6/dist-packages/django/core/management/__init__.py", line 438, in execute_manager
utility.execute()
File "/usr/local/lib/python2.6/dist-packages/django/core/management/__init__.py", line 379, in execute
self.fetch_command(subcommand).run_from_argv(self.argv)
File "/usr/local/lib/python2.6/dist-packages/django/core/management/base.py", line 191, in run_from_argv
self.execute(*args, **options.__dict__)
File "/usr/local/lib/python2.6/dist-packages/django/core/management/base.py", line 218, in execute
output = self.handle(*args, **options)
File "/usr/local/lib/python2.6/dist-packages/django/core/management/base.py", line 347, in handle
return self.handle_noargs(**options)
File "/usr/local/lib/python2.6/dist-packages/django/core/management/commands/syncdb.py", line 103, in handle_noargs
emit_post_sync_signal(created_models, verbosity, interactive, db)
File "/usr/local/lib/python2.6/dist-packages/django/core/management/sql.py", line 185, in emit_post_sync_signal
interactive=interactive, db=db)
File "/usr/local/lib/python2.6/dist-packages/django/dispatch/dispatcher.py", line 162, in send
response = receiver(signal=self, sender=sender, **named)
File "/usr/local/lib/python2.6/dist-packages/django/contrib/auth/management/__init__.py", line 28, in create_permissions
defaults={'name': name, 'content_type': ctype})
File "/usr/local/lib/python2.6/dist-packages/django/db/models/manager.py", line 135, in get_or_create
return self.get_query_set().get_or_create(**kwargs)
File "/usr/local/lib/python2.6/dist-packages/django/db/models/query.py", line 373, in get_or_create
obj.save(force_insert=True, using=self.db)
File "/usr/local/lib/python2.6/dist-packages/django/db/models/base.py", line 435, in save
self.save_base(using=using, force_insert=force_insert, force_update=force_update)
File "/usr/local/lib/python2.6/dist-packages/django/db/models/base.py", line 528, in save_base
result = manager._insert(values, return_id=update_pk, using=using)
File "/usr/local/lib/python2.6/dist-packages/django/db/models/manager.py", line 195, in _insert
return insert_query(self.model, values, **kwargs)
File "/usr/local/lib/python2.6/dist-packages/django/db/models/query.py", line 1479, in insert_query
return query.get_compiler(using=using).execute_sql(return_id)
File "/usr/local/lib/python2.6/dist-packages/django/db/models/sql/compiler.py", line 783, in execute_sql
cursor = super(SQLInsertCompiler, self).execute_sql(None)
File "/usr/local/lib/python2.6/dist-packages/django/db/models/sql/compiler.py", line 727, in execute_sql
cursor.execute(sql, params)
File "/usr/local/lib/python2.6/dist-packages/django/db/backends/util.py", line 15, in execute
return self.cursor.execute(sql, params)
File "/usr/local/lib/python2.6/dist-packages/django/db/backends/mysql/base.py", line 86, in execute
return self.cursor.execute(query, args)
File "/usr/local/lib/python2.6/dist-packages/MySQL_python-1.2.3-py2.6-linux-i686.egg/MySQLdb/cursors.py", line 176, in execute
if not self._defer_warnings: self._warning_check()
File "/usr/local/lib/python2.6/dist-packages/MySQL_python-1.2.3-py2.6-linux-i686.egg/MySQLdb/cursors.py", line 92, in _warning_check
warn(w[-1], self.Warning, 3)
_mysql_exceptions.Warning: Data truncated for column 'name' at row 1
I have checked (and double checked) my table schema. All name field are CharField type with maximum length = 64. The backend db I am using is MySQL, so I am sure that indexes can be created for strings of length 64.
What could be causing this error (I suspect it is a misleading error message - even though its coming from the db itself)...
The traceback is happening during the creation of a django.contrib.auth.Permission: some of these get created for your models automatically as part of syncdb.
Permission.name has max_length=50, so you probably have an application and/or model class with a really long name?
Try the following query in manage.py dbshell:
SELECT * FROM auth_permission WHERE LENGTH(name) = 50;
If you cannot change your model name, then you can fix this problem by reducing the length of the generated Permission.name by specifying verbose_name in the model Meta class (see here for more details):
class MyVeryLongModelNameThatIsBreakingMyMigration(models.Model):
class Meta:
verbose_name = 'my long model'
Update
There's an open (as of 2013) Django ticket to fix this:
#8162 (Increase Permission.name max_length)
As Piet Delport noted, the problem is that your model name is too long.
You're certainly going to have to shorten your model name, and then clean up your database. How you do that depends upon where you are in the development process.
If this is a brand new application, with a dedicated database, and no actual data, the simple answer is to drop and recreate the database, and then re-run python manage.py syncdb.
If you have other tables in the database that need to be left alone, but the tables for your Django have no 'real' data, and can thus be dropped without damage, then you can use manage.py sqlclear to generate SQL DDL to drop all of the Django-generated tables, constraints, and indexes.
Do the following:
apps="auth contenttypes sessions sites messages admin <myapp1> <myapp2>"
python manage.py sqlclear ${apps} > clear.sql
You can feed the generated script to mysql or python manage.py dbshell. Once that's done, you can re-run python manage.py syncdb.
If you have actual data in your database tables that can't be dropped or deleted: Slap yourself and repeat 100 times "I will never do development against a production database again. I will always back up my databases before changing them." Now you're going to have to hand-code SQL to change the affected table name, as well as anything else that references it and any references in the auth_permissions table and any other Django system tables. Your actual steps will depend entirely upon the state of your database and tables.
I also got error like this one using postgresql django 1.2, but the problem was not the length, but using ugettext_lazy for translating the names. ('can_purge', _("Can purge")) is evidently unacceptable, since the name is stored in the database as text