Django 1.7 migrations: Adding one field to User`s model

[marcin....@gmail.com]

Hi,

I would like to add one field to User.

I've created new model based on original Django`s user:

 class User(AbstractUser):

    is_verified = models.BooleanField(default=False)

    class Meta:

        db_table = 'auth_user'

Now I'm trying to make migrations, but Django tries to create `auth_user` table from scratch, and this is not what I'm expecting.

I've tried to migrate schema by adding one field:

[...] 

     operations = [

        migrations.AddField('User', 'is_verified', models.BooleanField(default=False)),

    ]

But during migrations Django dies at:

[...]

  File "eggs/Django-1.7.8-py2.7.egg/django/db/migrations/migration.py", line 76, in mutate_state

    operation.state_forwards(self.app_label, new_state)

  File "eggs/Django-1.7.8-py2.7.egg/django/db/migrations/operations/fields.py", line 26, in state_forwards

    state.models[app_label, self.model_name.lower()].fields.append((self.name, field))

KeyError: ('myapp', u'user')

I need to add just one column using builtin migrations. 

How to do that?

This is bug or feature?

BR,

Marcin

[Tim Graham]

This might be related to the difficulties of migrating an existing project to a custom user model. I'm not sure the steps to workaround the problem. We have an open ticket to recommend starting off a project with a custom user model to avoid this problem [1]. Sorry I can't be of more help.

[1] https://code.djangoproject.com/ticket/24370

[Hugo Osvaldo Barrera]

Here's how I'd get around this (I've recently worked on a project with an existing db where we needed to track new changes via migrations, and this is what we did).

 

I'm assuming your project has no existing migrations. If it does, it should not include migrations for this specific model. If it does, you've another problem.

 

1. Create an initial migrations with the model that matches the existing database.

2. Add any new fields, etc.

3. Create new migrations that apply changes.

4. Run python manage.py migrate --fake-initial. This will skip the *first* migrations for tables that exist, and proceed with other ones. Since the first migration would have created a table that looks like your existing one, that's not an issue. The following migrations will add a field

 

Lemme know if this helps.

 

--

Hugo Osvaldo Barrera

 

[marcin....@gmail.com]

Thanks, Hugo.

My project already contains migrations. 

I've added migration with RunSQL. Monkey patch is detected for "django.contrib.auth" app, and Django tries to add migration in python egg (Django). 

I'm avoiding calling "makemigrations" without args (or "auth" as an argument). 

This is a Django migrations design problem... :(

 

BR,

Marcin

[Hugo Osvaldo Barrera]

Oh, so the field you're adding in monkey patching contrib.auth.User?

IMHO, the design problem isn't django, but rather monkey-patching models itself. Maybe you'd be better of using a custom user model.

 

--

Hugo Osvaldo Barrera

 

[Marcin Nowak]

On 26 August 2015 at 20:09, Hugo Osvaldo Barrera <hu...@barrera.io> wrote:

Oh, so the field you're adding in monkey patching contrib.auth.User?

IMHO, the design problem isn't django, but rather monkey-patching models itself. Maybe you'd be better of using a custom user model.

I've tried to use custom user model, but Django forces me to change all FK`s. This is not possible for now.

I need to add just one column / field to existing User model. Nothing more, nothing less.

AFAIK I should create profile for user and put this column into profile model, but there are two disadvantages: 

• the profile is not necessary now and will contain just one column (well, three when incl. PK and FK to user)
• performance issues (joining table)

I think that for this use case "Custom user" will not work. I was wrong. I must forget about "Custom user". ;)

BR,

Marcin

[Carl Meyer]

On 08/26/2015 12:18 PM, Marcin Nowak wrote:
>
> On 26 August 2015 at 20:09, Hugo Osvaldo Barrera <hu...@barrera.io

> <mailto:hu...@barrera.io>> wrote:
>
> Oh, so the field you're adding in monkey patching contrib.auth.User?
> IMHO, the design problem isn't django, but rather monkey-patching
> models itself. Maybe you'd be better of using a custom user model.
>
>
> I've tried to use custom user model, but Django forces me to change all
> FK`s. This is not possible for now.
>
> I need to add just one column / field to existing User model. Nothing
> more, nothing less.
>
> AFAIK I should create profile for user and put this column into profile
> model, but there are two disadvantages:
>

> * the profile is not necessary now and will contain just one column

> (well, three when incl. PK and FK to user)

> * performance issues (joining table)

>
> I think that for this use case "Custom user" will not work. I was wrong.
> I must forget about "Custom user". ;)

Yes. I think the most important Django limitation here is how difficult
it is to switch from built-in User to custom User. That's a real
problem, and it should be fixed (but at the moment I'm not sure how to
fix it).

Better support for monkeypatching is not very interesting.

Carl

[marcin....@gmail.com]

On Wednesday, August 26, 2015 at 8:23:01 PM UTC+2, Carl Meyer wrote:

> I think that for this use case "Custom user" will not work. I was wrong.
> I must forget about "Custom user". ;)

Yes. I think the most important Django limitation here is how difficult
it is to switch from built-in User to custom User. That's a real
problem, and it should be fixed (but at the moment I'm not sure how to
fix it).

Maybe this is related to migrations. I must check someday source code of "custom user" implementation, then maybe I could give you some thoughts...

Better support for monkeypatching is not very interesting.

Right, Carl. And this wasn't my intention. You give me a hint in other thread and it was helpful, but MP has some side effects (with migrations, again).

PS. I don't like monkey patching, personally.

Cheers,

Marcin