Where does django store auth migrations?

[Dr Ed]

Hi all,

I feel a bit embarrassed even asking this question, because it must have an obvious answer... but when I do "./manage.py migrate -l" I see:

admin

 [X] 0001_initial

auth

 [X] 0001_initial

 [X] 0002_customer_payingcustomer_projectmanager_staff

 [X] 0003_auto_20141107_0803

contenttypes

 [X] 0001_initial

portal

 [X] 0001_initial

 [X] 0002_auto_20141008_2032

 [X] 0003_auto_20141008_2058

 [X] 0004_auto_20141008_2100

 [X] 0005_auto_20141008_2102

 [X] 0006_auto_20141008_2259

 [X] 0007_project_project_video_url

sessions

 [X] 0001_initial

Where do I find the auth migrations? I've used grep, find and Spotlight... I've searched the repository. I just can't find them! What am I missing?

As a bit of background - the reason I'm doing this is we want to migrate to custom user models (removing username and just using email). However when I do this, I get "TypeError: Staff cannot proxy the swapped model 'emailcustomuser.User'.

"

We don't actually need the proxy users, so I tried deleting them, but this didn't change anything (possibly because of these migrations I can't find). 

Cheers,

Ed

[Dr Ed]

Okay, I'm confused. I found it, in here:

/Users/XXXX/.virtualenvs/YYYY/lib/python2.7/site-packages/django/contrib/auth/migrations

Why are app related migrations being stored in this location?

Cheers,

Ed

[Daniel Roseman]

On Sunday, 9 November 2014 13:40:12 UTC, Dr Ed wrote:

Okay, I'm confused. I found it, in here:

/Users/XXXX/.virtualenvs/YYYY/lib/python2.7/site-packages/django/contrib/auth/migrations

Why are app related migrations being stored in this location?

Cheers,

Ed

What? Migrations related to Django's auth app are, not surprisingly, stored alongside the code to that app. Why does this puzzle you? 

--

DR.

[Cal Leeming [iops.io]]

Sounds like a bit of a weird edge case, I've had all sorts of problems previously when moving to custom user models from an app with existing migration data.

Personally I'd say get rid of the migration data for that specific model and re-initialize, it's just not worth trying to figure out why the magic is broken (imho).

Cal

--
You received this message because you are subscribed to the Google Groups "Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-users...@googlegroups.com.
To post to this group, send email to django...@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/ce688047-4e81-4ad8-bd71-115e9ca05ef9%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Dr Ed]

I guess it's because I thought that we could build migrations on the development machines and then update the project on the production machine and apply the migrations. Obviously this assumption was wrong and we need to distribute the entire .virtualenv too... 

Fine, if that's the way it is, that's the way it is, but to me this seems odd because everything else in there is just something you 'pip install' and I would not expect to mix 'user data' with 'installed packages' like this. It actually seems like an unfortunate design decision since it forces you - unless you try to be clever - to put django etc into the repository... we did this before and shifting to 1.7 was more painful as a result).

Anyway, thanks for the reply!

Cheers,

Ed

[Dr Ed]

Yep, agreed. This is what I've done.

Thanks for the reply!

Cheers,

Ed

[Markus Holtermann]

Hey Ed,

you certainly don't have to copy the virtualenv over to production!

Can you share some insights on your custom user model and your settings. A complete traceback, if you have any, helps too.

/Markus

[Dr Ed]

Hi Markus,

I don't really think it's the Custom model that's at fault here - this migration was created months ago. The point is that auth migrations are stored in, to my mind, the wrong place (in /Users/XXXX/.virtualenvs/YYYY/lib/python2.7/site-packages/django/contrib/auth/) and a separate problem revealed this to me. I've included a stack trace below though.

Cheers,

Ed

