Develop Reference

Django multitenant migration raises KeyError: "prune"

So I've been working in a project for a while, and haven't really changed the models at all, and therefore haven't done any migrations. Now I needed to add two new fields and delete another one, which should be normally fine. I'm using django-tenants, so my command to run the migrations is ./manage.py migrate_schemas.
Now, whenever I run that, I get the error KeyError: "prune" (the full traceback is below) in what seems to be internal code of Django.
Now, afterwards I tried reverting my changes, so no new migration and running the comnad again, and got the same error. I also thought that maybe the database had gotten "dirty" at some point, so I tried migrating a clean database from scratch, with the same result. The migrations don't even get to start.
Has anyone ever encountered something similar?
The full traceback (I have simplified the paths)
[standard:public] === Starting migration
Traceback (most recent call last):
File ":directory/./manage.py", line 22, in <module>
main()
File ":directory/./manage.py", line 18, in main
execute_from_command_line(sys.argv)
File "$venv/lib/python3.9/site-packages/django/core/management/__init__.py", line 446, in execute_from_command_line
utility.execute()
File "$/lib/python3.9/site-packages/django/core/management/__init__.py", line 440, in execute
self.fetch_command(subcommand).run_from_argv(self.argv)
File "$venv/lib/python3.9/site-packages/django/core/management/base.py", line 402, in run_from_argv
self.execute(*args, **cmd_options)
File "$venv/lib/python3.9/site-packages/django/core/management/base.py", line 448, in execute
output = self.handle(*args, **options)
File "$venv/lib/python3.9/site-packages/django_tenants/management/commands/migrate_schemas.py", line 52, in handle
executor.run_migrations(tenants=[self.PUBLIC_SCHEMA_NAME])
File "$venv/lib/python3.9/site-packages/django_tenants/migration_executors/standard.py", line 11, in run_migrations
run_migrations(self.args, self.options, self.codename, self.PUBLIC_SCHEMA_NAME)
File "$venv/lib/python3.9/site-packages/django_tenants/migration_executors/base.py", line 53, in run_migrations
MigrateCommand(stdout=stdout, stderr=stderr).execute(*args, **options)
File "$venv/lib/python3.9/site-packages/django/core/management/base.py", line 448, in execute
output = self.handle(*args, **options)
File "$venv/lib/python3.9/site-packages/django/core/management/base.py", line 96, in wrapped
res = handle_func(*args, **kwargs)
File "$venv/lib/python3.9/site-packages/django/core/management/commands/migrate.py", line 188, in handle
if options["prune"]:
KeyError: 'prune'

It seems like version incompatibility.
prune option added to Django couple months ago (Jan 22, 2022)
If you want to use newer Django you have to patch django-tenants manually and add --prune argument
def add_arguments(self, parser):
parser.add_argument(
'--prune', action='store_true', dest='prune',
help='Delete nonexistent migrations from the django_migrations table.',
)
PS I couldn't find issue related to prune, so you may create new one ;)

Django 1.10 path is on mount 'C:', start on mount 'D:'

I wanted to add additional fields to a many-to-many relationship and I created a intermediate model called Contact ( the goal is to implement a system that allows the user to follow other users and be followed too).
class Contact(models.Model):
user_from = models.ForeignKey(User,
related_name='rel_from_set')
user_to = models.ForeignKey(User,
related_name='rel_to_set')
created = models.DateTimeField(auto_now_add=True,
db_index=True)
class Meta:
ordering = ('-created',)
def __str__(self):
return '{} follows {}'.format(self.user_from, self.user_to)
I am using the User model provided by Django (from django.contrib.auth.models) . As this model is not one I created if I want to add fields to it, I should (or at least, I think I should ) add them dinamically (with monkey-patch) . So at the end of the models.py file I added the following code:
User.add_to_class('following', models.ManyToManyField('self', through=Contact , related_name='followers', symmetrical=False))
But I runned the python manage.py makemigrations I got the following error :
Migrations for 'auth':
Traceback (most recent call last):
File "manage.py", line 22, in <module>
execute_from_command_line(sys.argv)
File "C:\Program Files (x86)\Python35-32\lib\site-packages\django\core\managem
ent\__init__.py", line 367, in execute_from_command_line
utility.execute()
File "C:\Program Files (x86)\Python35-32\lib\site-packages\django\core\managem
ent\__init__.py", line 359, in execute
self.fetch_command(subcommand).run_from_argv(self.argv)
File "C:\Program Files (x86)\Python35-32\lib\site-packages\django\core\managem
ent\base.py", line 294, in run_from_argv
self.execute(*args, **cmd_options)
File "C:\Program Files (x86)\Python35-32\lib\site-packages\django\core\managem
ent\base.py", line 345, in execute
output = self.handle(*args, **options)
File "C:\Program Files (x86)\Python35-32\lib\site-packages\django\core\managem
ent\commands\makemigrations.py", line 192, in handle
self.write_migration_files(changes)
File "C:\Program Files (x86)\Python35-32\lib\site-packages\django\core\managem
ent\commands\makemigrations.py", line 210, in write_migration_files
migration_string = os.path.relpath(writer.path)
File "C:\Program Files (x86)\Python35-32\lib\ntpath.py", line 574, in relpath
path_drive, start_drive))
ValueError: path is on mount 'C:', start on mount 'D:'
After a quick google search :
"os.relpath does give you a relative path between two directories.
The problem you are encountering is that, on Windows, a relative path doesn't even exist if the two directories are on different drives (which is exactly what the error message says). "
But what is the solution ?
I am using Windows 8 and Django 1.10.

