I have a Django-CMS 2.4.1 project that always gives me the warning:
DeprecationWarning: Implicit manager CMSPlugin.tree will be removed in django-mptt 0.6. Explicitly define a TreeManager() on your model to remove this warning.
This only occurs in production - not in dev.
I tried:
./manage.py cms fix-mptt
which gives me the output (after the same warning as above):
fixing mptt page tree
fixing mptt plugin tree
all done
But... this does not solve the problem, e.g. if I repeat the command it does the same thing again, with the same warning.
The warning doesn't seem to be doing any harm yet, but I imagine it will with the next version of django-mptt. Can anyone give me any advice?
thanks
Harmless but utterly annoying, make the b*tch shut up:
CMSPlugin.tree = CMSPlugin.objects
in any module of early execution (models.py for example).
You can safely ignore that warning in any case.
It's just telling you that django CMS's use of Django MPTT is relying on something that will be removed in a future version.
Related
I'm working on a Django Project with Wagtail which uses two databases. The first one is the standard sql lite database for all django models (called db_tool.sqlite3), the other one is also sql lite but for a wagtail integration (called db.sqlite3).
I wanted to migrate to the db_tool.sqlite3 with the following command
python manage.py make migrations
python manage.py migrate --database db_tool
but now I get the following error message regarding wagtail, which I never got before.
django.db.utils.IntegrityError: NOT NULL constraint failed: wagtailcore_page.draft_title
First of all: I don't understand this, because I named the db_tool in particular and I wonder, why the wagtail integration raises an error when I try to migrate to db_tool.
Second: I see no particular field at my wagtail-pages called draft_title and I don't have any draft page at the moment.
Third: the error message also relates to a migration file of wagtail that can be found in the side-packages (see below). So maybe this is the root of the error, but I don't understand the correlation to the other error message, because since now it worked fine and I changed nothing exept of some content of my wagtail pages.
File "C:\Users\pubr\.conda\envs\iqps_web\lib\site-packages\wagtail\core\migrations\0001_squashed_0016_change_page_url_path_to_text_field.py", line 23, in initial_data
root = Page.objects.create(
The wagtail version I use here is wagtail 2.15.2 and I haven't updated it since I started the project...
Due to the fact, that my wagtail-database has the name of the default django-database, could it be possible, that I accidentally tried a migration which was ment for the tool_db.sqlite3 without naming it in the migrate-command and caused this error by doing that?
So I would be very grateful if anyone knows, where the error comes from, or at least, what I could try out to fix it...
Kind regards and thank you!
It isn't clear to me if your database is currently broken or not. Hopefully not, but if it is, please take a back up of each before doing anything else.
This does sound like you might have been trying to operate in the wrong database. Do you have DATABASE_ROUTERS configured? I think that might help you prevent code from one app from getting introduced into the wrong database. The example in the Django docs is mostly focused on read replicas but should be adaptable to your situation: https://docs.djangoproject.com/en/4.1/topics/db/multi-db/#an-example
If your databases are in an incorrect state, start by looking at the django_migrations file in each and then carefully pruning the messed up one until you get back to the separation you have been enforcing.
So, in a bit more detail I have a model with a field like: permalink = models.IntegerField(default=0)
I've not actually been using this field - but would now like to.
However, it seems all models on this table, permalink is now 57295730 - on all 2000 models!
In an attempt to debug, I tried completly wiping the DB, running migrate (~100 migrations) - but then creating a instance of the model, I am told permalink violates the not-null constraint though I am definitely passing it a value! I also get a list of the values I am passing it, but am not sure how to know which value/column relates to which field?
I've even tried removing DB, removing migrations, running a new makemigrations - and still get the null violation...
even stranger, it looks like this field has not been touched since the initial migration!
migrations$ egrep permalink *
0001_initial.py: ('permalink', models.IntegerField(default=0)),
migrations$
I'm running (k)ubuntu 14.04, postgres 9.3, python 3.4, django 1.9.4
Though I'd love to know how to fix this - my question is really "What can I do to debug this kind of situation?"
Well Not the answer I want - but a working answer:
do automated testing
use CI! Prevent this problem in the first place
And if you are not doing the above...
use git bisect (or if you cant, manually use git reset --hard HEAD~1 to find the problem!)
in mycase, I was over-riding the save function of the model in a... stupid way!
edit:
in a little more detail, I was setting permalink to be 1 greater than the current biggest value - but in an earlier commit, had removed the + 1
However, I did not notice this error quickly, as it did not happen with data in the DB.
So! the error was actually quite informative - had I been running my tests more often (or using CI) I would have been informed of the error instantly, and saved myself quite a headache!
so, in short: **write tests, run them - automatically **
I just started developing on Django, and then I thought using the Syntastic syntax checker on it would be a good idea.
The problem is that it complains about some things being wrong when, in fact, they aren't.
Examples:
For
from django.core.urlresolvers import reverse
I get:
error| [F0401] Unable to import 'django.core.urlresolvers'
For
amount = self.sale_set.filter(date__year=year).aggregate(sum=Sum('amount'))["sum"]
I get (where self is an Album)
error| [E1101, Album.get_sales_total] Instance of 'Album' has no 'sale_set' member
This code runs perfectly even with these "errors", but how can I make Syntastic behave correctly?
piggybacking on #supervacuo's answer:
there is a way to get this working for syntastic and it's rather straightforward, if not easy to figure out for someone unfamiliar with syntastic options (like, say, me):
in your .vimrc, add this line:
let g:syntastic_python_pylint_args = "--load-plugins pylint_django"
of course, this does require pylint-django be installed in your environment
Both of these messages come from pylint — you can see fuller explanations with pylint --help-msg=$ID, or on http://pylint-messages.wikidot.com/.
You can disable the checks with e.g. from django.core.urlresolvers import reverse
# pylint: disable=F0401, but that gets tiresome pretty quickly.
There's a pylint plugin for Django which will definitely fix your E1101 (and I hope the F0401 too). Maybe have a go at installing the plugin and configuring Syntastic to use it?
EDIT I miscounted - it is printed out twice, not four times.
I put this in my settings.py
print 'ola!'
and on startup "ola" is printed out twice! This seems like something is wrong with my pycharm django project ... any ideas why this would happen? It isn't in a loop or anything (that i'm aware of, anyway)
cheers!
YAY The user known only as "rohit", as per the comments, has determined that a solution can be found here: https://stackoverflow.com/a/2110584/1061426 ~ see the comment about disabling reloading.
CAUTION I don't have my Django code up and about now, so I don't know what the noload will do. Good luck, soldiers.
If you print out the thread ID within settings.py, you will see that settings.py is actually being loaded on two different threads.
See this stackoverflow response and this article for more info.
Actually what Django does is putting a wrapper around settings. It is basically an object (settings object if you want so) which give you access to some direct setters like settings.WHATEVER, so it appears like you access the global variables in settings.py direclty.
I really don't remember though, why the import happens twice. I looked into it once when I worked on django-dynamic-settings which uses a very similar approach as Django itself.
Anyway, if you are interested in the "magic" you can follow the flow starting from the execute_from_command_line call in manage.py.
Django does some strange things with settings.py, and it will execute more than once. I'm used to seeing it imported twice, not sure why in PyCharm you're getting four times. You have to be careful with statements with side-effects in settings.py.
A closely-related question has been asked at least twice since. I can add that a Django core developer rejected the idea that this is any sort of Django bug; it's normal behavior.
Also see this from Graham Dumpleton.
Sometimes when I run manage.py I get a cryptic message in red that says Error: cannot import name <Name> and nothing else.
Obviously, this is a simple import or syntax error and with a little looking around, I can usually fix it. Other times however it takes me quite a while to figure out what exactly I did wrong. Is there a way to get Django to spit out more info in this situation?
This is an annoying problem. Luckily, it's been fixed (recently): see this ticket and this patch.
If you want to just hack your local django install (you're running under virtualenv or buildout, right?), change to the root of your django directory (the one with README, INSTALL, etc) and run this:
curl "https://code.djangoproject.com/changeset/17197?format=diff&new=17197" | patch -p3\
So, if you run django trunk > 17197, apply the patch to your django install (it applied to django 1.2 for me), or wait until django 1.4, you'll be able to do this:
./manage.py shell --traceback
And you'll get a full traceback instead of just the Error: cannot import ...
Voila!
this happens when a circular import appears, when one model is dependent on another and in turn they try and import each other while executing code.
You might want to paste the two models that are causing you issues.
That'll help us debug.
Also it tends to happen sometimes with signals so if you have a signals file please paste too.