Running migrations:

  Applying auth.0002_customer_payingcustomer_projectmanager_staff...Traceback (most recent call last):

  File "./manage.py", line 10, in <module>

    execute_from_command_line(sys.argv)

  File "/Users/XXXX/.virtualenvs/gu_portal/lib/python2.7/site-packages/django/core/management/__init__.py", line 385, in execute_from_command_line

    utility.execute()

  File "/Users/XXXX/.virtualenvs/gu_portal/lib/python2.7/site-packages/django/core/management/__init__.py", line 377, in execute

    self.fetch_command(subcommand).run_from_argv(self.argv)

  File "/Users/XXXX/.virtualenvs/gu_portal/lib/python2.7/site-packages/django/core/management/base.py", line 288, in run_from_argv

    self.execute(*args, **options.__dict__)

  File "/Users/XXXX/.virtualenvs/gu_portal/lib/python2.7/site-packages/django/core/management/base.py", line 338, in execute

    output = self.handle(*args, **options)

  File "/Users/XXXX/.virtualenvs/gu_portal/lib/python2.7/site-packages/django/core/management/commands/migrate.py", line 160, in handle

    executor.migrate(targets, plan, fake=options.get("fake", False))

  File "/Users/XXXX/.virtualenvs/gu_portal/lib/python2.7/site-packages/django/db/migrations/executor.py", line 63, in migrate

    self.apply_migration(migration, fake=fake)

  File "/Users/XXXX/.virtualenvs/gu_portal/lib/python2.7/site-packages/django/db/migrations/executor.py", line 91, in apply_migration

    if self.detect_soft_applied(migration):

  File "/Users/XXXX/.virtualenvs/gu_portal/lib/python2.7/site-packages/django/db/migrations/executor.py", line 135, in detect_soft_applied

    apps = project_state.render()

  File "/Users/XXXX/.virtualenvs/gu_portal/lib/python2.7/site-packages/django/db/migrations/state.py", line 67, in render

    model.render(self.apps)

  File "/Users/XXXX/.virtualenvs/gu_portal/lib/python2.7/site-packages/django/db/migrations/state.py", line 311, in render

    body,

  File "/Users/XXXX/.virtualenvs/gu_portal/lib/python2.7/site-packages/django/db/models/base.py", line 155, in __new__

    raise TypeError("%s cannot proxy the swapped model '%s'." % (name, base_meta.swapped))

TypeError: PayingCustomer cannot proxy the swapped model 'emailcustomuser.User'.

[Carl Meyer]

Hi Ed,

On 11/10/2014 03:43 AM, Dr Ed wrote:
> I don't really think it's the Custom model that's at fault here - this
> migration was created months ago. The point is that auth migrations are
> stored in, to my mind, the wrong place
> (in /Users/XXXX/.virtualenvs/YYYY/lib/python2.7/site-packages/django/contrib/auth/)
> and a separate problem revealed this to me. I've included a stack trace
> below though.

The migrations for django.contrib.auth are part of Django, thus they are
properly located in Django. You should never create or modify migrations
for contrib auth, so it's not a problem that those migrations are in
Django. When using a custom AUTH_USER_MODEL, that custom user model
should be in one of your apps, not in contrib.auth, and the migrations
for it should also be in your own app, not in contrib.auth.

Changing the value of AUTH_USER_MODEL during the lifetime of a project
is not supported (see the warning at
https://docs.djangoproject.com/en/1.7/ref/settings/#auth-user-model). If
you're trying to do that, I'm not surprised if you're running into
difficulties. It's probably possible, but I don't know how it's done. If
you really need to, you might consider just backing up your project's
data, removing all migrations in your project and re-starting from a
totally fresh database, then re-loading the data from backup. I wouldn't
be surprised if that's the simplest option.

Carl

[Collin Anderson]

Hello,

Just checking, do you have AUTH_USER_MODULE = 'emailcustomuser.User'?

Did you mark emailcustomuser.User as "swappable" by chance? (I don't think you want to do that)

Thanks,

Collin