I am posting this because I am out of ideas. I have tried to find the cause of this issue for the last 2 years.
Say I have 4 model admins:
TabbedAdminMixin, ModelAdmin
a: BasketAdmin
b: ConsumerAdmin
Normal Django ModelAdmin
c: RoleAdmin
d: BranchAdmin
It took me veeeery long to be able to find a way to re-create this error but as of yesterday, I can easily re-create it by using locust to simulate concurrent requests.
When I run locust with 5 concurrent users, each doing requests to /basket//change/ and /consumer//change/ I get a keyerror where render_tab_fieldsets_inlines want to create a, for example, BasketAdmin with fields from ConsumerAdmin's form and vice versa.
When I run the same locust file on /role//change/ and /branch//change/ (vanilla django modeladmins) I don't get keyerrors. This happend locally with runserver and in production with uwsgi.
Any help will be very much appreciated!
In Django admin I have by mistake locked myself by attempting the wrong password.
I later of deleted the user and created another one using manage.py createsuperuser. However, it still says that I'm locked. How do I unlock myself?
It gives the following error when I try to log in using Django admin..
Account locked: too many login attempts. Contact an admin to unlock your account.
Given your error message and 3 strike policy, I assume you have django-axes in your project. You may have it configured to block by IP, regardless of user. That would explain why creating a new user did not work.
Djang-axes documentation gives you an outline of how to clear lockouts.
manage.py axes_reset will reset all lockouts and access records.
If you are currently in production and do not want to risk resetting any valid lockouts, you could try resetting for just your ip
manage.py axes_reset ip will clear lockout/records for ip
So, for example on if you are logged in on the same computer your server is on, you can use localhost:
manage.py axes_reset ip 127.0.0.1
If for some reason that doesn't work, you still have the option of manually deleting your AccessAttempt from your database. This assumes, of course, that you have access to your database, that your user has delete privileges, you are comfortable with sql, and you have not changed the default table name from django-axes.
delete from axes_accessattempt where username ='your_username'; where 'your_username' is the account you wish to unlock.
This can also by done by ip:
delete from axes_accessattempt where ip_address='your_ip'; where 'your_ip' is the ip address from the computer you are using.
Resetting attempts from command line:
python manage.py axes_reset
will reset all lockouts and access records.
python manage.py axes_reset_ip [ip ...]
will clear lockouts and records for the given IP addresses.
python manage.py axes_reset_username [username ...]
will clear lockouts and records for the given usernames.
python manage.py axes_reset_logs (age)
will reset (i.e. delete) AccessLog records that are older than the given age where the default is 30 days.
Yep here's how I did it.. Go to the shell using python manage.py shell
There enter the following commands
from axes.models import AccessAttempt
AccessAttempt.objects.all().delete()
If however the data is needed you must then delete only the object containing your username by
for obj in AccessAttempt.objects.all():
if obj.username == your_username:
obj.delete()
I have a Django 1.5.1 webapp using Celery 3.0.23 with RabbitMQ 3.1.5. and sqlite3.
I can submit jobs using a simple result = status.tasks.mymethod.delay(parameter), all tasks executes correctly:
[2013-09-30 17:04:11,369: INFO/MainProcess] Got task from broker: status.tasks.prova[a22bf0b9-0d5b-4ce5-967a-750f679f40be]
[2013-09-30 17:04:11,566: INFO/MainProcess] Task status.tasks.mymethod[a22bf0b9-0d5b-4ce5-967a-750f679f40be] succeeded in 0.194540023804s: u'Done'
I want to display in a page the latest 10 jobs submitted and their status. Is there a way in Django to get such objects? I see a couple of tables in the database (celery_taskmeta and celery_taskmeta_2ff6b945) and tried some accesses to the objects but Django always displays a AttributeError page.
What is the correct way to access Celery results from Django?
Doing
cel = celery.status.tasks.get(None)
cel = status.tasks.all()
does not work, resulting in the aforementioned AttributeError. (status is the name of my app)
EDIT: I am sure tasks are saved, as this small tutorial says:
By default django-celery stores this state in the Django database. You may consider choosing an alternate result backend or disabling states alltogether (see Result Backends).
Following the links there are only references on how to setup the DB connection and not how to retrieve the results.
Try this:
from djcelery.models import TaskMeta
TaskMeta.objects.all()
I've started working on a Django/Postgres site. Sometimes I work in manage.py shell, and accidentally do some DB action that results in an error. Then I am unable to do any database action at all, because for any database action I try to do, I get the error:
current transaction is aborted, commands ignored until end of transaction block
My current workaround is to restart the shell, but I should find a way to fix this without abandoning my shell session.
(I've read this and this, but they don't give actionable instructions on what to do from the shell.)
You can try this:
from django.db import connection
connection._rollback()
The more detailed discussion of This issue can be found here
this happens to me sometimes, often it's the missing
manage.py migrate
or
manage.py syncdb
as mentioned also here
it also can happen the other way around, if you have a schemamigration pending from your models.py. With south you need to update the schema with.
manage.py schemamigration mymodel --auto
Check this
The quick answer is usually to turn on database level autocommit by adding:
'OPTIONS': {'autocommit': True,}
To the database settings.
I had this error after restoring a backup to a totally empty DB. It went away after running:
./manage syncdb
Maybe there were some internal models missing from the dump...
WARNING: the patch below can possibly cause transactions being left in an open state on the db (at least with postgres). Not 100% sure about that (and how to fix), but I highly suggest not doing the patch below on production databases.
As the accepted answer does not solve my problems - as soon as I get any DB error, I cannot do any new DB actions, even with a manual rollback - I came up with my own solution.
When I'm running the Django-shell, I patch Django to close the DB connection as soon as any errors occur. That way I don't ever have to think about rolling back transactions or handling the connection.
This is the code I'm loading at the beginning of my Django-shell-session:
from django import db
from django.db.backends.util import CursorDebugWrapper
old_execute = CursorDebugWrapper.execute
old_execute_many = CursorDebugWrapper.executemany
def execute_wrapper(*args, **kwargs):
try:
old_execute(*args, **kwargs)
except Exception, ex:
logger.error("Database error:\n%s" % ex)
db.close_connection()
def execute_many_wrapper(*args, **kwargs):
try:
old_execute_many(*args, **kwargs)
except Exception, ex:
logger.error("Database error:\n%s" % ex)
db.close_connection()
CursorDebugWrapper.execute = execute_wrapper
CursorDebugWrapper.executemany = execute_many_wrapper
For me it was a test database without migrations. I was using --keepdb for testing. Running it once without it fixed the error.
There are a lot of useful answers on this topic, but still it can be a challenge to figure out what is the root of the issue. Because of this, I will try to give just a little more context on how I was able to figure out the solution for my issue.
For Django specifically, you want to turn on logs for db queries and before the error is raised, you can find the query that is failing in the console. Run that query directly on db, and you will see what is wrong.
In my case, one column was missing in db, so after migration everything worked correctly.
I hope this will be helpful.
If you happen to get such an error when running migrate (South), it can be that you have lots of changes in database schema and want to handle them all at once. Postgres is a bit nasty on that. What always works, is to break one big migration into smaller steps. Most likely, you're using a version control system.
Your current version
Commit n1
Commit n2
Commit n3
Commit n4 # db changes
Commit n5
Commit n6
Commit n7 # db changse
Commit n8
Commit n9 # db changes
Commit n10
So, having the situation described above, do as follows:
Checkout repository to "n4", then syncdb and migrate.
Checkout repository to "n7", then syncdb and migrate.
Checkout repository to "n10", then syncdb and migrate.
And you're done. :)
It should run flawlessly.
If you are using a django version before 1.6 then you should use Christophe's excellent xact module.
xact is a recipe for handling transactions sensibly in Django applications on PostgreSQL.
Note: As of Django 1.6, the functionality of xact will be merged into the Django core as the atomic decorator. Code that uses xact should be able to be migrated to atomic with just a search-and-replace. atomic works on databases other than PostgreSQL, is thread-safe, and has other nice features; switch to it when you can!
I add the following to my settings file, because I like the autocommit feature when I'm "playing around" but dont want it active when my site is running otherwise.
So to get autocommit just in shell, I do this little hack:
import sys
if 'shell' in sys.argv or sys.argv[0].endswith('pydevconsole.py'):
DATABASES['default']['OPTIONS']['autocommit'] = True
NOTE: That second part is just because I work in PyCharm, which doesnt directly run manage.py
I got this error in Django 1.7. When I read in the documentation that
This problem cannot occur in Django’s default mode and atomic()
handles it automatically.
I got a bit suspicious. The errors happened, when I tried running migrations. It turned out that some of my models had my_field = MyField(default=some_function). Having this function as a default for a field worked alright with sqlite and mysql (I had some import errors, but I managed to make it work), though it seems to not work for postgresql, and it broke the migrations to the point that I didn't event get a helpful error message, but instead the one from the questions title.
Note : pinax 0.7.3
I'm just running a clone of basic_project with sqlite3.
It was working fine yest. Hibernated my laptop and when I opened and
try to login again, I got -
no such table: profiles_profile
Opened the database dev.db using the sqlite3 client and I don't see it
there.
Stopped the server, deleted the DB, did a syncdb which created a
completely new dev.db and it too is missing the table.
I was looking into the views.py of the profiles app, but I'm sure I
didn't do any Dodo in it.
The settings.py has the basic_profiles as installed apps.
The exception shows the query fired as -
'SELECT "profiles_profile"."id", "profiles_profile"."user_id", "profiles_profile"."name", "profiles_profile"."about", "profiles_profile"."location", "profiles_profile"."website" FROM "profiles_profile" WHERE "profiles_profile"."user_id" = ? '
That table structure is the same as of basic_profiles, Can't figure where I could've mistyped while viewing these files.
Any pointers ?
Didn't figure where I messed up, hence I cloned the project again and haven't seen the issue.
Pretty sure it was my fault though.