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.
Related
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 ;)
Impacted versions:
12.0
Steps to reproduce:
I have made a customization to postpone the creation of pos order picking
and delegate the task to a job
some time i get the error below
Current behavior:
2020-06-18 17:49:24,588 1370 ERROR cafe9.rabeh.io odoo.addons.base.models.ir_cron: Call from cron POS Orders: Process Pending Orders for server action #610 failed in Job #24
Traceback (most recent call last):
File "/opt/rabeh/odoo/odoo/addons/base/models/ir_cron.py", line 102, in _callback
self.env['ir.actions.server'].browse(server_action_id).run()
File "/opt/rabeh/odoo/odoo/addons/base/models/ir_actions.py", line 569, in run
res = func(action, eval_context=eval_context)
File "/opt/rabeh/odoo/odoo/addons/base/models/ir_actions.py", line 445, in run_action_code_multi
safe_eval(action.sudo().code.strip(), eval_context, mode="exec", nocopy=True) # nocopy
allows to return 'action'
File "/opt/rabeh/odoo/odoo/tools/safe_eval.py", line 350, in safe_eval
return unsafe_eval(c, globals_dict, locals_dict)
File "/opt/rabeh-12/rabeh_addons/pos_pending_session/models/pos_order.py", line 68, in pending_picking_creation
po_order.create_picking()
File "/opt/rabeh-12/rabeh_addons/pos_pending_session/models/pos_order.py", line 36, in
create_picking
res = super(PosOrder, orders).create_picking()
File "/opt/rabeh/odoo/addons/point_of_sale/models/pos_order.py", line 841, in create_picking
order._force_picking_done(order_picking)
File "/opt/rabeh/odoo/addons/point_of_sale/models/pos_order.py", line 856, in _force_picking_done
picking.action_done()
File "/opt/rabeh/odoo/addons/stock/models/stock_picking.py", line 631, in action_done
todo_moves._action_done()
File "/opt/rabeh/odoo/addons/purchase_stock/models/stock.py", line 96, in _action_done
res = super(StockMove, self)._action_done()
File "/opt/rabeh/odoo/addons/stock_account/models/stock.py", line 389, in _action_done
res = super(StockMove, self)._action_done()
File "/opt/rabeh/odoo/addons/stock/models/stock_move.py", line 1137, in _action_done
moves_todo.mapped('move_line_ids')._action_done()
File "/opt/rabeh/odoo/addons/stock/models/stock_move_line.py", line 445, in _action_done
Quant._update_available_quantity(ml.product_id, ml.location_dest_id, quantity, lot_id=ml.lot_id, package_id=ml.result_package_id, owner_id=ml.owner_id, in_date=in_date)
File "/opt/rabeh/odoo/addons/stock/models/stock_quant.py", line 216, in _update_available_quantity
self._cr.execute("SELECT 1 FROM stock_quant WHERE id = %s FOR UPDATE NOWAIT", [quant.id], log_exceptions=False)
File "/opt/rabeh/odoo/odoo/sql_db.py", line 148, in wrapper
return f(self, *args, **kwargs)
File "/opt/rabeh/odoo/odoo/sql_db.py", line 225, in execute
res = self._obj.execute(query, params)
psycopg2.errors.SerializationFailure: could not serialize access due to concurrent update
Expected behavior:
i think this line should generate could not obtain lock
i was just wondering when it could generate "could not serialize access due to concurrent update"
It could have obtained the lock, as the lock is currently available. But it had been locked at some previous point which overlaps with the current transaction's snapshot. So obtaining the lock is possible, but would create a serialization problem if it were to acquire it. Reporting that as a serialization failure seems like the correct outcome.
Using FOR UPDATE NOWAIT in a transaction with elevated isolation level seems inconsistent, or at least unnecessary. What are you hoping to accomplish by doing this? Your description of "while creating pos picking from a job" doesn't elucidate this for me. Is that some odoo-specific jargon?
I am using neptune's graph database with gremlin queries through python, to store addresses in a database. Most of the queries execute fine, but once i try the following query neptune returns a internal failure exception:
g.V(address).outE('isPartOf').inV().
dedup().as_('groupNode').
inE('isPartOf').outV().dedup().as_('children').
addE('isPartOf').to(group).
select('groupNode').drop().
fold().
coalesce(__.unfold(),
g.V(address).addE('isPartOf').to(group)).next()
Every address has the possibility to belong to a group. when the address is already assigned to a group, i try to take all addresses assigned to that group and assign them to a new group, while deleting the old group. If the address is not yet assigned to a group i simply want to assign the address to the new group immediately.
If i try this query on it's own everything executes perfectly (although it is a bit of a slow query). However once i try to execute this query in parallel on more addresse this query fails with the following error:
Traceback (most recent call last):
File "/usr/lib64/python2.7/threading.py", line 804, in __bootstrap_inner
self.run()
File "gremlinExample.py", line 30, in run
processTx(self.tx, self.g, self.parentBlock)
File "gremlinExample.py", line 152, in processTx
g.V(address).outE('isPartOf').inV().dedup().as_('groupNode').inE('isPartOf').outV().dedup().as_('children').select('children').addE('isPartOf').to(group).select('groupNode').drop().fold().coalesce(__.unfold(), g.V(address).addE('isPartOf').to(group)).next()
File "/home/ec2-user/.local/lib/python2.7/site-packages/gremlin_python/process/traversal.py", line 70, in next
return self.__next__()
File "/home/ec2-user/.local/lib/python2.7/site-packages/gremlin_python/process/traversal.py", line 43, in __next__
self.traversal_strategies.apply_strategies(self)
File "/home/ec2-user/.local/lib/python2.7/site-packages/gremlin_python/process/traversal.py", line 346, in apply_strategies
traversal_strategy.apply(traversal)
File "/home/ec2-user/.local/lib/python2.7/site-packages/gremlin_python/driver/remote_connection.py", line 143, in apply
remote_traversal = self.remote_connection.submit(traversal.bytecode)
File "/home/ec2-user/.local/lib/python2.7/site-packages/gremlin_python/driver/driver_remote_connection.py", line 54, in submit
results = result_set.all().result()
File "/usr/lib/python2.7/site-packages/concurrent/futures/_base.py", line 405, in result
return self.__get_result()
File "/usr/lib/python2.7/site-packages/concurrent/futures/_base.py", line 357, in __get_result
raise type(self._exception), self._exception, self._traceback
GremlinServerError: 500: {"requestId":"a42015b7-6b22-4bd1-9e7d-e3252e8f3ab6","code":"InternalFailureException","detailedMessage":"Can not get the attachable from the host vertex: v[64b32957-ef71-be47-c8d7-0109cfc4d9fd]-/->neptunegraph[org.apache.commons.configuration.PropertiesConfiguration#6db0f02]"}
To my knowledge execution in parallel shouldn't be the problem, since every query simply get's queued at the database (exactly for this reason i tried to create a query which executes the whole task at once).
Excuses for any bad English, it is not my native language
For anyone else who's looking for an update here - the OP was able to resolve the issue by replacing .next() with a .iterate(). Some followups were needed to understand the query and data better, but the OP has abandoned the project and moved to another solution.
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"