I updated django-dynamic-model repository to support Django 1.9. I got this error:
CommandError:
Conflicting migrations detected; multiple leaf nodes in the migration
graph: (0001_initial, 0002_auto__add_field_dynamicschemafield_extra in
dynamicmodel).
To fix them run 'python manage.py makemigrations --merge'
After running python manage.py makemigrations --merge, I got another error:
File "/local/lib/python2.7/sitepackages/django/core/management/__init__.py",
line 353, in execute_from_command_line
utility.execute()
File "/local/lib/python2.7/sitepackages/django/core/management/__init__.py", line 345, in execute
self.fetch_command(subcommand).run_from_argv(self.argv)
File
"/local/lib/python2.7/site-packages/django/core/management/base.py", line 348, in run_from_argv
self.execute(*args, **cmd_options)
File
"/local/lib/python2.7/site-packages/django/core/management/base.py", line 399, in execute
output = self.handle(*args, **options)
File
"/local/lib/python2.7/site-packages/django/core/management/commands/makemigrations.py", line 97, in handle
return self.handle_merge(loader, conflicts)
File
"/local/lib/python2.7/site-packages/django/core/management/commands/makemigrations.py", line 216, in handle_merge
raise ValueError("Could not find common ancestor of %s" % migration_names)
ValueError: Could not find common ancestor of set([u'0001_initial', u'0002_auto__add_field_dynamicschemafield_extra']).
Help me to find the solution.
The migrations need to have "straight" dependency chain, i.e. migration 0003 needs to depend on migration 0002, and 0002 on 0001.
You need to define this in the 0003_third.py like this:
class Migration(migrations.Migration):
dependencies = [
('modulename', '0002_second'),
]
Seems like you have injected models of other applications.
Define TARGET_APP in your migrations, seems like migrations loader can't correctly identify target app.
Related
I have a similar problem to this post but its only answer didn't help:
❯ python manage.py makemigrations
No changes detected
Because when I execute python manage.py migrate I get the following traceback:
❯ python manage.py migrate
Operations to perform:
Apply all migrations: admin, auth, blog, contenttypes, portfolio, sessions
Traceback (most recent call last):
File "C:\Users\user\Projects\personal_website\src\packages\pweb_django\manage.py", line 23, in <module>
main()
File "C:\Users\user\Projects\personal_website\src\packages\pweb_django\manage.py", line 19, in main execute_from_command_line(sys.argv)
File "C:\Users\user\Projects\personal_website\pweb-venv\lib\site-packages\django\core\management\__init__.py", line 446, in execute_from_command_line
utility.execute()
File "C:\Users\user\Projects\personal_website\pweb-venv\lib\site-packages\django\core\management\__init__.py", line 440, in execute
self.fetch_command(subcommand).run_from_argv(self.argv)
File "C:\Users\user\Projects\personal_website\pweb-venv\lib\site-packages\django\core\management\base.py", line 414, in run_from_argv
self.execute(*args, **cmd_options)
File "C:\Users\user\Projects\personal_website\pweb-venv\lib\site-packages\django\core\management\base.py", line 460, in execute
output = self.handle(*args, **options)
File "C:\Users\user\Projects\personal_website\pweb-venv\lib\site-packages\django\core\management\base.py", line 98, in wrapped
res = handle_func(*args, **kwargs)
File "C:\Users\user\Projects\personal_website\pweb-venv\lib\site-packages\django\core\management\commands\migrate.py", line 236, in handle
pre_migrate_apps = pre_migrate_state.apps
File "C:\Users\user\Projects\personal_website\pweb-venv\lib\site-packages\django\utils\functional.py", line 49, in __get__
res = instance.__dict__[self.name] = self.func(instance)
File "C:\Users\user\Projects\personal_website\pweb-venv\lib\site-packages\django\db\migrations\state.py", line 544, in apps
return StateApps(self.real_apps, self.models)
File "C:\Users\user\Projects\personal_website\pweb-venv\lib\site-packages\django\db\migrations\state.py", line 615, in __init__
raise ValueError("\n".join(error.msg for error in errors))
ValueError: The field admin.LogEntry.user was declared with a lazy reference to 'portfolio.user', but app 'portfolio' doesn't provide model 'user'.
Yet, when I check the file portfolio\models.py it clearly provides the 'user'-model:
class User(AbstractUser):
"""Dummy class in order to mimic a standard Auth-user.
Docs: https://docs.djangoproject.com/en/4.0/topics/auth/customizing/#using-a-custom-user-model-when-starting-a-project
"""
pass
In the related portfolio\admin.py - file, the following admin site is being registered:
from django.contrib import admin
from django.contrib.auth.admin import UserAdmin
from .models import User
admin.site.register(User, UserAdmin)
I would like to understand why this does not work while the other model-class can be found and registered without an issue:
from django.contrib import admin
from .models import Project
admin.site.register(Project)
It happens if you ran default auth app migrations and later changed the AUTH_USER_MODEL in settings.py. You can try following:
#comments AUTH_USER_MODEL in the settings.py file so it points to a default User Model
Python manage.py migrate auth zero
#Uncomment AUTH_USER_MODEL='recommend.AuthUser'
Python manage.py migrate auth
Source
If it's doesn't solve your problems and you are using Sqlite3 you can:
Delete all migration files except __init__.py file.
I am working on a codebase using Django 1.9, I am busy getting everything ready to upgrade to 1.10.
I have run into an issue after migrating from python social auth to python social auth app django. I have used the steps found here
After updating my settings and url files, I ran into the below error. Does anyone know how I can get around this?
Running migrations:
Rendering model states... DONE
Applying social_django.0006_partial... OK
Applying social_django.0007_code_timestamp... OK
Applying social_django.0008_partial_timestamp... OK
Applying social_django.0009_auto_20191118_0520...Traceback (most recent call last):
File "/home/brendan/venvs/social/lib/python3.6/site-packages/django/db/backends/utils.py", line 64, in execute
return self.cursor.execute(sql, params)
psycopg2.IntegrityError: column "modified" contains null values
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 "/home/brendan/venvs/social/lib/python3.6/site-packages/django/core/management/__init__.py", line 353, in execute_from_command_line
utility.execute()
File "/home/brendan/venvs/social/lib/python3.6/site-packages/django/core/management/__init__.py", line 345, in execute
self.fetch_command(subcommand).run_from_argv(self.argv)
File "/home/brendan/venvs/social/lib/python3.6/site-packages/django/core/management/base.py", line 348, in run_from_argv
self.execute(*args, **cmd_options)
File "/home/brendan/venvs/social/lib/python3.6/site-packages/django/core/management/base.py", line 399, in execute
output = self.handle(*args, **options)
File "/home/brendan/venvs/social/lib/python3.6/site-packages/django/core/management/commands/migrate.py", line 200, in handle
executor.migrate(targets, plan, fake=fake, fake_initial=fake_initial)
File "/home/brendan/venvs/social/lib/python3.6/site-packages/django/db/migrations/executor.py", line 92, in migrate
self._migrate_all_forwards(plan, full_plan, fake=fake, fake_initial=fake_initial)
File "/home/brendan/venvs/social/lib/python3.6/site-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 "/home/brendan/venvs/social/lib/python3.6/site-packages/django/db/migrations/executor.py", line 198, in apply_migration
state = migration.apply(state, schema_editor)
File "/home/brendan/venvs/social/lib/python3.6/site-packages/django/db/migrations/migration.py", line 123, in apply
operation.database_forwards(self.app_label, schema_editor, old_state, project_state)
File "/home/brendan/venvs/social/lib/python3.6/site-packages/django/db/migrations/operations/fields.py", line 62, in database_forwards
field,
File "/home/brendan/venvs/social/lib/python3.6/site-packages/django/db/backends/base/schema.py", line 396, in add_field
self.execute(sql, params)
File "/home/brendan/venvs/social/lib/python3.6/site-packages/django/db/backends/base/schema.py", line 110, in execute
cursor.execute(sql, params)
File "/home/brendan/venvs/social/lib/python3.6/site-packages/django/db/backends/utils.py", line 79, in execute
return super(CursorDebugWrapper, self).execute(sql, params)
File "/home/brendan/venvs/social/lib/python3.6/site-packages/django/db/backends/utils.py", line 64, in execute
return self.cursor.execute(sql, params)
File "/home/brendan/venvs/social/lib/python3.6/site-packages/django/db/utils.py", line 95, in __exit__
six.reraise(dj_exc_type, dj_exc_value, traceback)
File "/home/brendan/venvs/social/lib/python3.6/site-packages/django/utils/six.py", line 685, in reraise
raise value.with_traceback(tb)
File "/home/brendan/venvs/social/lib/python3.6/site-packages/django/db/backends/utils.py", line 64, in execute
return self.cursor.execute(sql, params)
django.db.utils.IntegrityError: column "modified" contains null values
This usually happens when you upgrade the module and the newer module's models have new constraints, in your case
column "modified" contains null values
One way is to delete just the instance that are causing the error. For this, go to the migrations folder and delete manually files that have 0009_auto_20191118_0520 type of name, you can delete, probably all, but 0001_initial.py file. After that run
python ./manage.py make migrations social_django, it should update your database.
You can also consider clearing the migration history for the social_django app, with the cmd
$ python manage.py migrate --fake social_django zero
Follow the tutorial here on how you can do that.
Edit:
You can overcome this by downgrading to a lower version of social auth app django. The latest version was to get to on Django 1.9 was social-auth-app-django==3.1.0
I was able to overcome this by downgrading to a lower version of social auth app django. The latest version I was able to get to on Django 1.9 was social-auth-app-django==3.1.0
I hit the exact same issue. (pip install "python-social-auth==0.2.21" -> set social.apps.django_app.default in INSTALLED_APPS -> python manage.py migrate -> pip install python-social-auth[django] -> set social_django in INSTALLED_APPS -> python manage.py migrate = column "modified" contains null values).
At first I thought this was a conflict between the model and the changes in the migrations file. E.g. from here:
django.db.utils.IntegrityError: column "venue_city" contains null values
Looks like you added null=True after created migration file
However, that doesn't look right because /usr/local/lib/python2.7/site-packages/social_django/models.py does not include null=True:
created = models.DateTimeField(auto_now_add=True)
modified = models.DateTimeField(auto_now=True)
Instead, I suspect the issue is the default value to update existing rows when creating the column is null which immediately conflicts. This is discussed here:
Django Migrations Add Field with Default as Function of Model
I got past this error by adding null=True to the modified field in /usr/local/lib/python2.7/site-packages/social_django/migrations/0009_auto_20191118_0520.py (or wherever social_django is installed) and re-running migrations.
migrations.AddField(
model_name='usersocialauth',
name='created',
field=models.DateTimeField(auto_now_add=True, default=django.utils.timezone.now),
preserve_default=False,
),
migrations.AddField(
model_name='usersocialauth',
name='modified',
- field=models.DateTimeField(auto_now=True),
+ field=models.DateTimeField(auto_now=True, null=True),
),
A better way might be to set default=django.utils.timezone.now as is already done for the created field.
I have a playground for model developement.
When running python manage.py makemigrations the Error
Traceback (most recent call last):
File "manage.py", line 22, in <module>
execute_from_command_line(sys.argv)
File "/home/IPP-HGW/dboe/anaconda2/lib/python2.7/site-packages/django/core/management/__init__.py", line 367, in execute_from_command_line
utility.execute()
File "/home/IPP-HGW/dboe/anaconda2/lib/python2.7/site-packages/django/core/management/__init__.py", line 359, in execute
self.fetch_command(subcommand).run_from_argv(self.argv)
File "/home/IPP-HGW/dboe/anaconda2/lib/python2.7/site-packages/django/core/management/base.py", line 294, in run_from_argv
self.execute(*args, **cmd_options)
File "/home/IPP-HGW/dboe/anaconda2/lib/python2.7/site-packages/django/core/management/base.py", line 345, in execute
output = self.handle(*args, **options)
File "/home/IPP-HGW/dboe/anaconda2/lib/python2.7/site-packages/django/core/management/commands/makemigrations.py", line 173, in handle
migration_name=self.migration_name,
File "/home/IPP-HGW/dboe/anaconda2/lib/python2.7/site-packages/django/db/migrations/autodetector.py", line 47, in changes
changes = self._detect_changes(convert_apps, graph)
File "/home/IPP-HGW/dboe/anaconda2/lib/python2.7/site-packages/django/db/migrations/autodetector.py", line 132, in _detect_changes
self.old_apps = self.from_state.concrete_apps
File "/home/IPP-HGW/dboe/anaconda2/lib/python2.7/site-packages/django/db/migrations/state.py", line 180, in concrete_apps
self.apps = StateApps(self.real_apps, self.models, ignore_swappable=True)
File "/home/IPP-HGW/dboe/anaconda2/lib/python2.7/site-packages/django/db/migrations/state.py", line 242, in __init__
self.render_multiple(list(models.values()) + self.real_models)
File "/home/IPP-HGW/dboe/anaconda2/lib/python2.7/site-packages/django/db/migrations/state.py", line 285, in render_multiple
"for more" % (new_unrendered_models, get_docs_version())
django.db.migrations.exceptions.InvalidBasesError: Cannot resolve bases for [<ModelState: 'main.Component'>, <ModelState: 'main.MagneticConfig'>, <ModelState: 'main.NetStructure'>, <ModelState: 'main.Program'>, <ModelState: 'main.FilePath'>]
This can happen if you are inheriting models from an app with migrations (e.g. contrib.auth)
in an app with no migrations; see https://docs.djangoproject.com/en/1.10/topics/migrations/#dependencies for more
Keeps occuring though i tried a hell of a lot:
of course python manage.py makemigration <appName>
python manage.py migrate <appName>
drop all tables from the app
python manage.py squashmigrations main 0001
emptied the models.py file
uncommented the app in settings
read everything i could find on that
flushing the whole database python manage.py flush
Any idea, how to solve this? Thanks,
Daniel
Edit Nov_29:
Stack trace added
Finally i got the solution. I found out, that the migrations are stored in a file in the application folder. You can delete these by hand. Of course, you need to be very careful with this.
Take a look at this if you got the same problem.
This problem randomly started appearing for me. I know that Django generates its own ids but a lot my code has been using custom AutoFields which HAS been working. I added a new class today and tried to makemigrations but this error keeps showing up.
I DID remove all instances of AutoFields and retried migrating but the problem still persists which leads me to believe it's something else... I don't believe my Django version has changed at all...
Error:
Traceback (most recent call last):
File "manage.py", line 10, in <module>
execute_from_command_line(sys.argv)
File "C:\Python34\lib\site-packages\django\core\management\__init__.py", line
338, in execute_from_command_line
utility.execute()
File "C:\Python34\lib\site-packages\django\core\management\__init__.py", line
330, in execute
self.fetch_command(subcommand).run_from_argv(self.argv)
File "C:\Python34\lib\site-packages\django\core\management\base.py", line 390,
in run_from_argv
self.execute(*args, **cmd_options)
File "C:\Python34\lib\site-packages\django\core\management\base.py", line 441,
in execute
output = self.handle(*args, **options)
File "C:\Python34\lib\site-packages\django\core\management\commands\makemigrat
ions.py", line 98, in handle
loader.project_state(),
File "C:\Python34\lib\site-packages\django\db\migrations\loader.py", line 326,
in project_state
return self.graph.make_state(nodes=nodes, at_end=at_end, real_apps=list(self
.unmigrated_apps))
File "C:\Python34\lib\site-packages\django\db\migrations\graph.py", line 231,
in make_state
project_state = self.nodes[node].mutate_state(project_state, preserve=False)
File "C:\Python34\lib\site-packages\django\db\migrations\migration.py", line 8
3, in mutate_state
operation.state_forwards(self.app_label, new_state)
File "C:\Python34\lib\site-packages\django\db\migrations\operations\fields.py"
, line 51, in state_forwards
state.reload_model(app_label, self.model_name_lower)
File "C:\Python34\lib\site-packages\django\db\migrations\state.py", line 152,
in reload_model
self.apps.render_multiple(states_to_be_rendered)
File "C:\Python34\lib\site-packages\django\db\migrations\state.py", line 262,
in render_multiple
model.render(self)
File "C:\Python34\lib\site-packages\django\db\migrations\state.py", line 546,
in render
body,
File "C:\Python34\lib\site-packages\django\db\models\base.py", line 189, in __
new__
new_class.add_to_class(obj_name, obj)
File "C:\Python34\lib\site-packages\django\db\models\base.py", line 324, in ad
d_to_class
value.contribute_to_class(cls, name)
File "C:\Python34\lib\site-packages\django\db\models\fields\__init__.py", line
989, in contribute_to_class
"A model can't have more than one AutoField."
AssertionError: A model can't have more than one AutoField.
Here's an example of one of my fields:
assetid = models.AutoField(primary_key=True)
A lot of my code already depends on the name itself so changing it is going to be a big issue. Furthermore, this was working perfectly before! I just can't seem to migrate it now. I should mention im using a sqlite3 db.
This is Because Django By default uses AutoField for the id.....so, if you want other fields to be AutoField, then make sure you confirm primary_key=True.
Doing so deletes the id field from the Database.
I have used Mysql as my database. Be sure this problem might not solve in other databases.
Deleted migration files and most recent history and fixed it.
I was having the same problem,
I commented out all the references to that model in all my app files, then run makemigrations and migrate, butit keeps telling that "A model can't have more than one AutoField." even if i am trying to deleting that file.
I had to reset my database.
in my case I deleted id Autofield ,it works fine for me as Django uses Autofield by default
better way is just unapply migrations(meaning run a previous migration).in this way the fields which sometimes are not removed from database are automatically removed from database.Then, after changes you can easily do makemigrations again and then migrate and everything will be good.
I have a problem with south migrations. I still don't understand how this did happen, and what should what path to move to resolve this
Romans-MacBook-Pro:holms$ ./manage.py migrate
cRunning migrations for accounts:
- Nothing to migrate.
- Loading initial data for accounts.
No fixtures found.
Running migrations for allocations:
- Nothing to migrate.
- Loading initial data for allocations.
No fixtures found.
Running migrations for adyen:
- Nothing to migrate.
- Loading initial data for adyen.
No fixtures found.
Running migrations for blog:
- Nothing to migrate.
- Loading initial data for blog.
No fixtures found.
Running migrations for offers:
- Nothing to migrate.
- Loading initial data for offers.
No fixtures found.
Running migrations for orders:
- Migrating forwards to 0011_update_price_fields.
> orders:0002_update_order_contact_information
Traceback (most recent call last):
File "./manage.py", line 15, in <module>
execute_manager(settings)
File "/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/django/core/management/__init__.py", line 438, in execute_manager
utility.execute()
File "/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/django/core/management/__init__.py", line 379, in execute
self.fetch_command(subcommand).run_from_argv(self.argv)
File "/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/django/core/management/base.py", line 191, in run_from_argv
self.execute(*args, **options.__dict__)
File "/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/django/core/management/base.py", line 220, in execute
output = self.handle(*args, **options)
File "/Users/holms/Development/xxx/xxx/settings/../../lib/south/management/commands/migrate.py", line 105, in handle
ignore_ghosts = ignore_ghosts,
File "/Users/holms/Development/xxx/xxx/settings/../../lib/south/migration/__init__.py", line 191, in migrate_app
success = migrator.migrate_many(target, workplan, database)
File "/Users/holms/Development/xxx/xxx/settings/../../lib/south/migration/migrators.py", line 221, in migrate_many
result = migrator.__class__.migrate_many(migrator, target, migrations, database)
File "/Users/holms/Development/xxx/xxx/settings/../../lib/south/migration/migrators.py", line 292, in migrate_many
result = self.migrate(migration, database)
File "/Users/holms/Development/xxx/xxx/settings/../../lib/south/migration/migrators.py", line 125, in migrate
result = self.run(migration)
File "/Users/holms/Development/xxx/xxx/settings/../../lib/south/migration/migrators.py", line 99, in run
return self.run_migration(migration)
File "/Users/holms/Development/xxx/xxx/settings/../../lib/south/migration/migrators.py", line 81, in run_migration
migration_function()
File "/Users/holms/Development/xxx/xxx/settings/../../lib/south/migration/migrators.py", line 57, in <lambda>
return (lambda: direction(orm))
File "/Users/holms/Development/xxx/migrations/0002_update_order_contact_information.py", line 29, in forwards
for o in orders:
File "/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/django/db/models/query.py", line 107, in _result_iter
self._fill_cache()
File "/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/django/db/models/query.py", line 772, in _fill_cache
self._result_cache.append(self._iter.next())
File "/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/django/db/models/query.py", line 273, in iterator
for row in compiler.results_iter():
File "/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/django/db/models/sql/compiler.py", line 680, in results_iter
for rows in self.execute_sql(MULTI):
File "/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/django/db/models/sql/compiler.py", line 735, in execute_sql
cursor.execute(sql, params)
File "/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/django/db/backends/util.py", line 34, in execute
return self.cursor.execute(sql, params)
File "/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/django/db/backends/sqlite3/base.py", line 234, in execute
return Database.Cursor.execute(self, query, params)
django.db.utils.DatabaseError: no such column: orders_order.pre_paid
part of migration file [0002_update_order_contact_information.py] which breaks:
# encoding: utf-8
import datetime
from south.db import db
from south.v2 import DataMigration
from django.db import models
class Migration(DataMigration):
def forwards(self, orm):
Order = models.get_model('orders', 'Order')
orders = Order.all_objects.select_related('buyer')
orders = orders.filter(first_name__isnull=True)
orders = orders.filter(buyer__isnull=False)
orders = orders.exclude(payment_status="UNFINISHED")
userfields = (
'gender', 'birth_date', 'first_name', 'last_name', 'street_number',
You should not interact with your models directly like that. You use django.models, but that version of the models are in a wrong state. You want the state of the models as they were in migration 0002. The south manual states that you should access your models through the orm parameter.
Notice that we use orm.User to access the User model - this gives us the version of User from when this migration was created, so if we want to run the migration in future, it won’t get a completely different, new, User model. source
So you should rewrite the migration like this:
orders = orm.Order.objects.all()
Or even like this:
Order = orm.Order