You are running makemigrations from another drive (not from C: where django is installed).
There was a bug with makemigrations on Windows:
see this Django ticket,
and the commit that fixed the bug:
makemigrations crash when creating migrations on a separate drive than where Django is installed
So to fix this error you should:
move your Django project (your Python code) on C: drive
or update your Django version (to Django 1.11)

Django 1.8 Migrations - "NoneType" object has no attribute "_meta"

Attempting to migrate a project from Django 1.7 to 1.8. After wrestling with code errors, I'm able to get migrations to run. However, when I try to migrate, I'm given the error "'NoneType' object has no attribute '_meta'"
There's no reference in the traceback to any of my apps, so I'm unsure of where exactly to go about looking for the bug (as well as which code to include here so I can be more helpful to those trying to help me)
Here's the full text of the traceback
(venv)rtownley#ubuntu:~/Projects/sparrow1/NJ$ ./manage.py makemigrations
No changes detected
(venv)rtownley#ubuntu:~/Projects/sparrow1/NJ$ ./manage.py migrate
Operations to perform:
Synchronize unmigrated apps: staticfiles, editor, djcelery, messages, getty, kombu_transport_django, debug_toolbar, utils, locking, petro, tokenapi, grappelli, django_extensions, selectable
Apply all migrations: adops, taxonomy, issues, editorial, contenttypes, authors, auth, comms, membership, sessions, bento, urlalias, accounts, breaking_news, easy_thumbnails, images, admin, pages, documents, events
Synchronizing apps without migrations:
Creating tables...
Running deferred SQL...
Installing custom SQL...
Running migrations:
Rendering model states...Traceback (most recent call last):
File "./manage.py", line 10, in <module>
execute_from_command_line(sys.argv)
File "/home/rtownley/Projects/sparrow1/venv/lib/python3.4/site-packages/django/core/management/__init__.py", line 338, in execute_from_command_line
utility.execute()
File "/home/rtownley/Projects/sparrow1/venv/lib/python3.4/site-packages/django/core/management/__init__.py", line 330, in execute
self.fetch_command(subcommand).run_from_argv(self.argv)
File "/home/rtownley/Projects/sparrow1/venv/lib/python3.4/site-packages/django/core/management/base.py", line 390, in run_from_argv
self.execute(*args, **cmd_options)
File "/home/rtownley/Projects/sparrow1/venv/lib/python3.4/site-packages/django/core/management/base.py", line 441, in execute
output = self.handle(*args, **options)
File "/home/rtownley/Projects/sparrow1/venv/lib/python3.4/site-packages/django/core/management/commands/migrate.py", line 221, in handle
executor.migrate(targets, plan, fake=fake, fake_initial=fake_initial)
File "/home/rtownley/Projects/sparrow1/venv/lib/python3.4/site-packages/django/db/migrations/executor.py", line 104, in migrate
state = migration.mutate_state(state, preserve=do_run)
File "/home/rtownley/Projects/sparrow1/venv/lib/python3.4/site-packages/django/db/migrations/migration.py", line 83, in mutate_state
operation.state_forwards(self.app_label, new_state)
File "/home/rtownley/Projects/sparrow1/venv/lib/python3.4/site-packages/django/db/migrations/operations/fields.py", line 51, in state_forwards
state.reload_model(app_label, self.model_name_lower)
File "/home/rtownley/Projects/sparrow1/venv/lib/python3.4/site-packages/django/db/migrations/state.py", line 97, in reload_model
related_models = get_related_models_recursive(old_model)
File "/home/rtownley/Projects/sparrow1/venv/lib/python3.4/site-packages/django/db/migrations/state.py", line 57, in get_related_models_recursive
rel_app_label, rel_model_name = rel_mod._meta.app_label, rel_mod._meta.model_name
AttributeError: 'NoneType' object has no attribute '_meta'
Other pieces that could potentially be at play:
-I have a custom handler that listens for the save event, serializes the data, and creates an identical object in Mongo
-Operating out of a virtual environment running Python3.4
Any thoughts on where to go about hunting for the error? Thanks, and sorry I can't provide more code yet!

