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 ;)
Related
So I have an extended User model (extended AbstractUser) called Profile. This was in a seperate app called "profiles". I was plugging in the standard login and realised it was looking for a "profile" app name as standard, so I renamed it (directories, code, DB schema) which I thought should work. app_name was actually already set to "profile" in apps.py, so didn't need to rename url references.
No dice. I get the error in the title.
So I removed all migrations (I'm at the stage where I can still do this OK :) ) and deleted the sqlite DB that I'm currently working with, thinking I'd just rerun the migrations and recreate everything.
Same error.
The stack trace is:
λ python manage.py makemigrations
Traceback (most recent call last):
File "manage.py", line 21, in <module>
main()
File "manage.py", line 17, in main
execute_from_command_line(sys.argv)
File "C:\Users\mjnic\.virtualenvs\pyp-E_0Se9Bl\lib\site-packages\django\core\management\__init__.py", line 381, in execute_from_command_line
utility.execute()
File "C:\Users\mjnic\.virtualenvs\pyp-E_0Se9Bl\lib\site-packages\django\core\management\__init__.py", line 375, in execute
self.fetch_command(subcommand).run_from_argv(self.argv)
File "C:\Users\mjnic\.virtualenvs\pyp-E_0Se9Bl\lib\site-packages\django\core\management\base.py", line 323, in run_from_argv
self.execute(*args, **cmd_options)
File "C:\Users\mjnic\.virtualenvs\pyp-E_0Se9Bl\lib\site-packages\django\core\management\base.py", line 361, in execute
self.check()
File "C:\Users\mjnic\.virtualenvs\pyp-E_0Se9Bl\lib\site-packages\django\core\management\base.py", line 390, in check
include_deployment_checks=include_deployment_checks,
File "C:\Users\mjnic\.virtualenvs\pyp-E_0Se9Bl\lib\site-packages\django\core\management\base.py", line 377, in _run_checks
return checks.run_checks(**kwargs)
File "C:\Users\mjnic\.virtualenvs\pyp-E_0Se9Bl\lib\site-packages\django\core\checks\registry.py", line 72, in run_checks
new_errors = check(app_configs=app_configs)
File "C:\Users\mjnic\.virtualenvs\pyp-E_0Se9Bl\lib\site-packages\debug_toolbar\apps.py", line 18, in check_middleware
from debug_toolbar.middleware import DebugToolbarMiddleware
File "C:\Users\mjnic\.virtualenvs\pyp-E_0Se9Bl\lib\site-packages\debug_toolbar\middleware.py", line 12, in <module>
from debug_toolbar.toolbar import DebugToolbar
File "C:\Users\mjnic\.virtualenvs\pyp-E_0Se9Bl\lib\site-packages\debug_toolbar\toolbar.py", line 141, in <module>
urlpatterns = DebugToolbar.get_urls()
File "C:\Users\mjnic\.virtualenvs\pyp-E_0Se9Bl\lib\site-packages\debug_toolbar\toolbar.py", line 134, in get_urls
for panel_class in cls.get_panel_classes():
File "C:\Users\mjnic\.virtualenvs\pyp-E_0Se9Bl\lib\site-packages\debug_toolbar\toolbar.py", line 116, in get_panel_classes
import_string(panel_path) for panel_path in dt_settings.get_panels()
File "C:\Users\mjnic\.virtualenvs\pyp-E_0Se9Bl\lib\site-packages\debug_toolbar\toolbar.py", line 116, in <listcomp>
import_string(panel_path) for panel_path in dt_settings.get_panels()
File "C:\Users\mjnic\.virtualenvs\pyp-E_0Se9Bl\lib\site-packages\django\utils\module_loading.py", line 17, in import_string
module = import_module(module_path)
File "C:\Users\mjnic\.virtualenvs\pyp-E_0Se9Bl\lib\importlib\__init__.py", line 127, in import_module
return _bootstrap._gcd_import(name[level:], package, level)
File "C:\Users\mjnic\.virtualenvs\pyp-E_0Se9Bl\lib\site-packages\debug_toolbar\panels\profiling.py", line 1, in <module>
import cProfile
File "D:\Python\Python37-32\Lib\cProfile.py", line 22, in <module>
run.__doc__ = _pyprofile.run.__doc__
AttributeError: module 'profile' has no attribute 'run'
What have I missed as part of this rename?
Any other info I've missed posting that would help? (I've searched for any instance of "profiles", but everything is correctly renamed now, and the app was working OK prior to this, so it's purely this rename that's messed it up).
Edit: Can it be that "profile" conflicts with some internal python routine? That cProfile.py file under the python installation is defined as
#! /usr/bin/env python3
"""Python interface for the 'lsprof' profiler.
Compatible with the 'profile' module.
"""
Now that can't be anything to do with my project? Do I just need to call my app/extended user model something other than "profile"?
OK. So yes, it's a naming clash. I've renamed my "Profile" model and "profile" app as "UserProfile" and "user_profile" and updated everything accordingly. It all seems to work now ...
Just putting an answer here in case anybody comes along in the future with the same issue!
In my case, it was profile.py file.
Delete the file and try again.
In my case was the conflict between app - 'profile' and 'django-debug-toolbar':
I rename my app from 'profile' to 'account' and it solved the problem
Working on a fairly large/complex Django project with a team, we occasionally see runserver crash with ValueError: embedded null byte. We restart runserver and it's fine - either for a few minutes or a few days. We can detect no pattern to what causes the crashes (seems totally random). Fortunately it's only happening in local development, not on our servers, but I'm worried that it will bite us down the road.
The stack trace below does not point to any location in our code -- seems to come either from Django or the virtualenv itself.
Using Django 1.9.8, Python 3.5.0, on El Capitan.
I can't see any way to debug this. Theories?
Traceback (most recent call last):
File "manage.py", line 10, in <module>
execute_from_command_line(sys.argv)
File "/path/to/virtualenvs/ourproj/lib/python3.5/site-packages/django/core/management/__init__.py", line 353, in execute_from_command_line
utility.execute()
File "/path/to/virtualenvs/ourproj/lib/python3.5/site-packages/django/core/management/__init__.py", line 345, in execute
self.fetch_command(subcommand).run_from_argv(self.argv)
File "/path/to/virtualenvs/ourproj/lib/python3.5/site-packages/django/core/management/base.py", line 348, in run_from_argv
self.execute(*args, **cmd_options)
File "/path/to/virtualenvs/ourproj/lib/python3.5/site-packages/django/core/management/commands/runserver.py", line 54, in execute
super(Command, self).execute(*args, **options)
File "/path/to/virtualenvs/ourproj/lib/python3.5/site-packages/django/core/management/base.py", line 399, in execute
output = self.handle(*args, **options)
File "/path/to/virtualenvs/ourproj/lib/python3.5/site-packages/django/core/management/commands/runserver.py", line 93, in handle
self.run(**options)
File "/path/to/virtualenvs/ourproj/lib/python3.5/site-packages/django/core/management/commands/runserver.py", line 102, in run
autoreload.main(self.inner_run, None, options)
File "/path/to/virtualenvs/ourproj/lib/python3.5/site-packages/django/utils/autoreload.py", line 333, in main
reloader(wrapped_main_func, args, kwargs)
File "/path/to/virtualenvs/ourproj/lib/python3.5/site-packages/django/utils/autoreload.py", line 299, in python_reloader
reloader_thread()
File "/path/to/virtualenvs/ourproj/lib/python3.5/site-packages/django/utils/autoreload.py", line 275, in reloader_thread
change = fn()
File "/path/to/virtualenvs/ourproj/lib/python3.5/site-packages/django/utils/autoreload.py", line 204, in code_changed
for filename in gen_filenames():
File "/path/to/virtualenvs/ourproj/lib/python3.5/site-packages/django/utils/autoreload.py", line 114, in gen_filenames
basedirs = [os.path.abspath(basedir) for basedir in basedirs
File "/path/to/virtualenvs/ourproj/lib/python3.5/site-packages/django/utils/autoreload.py", line 115, in <listcomp>
if os.path.isdir(basedir)]
File "/path/to/virtualenvs/ourproj/bin/../lib/python3.5/genericpath.py", line 42, in isdir
st = os.stat(s)
ValueError: embedded null byte
One of the AppConfig objects has null byte in its path attribute.
One of the LOCALE_PATHS has null byte.
One of the files is in the "wrong" encoding, so Django treats something has null byte (e. g. AppConfig.path).
One of the files or directories in project directory has null byte (\x00) in its name.
Other reason.
autoreload.py lines related to this issue. os.path.isdir() raises ValueError: embedded null byte if its argument has null byte, e. g. os.path.isdir('foo\x00bar').
You can try to edit autoreload.py, comment out these lines temporarily:
basedirs = [os.path.abspath(basedir) for basedir in basedirs
if os.path.isdir(basedir)]
and add this:
temp_basedirs = []
for basedir in basedirs:
try:
if os.path.isdir(basedir):
temp_basedirs.append(os.path.abspath(basedir))
except ValueError:
print(basedir)
raise
basedirs = temp_basedirs
I just generated the migration scripts through ./manage.py schemamigration --auto and ran it. I get the following error. I am stumped as to what it could mean. I have been using SET_NULL for a while now. So this is something new that didn't occur earlier. Any idea what could be wrong?
Traceback (most recent call last):
File "./manage.py", line 16, in
execute_from_command_line(sys.argv)
File "/home/vivekv/.environments/fantain/local/lib/python2.7/site-packages/django/core/management/init.py", line 399, in execute_from_command_line
utility.execute()
File "/home/vivekv/.environments/fantain/local/lib/python2.7/site-packages/django/core/management/init.py", line 392, in execute
self.fetch_command(subcommand).run_from_argv(self.argv)
File "/home/vivekv/.environments/fantain/local/lib/python2.7/site-packages/django/core/management/base.py", line 242, in run_from_argv
self.execute(*args, **options.dict)
File "/home/vivekv/.environments/fantain/local/lib/python2.7/site-packages/django/core/management/base.py", line 285, in execute
output = self.handle(*args, **options)
File "/home/vivekv/.environments/fantain/local/lib/python2.7/site-packages/south/management/commands/schemamigration.py", line 111, in handle
old_orm = last_migration.orm(),
File "/home/vivekv/.environments/fantain/local/lib/python2.7/site-packages/south/utils/init.py", line 62, in method
value = function(self)
File "/home/vivekv/.environments/fantain/local/lib/python2.7/site-packages/south/migration/base.py", line 432, in orm
return FakeORM(self.migration_class(), self.app_label())
File "/home/vivekv/.environments/fantain/local/lib/python2.7/site-packages/south/orm.py", line 48, in FakeORM
_orm_cache[args] = _FakeORM(*args)
File "/home/vivekv/.environments/fantain/local/lib/python2.7/site-packages/south/orm.py", line 134, in init
self.retry_failed_fields()
File "/home/vivekv/.environments/fantain/local/lib/python2.7/site-packages/south/orm.py", line 377, in retry_failed_fields
fname, modelname, e
ValueError: Cannot successfully create field 'winner' for model 'match': 'module' object has no attribute 'SET_NULL'.
OK This is not a valid question. I am embarrassed to admit I made a small tweak on the migration script that caused the problem. Please ignore this question - seems like I dont have a way to delete a question I had asked!
I wrote the solution here
Short answer: use models.SET_NULL instead of "SET_NULL".
You need to replace this in all migrations which have b"SET_NULL"
It's difficult to tell what is being asked here. This question is ambiguous, vague, incomplete, overly broad, or rhetorical and cannot be reasonably answered in its current form. For help clarifying this question so that it can be reopened, visit the help center.
Closed 10 years ago.
What may be going on here? This is a problem on two separate Macs of mine - one Eclipse install and one Aptana Studio. After I answer "yes" to create a superuser the first time I Sync DB, I get these errors.
Performing Sync db outside of PyDev (via terminal, etc) seems to work fine.
You just installed Django's auth system, which means you don't have
any superusers defined. Would you like to create one now? (yes/no):
yes Traceback (most recent call last): File
"/Users/mac2/Documents/workspace/helloworld/manage.py", line 10, in
execute_from_command_line(sys.argv) File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/django/core/management/init.py",
line 443, in execute_from_command_line
utility.execute() File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/django/core/management/init.py",
line 382, in execute
self.fetch_command(subcommand).run_from_argv(self.argv) File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/django/core/management/base.py",
line 196, in run_from_argv
self.execute(*args, **options.dict) File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/django/core/management/base.py",
line 232, in execute
output = self.handle(*args, **options) File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/django/core/management/base.py",
line 371, in handle
return self.handle_noargs(**options) File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/django/core/management/commands/syncdb.py",
line 110, in handle_noargs
emit_post_sync_signal(created_models, verbosity, interactive, db) File
"/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/django/core/management/sql.py",
line 189, in emit_post_sync_signal
interactive=interactive, db=db) File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/django/dispatch/dispatcher.py",
line 172, in send
response = receiver(signal=self, sender=sender, **named) File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/django/contrib/auth/management/init.py",
line 73, in create_superuser
call_command("createsuperuser", interactive=True, database=db) File
"/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/django/core/management/init.py",
line 150, in call_command
return klass.execute(*args, **defaults) File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/django/core/management/base.py",
line 232, in execute
output = self.handle(*args, **options) File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/django/contrib/auth/management/commands/createsuperuser.py", line 70, in handle
default_username = get_default_username() File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/django/contrib/auth/management/init.py",
line 105, in get_default_username
default_username = get_system_username() File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/django/contrib/auth/management/init.py",
line 85, in get_system_username
return getpass.getuser().decode(locale.getdefaultlocale()[1]) TypeError: decode() argument 1 must be string, not None Finished
"/Users/mac2/Documents/workspace/helloworld/manage.py syncdb"
execution.
The error returned indicates that the call to decode is failing with a None argument:
"/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/django/contrib/auth/management/init.py", line 85, in get_system_username return getpass.getuser().decode(locale.getdefaultlocale()[1]) TypeError: decode() argument 1 must be string, not None Finished
The problem there is that locale.getdefaultlocale() returns a tuple with the environment variable LANG (see http://docs.python.org/library/locale.html). If you open terminal, where syncdb works, and type echo $LANG, my guess is you'll get something like en_US.UTF-8. Similarly, I imagine Python on your command line returns something like this:
>>> import locale
>>> locale.getdefaultlocale()
('en_US', 'UTF-8')
However, if you run that same command from within Eclipse, where the LANG environment variable isn't set, you get (None, None).
Try setting the LANG environment variable in Eclipse (Run Configurations... > Environment), and then running syncdb. You might have to play a bit with where the variable is set (i.e., in the Run Config versus the Project itself). Does that fix the problem?
I use Django and just dropped and re-created database in order to flush table data. Now when I'm trying to do any db-related task, I get:
./manage.py sql portfolio
Traceback (most recent call last):
File "./manage.py", line 11, in <module>
execute_manager(settings)
File "/usr/lib/pymodules/python2.6/django/core/management/__init__.py", line 362, in execute_manager
utility.execute()
File "/usr/lib/pymodules/python2.6/django/core/management/__init__.py", line 303, in execute
self.fetch_command(subcommand).run_from_argv(self.argv)
File "/usr/lib/pymodules/python2.6/django/core/management/base.py", line 195, in run_from_argv
self.execute(*args, **options.__dict__)
File "/usr/lib/pymodules/python2.6/django/core/management/base.py", line 222, in execute
output = self.handle(*args, **options)
File "/usr/lib/pymodules/python2.6/django/core/management/base.py", line 286, in handle
app_output = self.handle_app(app, **options)
File "/usr/lib/pymodules/python2.6/django/core/management/commands/sql.py", line 10, in handle_app
return u'\n'.join(sql_create(app, self.style)).encode('utf-8')
File "/usr/lib/pymodules/python2.6/django/core/management/sql.py", line 28, in sql_create
tables = connection.introspection.table_names()
File "/usr/lib/pymodules/python2.6/django/db/backends/__init__.py", line 491, in table_names
return self.get_table_list(cursor)
File "/usr/lib/pymodules/python2.6/django/db/backends/postgresql/introspection.py", line 30, in get_table_list
AND pg_catalog.pg_table_is_visible(c.oid)""")
File "/usr/lib/pymodules/python2.6/django/db/backends/util.py", line 19, in execute
return self.cursor.execute(sql, params)
psycopg2.InternalError: BŁĄD: current transaction is aborted, commands ignored until end of transaction block
As you can see it's just code generation, so there should not be any problem with transaction. What's going on? :-(
That error means that something happened to your Postgres process that caused it to fail in the middle of a transaction but the transaction was never committed or rolled back, so it's stuck.
Basically you need to either issue a rollback command (this can be done from the Django shell, oftentimes), or kill the postgres process.
Note that (depending on your server config) Postgres processes keep running even if Django is not, so you're getting the same error every time because it's probably still stuck in the same process.
If you've done that and it's still doing this every time then it means you're triggering the error in your actual code somewhere and need to go digging.
Check postgres log file, to see the actual query responsible for database error. and try to find which portion of django makes this query.
Also check out https://github.com/django-debug-toolbar/django-debug-toolbar/issues/351 .
It says django-debug-toolbar might be responsible for this error. Try disabling it.