On 1.8 `--fake-initial` only works if you have a single initial migration
per app. We don't because we have additional migrations to load data and
create database triggers, etc.
In 1.9 this will be handled by the `initial = True` setting on the
Migration class.
Until then, we are using:
./ma
On 07/26/2015 10:46 AM, Tobias McNulty wrote:
> I just ran into this issue as well when updating an old project to
> Django 1.8. The only suitable workaround I found was to update first to
> Django 1.7 and fake the initial migrations for my apps (presumably
> Django's as well, though it seems to ha
I am not sure if there's a bug in Django or if it's user error that's
causing these problems. If I run syncdb on the Django 1.6 with the
tutorial, then upgrade directly to 1.8, all seems okay:
$ python manage.py migrate --fake-initial
Operations to perform:
Apply all migrations: contenttypes,
Good tip. First upgrading to Django 1.7 then running the migrations then
upgrading to 1.8 also fixed this for me :)
On Sunday, July 26, 2015 at 9:50:19 AM UTC-7, Tobias McNulty wrote:
>
> I just ran into this issue as well when updating an old project to Django
> 1.8. The only suitable workaroun
I just ran into this issue as well when updating an old project to Django
1.8. The only suitable workaround I found was to update first to Django 1.7
and fake the initial migrations for my apps (presumably Django's as well,
though it seems to handle that automatically). Only then can you safely
While poking around with this again, I noticed that the thing causing the
error for me was a datamigration (being applied due to it being run in
tests) which is (I believe) why I was seeing the issue when trying to run
tests but not otherwise. I was trying to grab a contenttype using
ContentTyp
I just fixed this issue by entering into my database directly, showed all
rows on "django_migrations", I saw that I did migrated before the
contenttypes (probably when I did a regression to django 1.4 for some
tests). By deleting the rows with contenttypes on it, deleting the
contenttypes table
Hey Devang,
No, we did not fake any migrations =(
On Tuesday, June 23, 2015 at 12:58:46 AM UTC+2, Devang Mundhra wrote:
>
> Chris-
> By any chance, did you fake any of the migrations. That was the problem I
> had faced- it wasn't a Django problem, it was a problem with my migration.
>
> On Mon,
Chris-
By any chance, did you fake any of the migrations. That was the problem I
had faced- it wasn't a Django problem, it was a problem with my migration.
On Mon, Jun 22, 2015 at 3:52 PM Chris DiLorenzo <
dilorenzo.christop...@gmail.com> wrote:
> I'm seeing this issue as well. Not sure if it hel
I'm seeing this issue as well. Not sure if it helps but I get it when
running my tests.
I chose to raise the error instead and saw this:
django.db.utils.IntegrityError: null value in column "name" violates not-
null constraint
DETAIL: Failing row contains (1, null, app, listing).
Where app is
In my case this is not a Django bug.
The problem was that since 1.8 contenttypes started to have migrations. But
since the table already existed earlier, the migrations needed to be faked.
When faking the migrations, I used python manage.py migrate contenttypes
--fake which faked both 0001 and 0002
If anyone running into this problem can figure out why the
contrib.contenttypes migration (0002_remove_content_type_name) is being
marked as applied but not actually run in the database, that will help
determine if this is a bug in Django or a problem elsewhere.
On Wednesday, June 10, 2015 at 7
I am getting the same error on Django v1.8.2 after migrating from v1.7.7
The underlying error is this-
django.db.utils.IntegrityError: null value in column "name" violates not-
> null constraint
> DETAIL: Failing row contains (39, null, app_name, model_name).
>
>
On Friday, April 17, 2015 at 1:25
Same problem nothing is working!!
On Wednesday, May 6, 2015 at 6:07:45 AM UTC-4, Max Usachev wrote:
>
> Try to migrate auth application first, and then others:
> manage.py migrate auth
> manage.py migrate
>
> среда, 29 апреля 2015 г., 14:12:33 UTC+3 пользователь Shubham Goyal
> написал:
>>
>> Fac
Try to migrate auth application first, and then others:
manage.py migrate auth
manage.py migrate
среда, 29 апреля 2015 г., 14:12:33 UTC+3 пользователь Shubham Goyal написал:
>
> Facing the same problem. Any leads..??
>
> On Saturday, April 18, 2015 at 2:38:56 AM UTC+5:30, Christophe Pettus
> wrot
Facing the same problem. Any leads..??
On Saturday, April 18, 2015 at 2:38:56 AM UTC+5:30, Christophe Pettus wrote:
>
> Well, django_content_type.name definitely in my database. :) This is a
> project that was migrated from 1.6.
>
> The underlying exception was a null value complaint about
> d
Well, django_content_type.name definitely in my database. :) This is a project
that was migrated from 1.6.
The underlying exception was a null value complaint about
django_content_type.name; it appears as though (on the production database) it
thought that the migration to remove had been appl
The contenttypes name column was removed in Django 1.8. Could you retrieve
the underlying exception before the RuntimeError is raised?
On Friday, April 17, 2015 at 2:55:07 PM UTC-4, Christophe Pettus wrote:
>
> Digging into this a bit more, the specific exception is that it is trying
> to insert
Digging into this a bit more, the specific exception is that it is trying to
insert a contenttypes row with a null 'name' value.
The code in question is doing a get_or_create() on the contenttype object. I
assume it should be picking up the name from the name @property on the
ContentType model
19 matches
Mail list logo