Thanks to meiamsome, I figured it out: one of my models had a ForeignKey relationship to a model that no longer existed (I had removed it, and a Git merge had added it back). Thanks for the help all!

Doubt this will help anyone but I had single quotes around my model name instead of referencing the class model object itself. Removing the quotes seemed to help.

Django syncdb works in SQLite, failing in MySQL

I'm a newbie to MySQL, and haven't used Django for anything in production. I've been doing development under Windows 7 with SQLite, and am trying to move the code to a Linux server running MySQL.
When I ran syncdb, it created the first three tables then threw an error:
Traceback (most recent call last):
File "manage.py", line 10, in <module>
execute_from_command_line(sys.argv)
File "/home/gsdemo01/project_file/lib/python3.3/site-packages/django/core/management/__init__.py", line 399, in execute_from_command_line
utility.execute()
File "/home/gsdemo01/project_file/lib/python3.3/site-packages/django/core/management/__init__.py", line 392, in execute
self.fetch_command(subcommand).run_from_argv(self.argv)
File "/home/gsdemo01/project_file/lib/python3.3/site-packages/django/core/management/base.py", line 242, in run_from_argv
self.execute(*args, **options.__dict__)
File "/home/gsdemo01/project_file/lib/python3.3/site-packages/django/core/management/base.py", line 285, in execute
output = self.handle(*args, **options)
File "/home/gsdemo01/project_file/lib/python3.3/site-packages/django/core/management/base.py", line 415, in handle
return self.handle_noargs(**options)
File "/home/gsdemo01/project_file/lib/python3.3/site-packages/django/core/management/commands/syncdb.py", line 96, in handle_noargs
sql, references = connection.creation.sql_create_model(model, self.style, seen_models)
File "/home/gsdemo01/project_file/lib/python3.3/site-packages/django/db/backends/creation.py", line 83, in sql_create_model
model, f, known_models, style)
TypeError: sql_for_inline_foreign_key_references() takes 4 positional arguments but 5 were given
The model immediately after the last one created is a Metaclass, followed by a class that inherits from it:
class Location(models.Model):
# con = models.ForeignKey(Convention)
name = models.CharField(max_length=40)
scheduler = models.ForeignKey(GCUser, blank=True, null=True)
class Meta:
abstract = True
def __str__(self):
return self.name
class Room(Location):
tag = models.CharField(max_length=10)
capacity = models.PositiveSmallIntegerField(default=100)
This works fine with SQLite, so it seems like it has to be either a problem with the python connector package or with MySQL itself.
Thanks in advance for any help.
Update:
Through trial and error I've determined that the issue is definitely with the Foreign Key field. If I comment that out the table is created correctly. As far as I can tell the modification suggested by Yogesh matches what we already have in the code, so if anyone has any other suggestions I'd love to hear them.

If you using these virsions Python3.3 Django1.6 use MySql official middleware mysql-connector-python-1.1.4-py3.3.
The solution:
find: creation.py within your site-packages and Modification method: sql_for_inline_foreign_key_references is: you can only modify the method parameters
def sql_for_inline_foreign_key_references (self, model, field, known_models, style):
This is not a good solution,this is alternate for remove error.

I'm posting the solution here for the benefit of future users who run into this. It took many hours on the part of my partner to ferret this out.
The simple part of the solution is to edit creation.py to change
def sql_for_inline_foreign_key_references (self, model, field, known_models, style):
to
def sql_for_inline_foreign_key_references (self, *args):
There's a routine with the same name and almost the same syntax in site-packages/django/db/backends/creation.py, but you want the one in site-packages/django/db/backends/mysql/creation.py.
You're not done yet, though, because the module gets copied to site-packages/mysql/connector/django/creation.py, and that doesn't happen automatically on edit, so you'll need to copy it over manually. I deleted the .pyc file for good measure, but that "shouldn't" have been necessary.
Of course, none of this should have been necessary...

For Mac users using MacOSX 10.9 (aka Mavericks) or up, this solution works perfectly, but be sure you're going to the right place if you're using python3 to edit the creation.py file from the mysql.connector:
/Library/Frameworks/Python.framework/Versions/3.3/lib/python3.3/site-packages/mysql/connector/django/creation.py
FYI:
Environment: Python3 / Mysql-connector-1.1.4 / Django-1.6.1

Testing Django database manipulation scripts with test database

I am attempting to setup the django testing environment to test a script we use to load data into our data visualization web app. It is "external" to the actual django app, so it doesn't seem appropriate or clean to use the manage.py test facility.
I have followed the instructions found in the django docs to write my own test module, but when I reach a statement that actually tries to access the database I get an error saying that a table does not exist.
Is there something else I need to do to make sure that the test database is created with all of the needed tables?
For reference, here is the code from my test case:
import os
import sys
sys.path.append(os.curdir)
os.environ['DJANGO_SETTINGS_MODULE'] = 'visualization_app.settings'
from django.utils import unittest
from django.test.utils import setup_test_environment
from topic_modeling import settings
# The module to be tested
import analysis_import
setup_test_environment()
class CreateAnalysisTestCase(unittest.TestCase):
def test_analysis_creation(self):
self.assertTrue(analysis_import.create_analysis('a_name', 'a description'))
if __name__ == '__main__':
unittest.main()
The error I get looks like this:
ERROR: test_analysis_creation (__main__.CreateAnalysisTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
File "import_scripts/tests.py", line 20, in test_analysis_creation
self.assertTrue(analysis_import.create_analysis('a_name', 'a description'))
File "/home/dan/programmingProjects/topical_guide/import_scripts/analysis_import.py", line 117, in create_analysis
Analysis.objects.get(name=name, dataset=dataset)
File "/usr/local/lib/python2.7/dist-packages/Django-1.3-py2.7.egg/django/db/models/manager.py", line 132, in get
return self.get_query_set().get(*args, **kwargs)
File "/usr/local/lib/python2.7/dist-packages/Django-1.3-py2.7.egg/django/db/models/query.py", line 344, in get
num = len(clone)
File "/usr/local/lib/python2.7/dist-packages/Django-1.3-py2.7.egg/django/db/models/query.py", line 82, in __len__
self._result_cache = list(self.iterator())
File "/usr/local/lib/python2.7/dist-packages/Django-1.3-py2.7.egg/django/db/models/query.py", line 273, in iterator
for row in compiler.results_iter():
File "/usr/local/lib/python2.7/dist-packages/Django-1.3-py2.7.egg/django/db/models/sql/compiler.py", line 680, in results_iter
for rows in self.execute_sql(MULTI):
File "/usr/local/lib/python2.7/dist-packages/Django-1.3-py2.7.egg/django/db/models/sql/compiler.py", line 735, in execute_sql
cursor.execute(sql, params)
File "/usr/local/lib/python2.7/dist-packages/Django-1.3-py2.7.egg/django/db/backends/util.py", line 34, in execute
return self.cursor.execute(sql, params)
File "/usr/local/lib/python2.7/dist-packages/Django-1.3-py2.7.egg/django/db/backends/sqlite3/base.py", line 234, in execute
return Database.Cursor.execute(self, query, params)
DatabaseError: no such table: visualize_analysis

Strictly speaking, test databases are intended to be created, used to run unit tests and then destroyed. They're not really a place to "test" a data loading script. Why not just use your standard dev database? There shouldn't be anything there that you can't get back, have a backup for, etc., and it's pretty much designed for this sort of destructive behavior.

As far as I can see, the module you are testing still uses django's ORM system to read the database, so there is anything wrong about using manage.py to run your test. You can use
./manage.py test analysis_import
to only run test codes which reside in analysis_import module. In this way, you can still run only the tests for this module, but avoid the trouble of writing your own test module.
Then let us know if you still have the same problem.