1.7 Schema migrations and AUTH_PROFILE_MODULE / get_profile() deprecation

[Brian Neal]

Hello,

The deprecation timeline says this about Django 1.7:

"The AUTH_PROFILE_MODULE setting, and the get_profile() method on the User model, will be removed."

The dev 1.7 release notes say that the new schema migration is scheduled to land in 1.7.

Does this mean we cannot use the new schema migration functionality to migrate away from AUTH_PROFILE_MODULE? Would it be better to deprecate the AUTH_PROFILE_MODULE in 1.8? That way the features could co-exist together for a brief time in order to facilitate migration.

Sorry if this has been discussed earlier.

Thank you,
BN

[Russell Keith-Magee]

On Fri, Jan 24, 2014 at 9:05 AM, Brian Neal <bgn...@gmail.com> wrote:

Hello,

The deprecation timeline says this about Django 1.7:

"The AUTH_PROFILE_MODULE setting, and the get_profile() method on the User model, will be removed."

The dev 1.7 release notes say that the new schema migration is scheduled to land in 1.7.

Does this mean we cannot use the new schema migration functionality to migrate away from AUTH_PROFILE_MODULE? Would it be better to deprecate the AUTH_PROFILE_MODULE in 1.8? That way the features could co-exist together for a brief time in order to facilitate migration.

Hi Brian,

There's a problem with your proposal - what profile are you suggesting that we migrate *to*? 

Migrations are only helpful if you've got a plan for how the data is changing. We've removed AUTH_PROFILE_MODULE because there's a number of ways that this data could be stored:

 * On a custom User model

 * On a related model linked with a FK

 * On a related model linked with a O2O relation

 * On a separate model indexed by user ID

There's no migration path for simply *removing* AUTH_PROFILE_MODULE either. The database table for User never had a formal representation of AUTH_PROFILE_MODULE - it was just a O2O relation that had a specialised caching implementation. When AUTH_PROFILE_MODULE disappears, you'll still be able to access profile modules - the name will just change.

So - there might be a role for migrations to play, but it's not something Django can specify as a project -- you'll have to handle it on a per-project basis.

Yours,

Russ Magee %-)

[Ryan Hiebert]

That's true,  but if profiles won't work in 1.7, then it seems that he wouldn't be able to use the native django migrations to aid the developer in migrating his existing profiles to something better, which is what I understood the problem to be.

Using south might be an option for migrating, but if we were to keep the profile around one release longer, perhaps that would ease the pain of migrating profiles to a better solution.

Or maybe it's not worth the hassle, or maybe there's a better way?

Ryan

[Russell Keith-Magee]

You appear to be missing my point. I would gladly ship a migration to aid the transition.

Now, what will that migration be?

Unless I'm mistaken, there's no authoritative answer to this question; Django's deprecation of AUTH_PROFILE_MODULE requires only that you:

 * Remove the AUTH_PROFILE_MODULE='foo.myprofile' definition in your settings file

 * Replace uses of user.get_profile() in your codebase with user.myprofile

Neither of these things require a migration - it's all code changes. And any other change (e.g., moving the contents of my profile onto User) requires a per-project understanding of the most appropriate solution, which isn't something Django is in a position to provide.

Yours,

Russ Magee %-)

 

[Ryan Hiebert]

Django clearly cannot know what migration to perform, so cannot ship any generic migration. It could, however, allow the migration system to exist while the profiles still work, so that a developer can use the built in Django migrations to create a migration away from it.

It's not about shipping the actual migrations, but allowing him to use the new native migration system to create migrations away from his profiles. That takes a per-project understanding, but having the built-in migration system may be helpful in his quest to find the right place to store the data that he's had in his profiles.

[Russell Keith-Magee]

I must be missing something -- why is this not possible with the current code in trunk?

As I said previously, AUTH_PROFILE_MODULE has no effect on database tables. It's a code-only mechanism used to implement an odd API-level caching strategy. 

If you're using AUTH_PROFILE_MODULE, you will have defined a profile module in some app, which will be providing a database table. If that database table needs to be migrated in some way, you can add migrations to that app. 

I'm afraid I either don't see the dependency on AUTH_PROFILE_MODULE that concerns you, or the problem that it's deprecation will cause. What migration are you trying to perform that requires the existence of a code-level API to support it?

Yours,

Russ Magee %-)

[Ryan Hiebert]

On Thu, Jan 23, 2014 at 10:30 PM, Russell Keith-Magee <rus...@keith-magee.com> wrote:

On Fri, Jan 24, 2014 at 9:05 AM, Brian Neal <bgn...@gmail.com> wrote:

Hello,

The deprecation timeline says this about Django 1.7:

"The AUTH_PROFILE_MODULE setting, and the get_profile() method on the User model, will be removed."

The dev 1.7 release notes say that the new schema migration is scheduled to land in 1.7.

I must be missing something -- why is this not possible with the current code in trunk?

I think its much more likely that I'm the one missing something. Thanks for going back and forth with me. 

I'm afraid I either don't see the dependency on AUTH_PROFILE_MODULE that concerns you, or the problem that it's deprecation will cause. What migration are you trying to perform that requires the existence of a code-level API to support it?

Assuming that the changes from the deprecation policy are in trunk now that the alpha has landed, any use of the AUTH_PROFILE_MODULE must be eliminated _before_ moving to 1.7, since they are not just deprecated, but _removed_ in 1.7. Migrating to 1.7 will _break_ code that uses it. This is normal and expected.

Since the new migration system lands in 1.7, and AUTH_PROFILE_MODULE is removed in 1.7, then it is clear that it won't be possible to use the new migration system to do the custom migrations that may be required to stop using the AUTH_PROFILE_MODULE.

Allowing one more release before AUTH_PROFILE_MODULE is removed would allow him to use the new migration system to create a custom migration to migrate away from using the profiles. Otherwise, he'd need to use South or go through two code change cycles.

I hope this clears up either why you're confused, or why I am. I'm very sorry if it's me, I hate to waste your time.

 

[Russell Keith-Magee]

Well, there's definitely some confusion here :-)

Going right back to basics, just in case: Migrations are only going to fix your database. It's for renaming columns and the like. The only reason you'd even need a migration to deal with AUTH_PROFILE_MODULE is if you're planning to move your profile data to a different table, or restructure the existing table. You don't need to reference AUTH_PROFILE_MODULE to do this sort of restructuring - you just make a change to the profile model.

As a completely separate activity, you'll need to update your code to not use AUTH_PROFILE_MODULE or get_profile(). For the most part, this will mean replacing the references to get_profile() with the equivalent native ORM calls (accessing the relevant attribute directly, instead of using the get_profile() proxy).

The only reason I can see that you'd need to reference AUTH_PROFILE_MODULE in a migration is if you're doing a data migration, and you want to access the old profile. But even then, you don't need to reference AUTH_PROFILE_MODULE or get_profile() - you just access the profile attribute directly, exactly as your migrated codebase will need to do.

Have you got a use case that I've missed here?

Yours,

Russ Magee %-)

[Josh Smeaton]

Sorry to jump in here, please ignore me if I make no sense.

Allowing one more release before AUTH_PROFILE_MODULE is removed would allow him to use the new migration system to create a custom migration to migrate away from using the profiles. Otherwise, he'd need to use South or go through two code change cycles.

That sounds like a *code migration* not a *database migration*. The migrations framework that has just landed focuses, specifically, on changes to model definitions.

So it can detect the changes between:

class MyModel(models.Model):

     field = models.IntegerField()

and 

class MyModel(models.Model):

    renamed_field = models.IntegerField()

But it can't detect code usage like:

user.get_profile() 

and

user.my_profile

Is that possibly where the confusion was?

[Carl Meyer]

Hi Ryan,

On 01/23/2014 09:50 PM, Ryan Hiebert wrote:
> Assuming that the changes from the deprecation policy are in trunk now
> that the alpha has landed, any use of the AUTH_PROFILE_MODULE must be
> eliminated _before_ moving to 1.7, since they are not just deprecated,
> but _removed_ in 1.7. Migrating to 1.7 will _break_ code that uses it.
> This is normal and expected.
>
> Since the new migration system lands in 1.7, and AUTH_PROFILE_MODULE is
> removed in 1.7, then it is clear that it won't be possible to use the
> new migration system to do the custom migrations that may be required to
> stop using the AUTH_PROFILE_MODULE.

I think this is the point of confusion. No migrations are required to
stop using AUTH_PROFILE_MODULE, since the AUTH_PROFILE_MODULE feature
does not affect the database in any way, it simply changes (very
slightly) the code you use to access the database.

If you have a Profile model in an "accounts" app, and you have
AUTH_PROFILE_MODULE set to "accounts.Profile", here are the sum total of
steps needed to stop using AUTH_PROFILE_MODULE:

1. Remove the AUTH_PROFILE_MODULE setting.

2. Replace occurrences of "user.get_profile()" in your code with
"user.profile".

Note the lack of any database migrations in those steps.

> Allowing one more release before AUTH_PROFILE_MODULE is removed would
> allow him to use the new migration system to create a custom migration
> to migrate away from using the profiles. Otherwise, he'd need to use
> South or go through two code change cycles.

You are correct that _if_ you should happen to _also_ want to move the
data you are storing in the Profile table to somewhere else, you won't
be able to do that using a Django 1.7 migration at the exact same time
as you remove the occurrences of "user.get_profile()" in your code. But
there's no particular reason the removal of AUTH_PROFILE_MODULE should
make you want to move data out of the Profile table, unless it just
happened to remind you that you'd been wanting to do that anyway.

So I think in a sense you and Russell are both right :-) But I don't
think there's a strong enough case here to justify extending the
lifetime of AUTH_PROFILE_MODULE. There's no harm in changing
"user.get_profile()" to "user.profile" right now, and then waiting until
1.7 to do your migration. Or if you really want to do them in a single
change to your codebase, you just do it now under Django 1.5 or 1.6
using South.

Carl

[Loic Bistuer]

If you look at the following example:

https://docs.djangoproject.com/en/1.4/topics/auth/#storing-additional-information-about-users

With `AUTH_PROFILE_MODULE = ’accounts.UserProfile’`: 'accounts' is a standard application that you add to your INSTALLED_APPS setting, and just like any other applications, it can benefit from migrations in Django 1.7.

The AUTH_PROFILE_MODULE *setting* was only used by `User.get_profile()` - see https://github.com/django/django/blob/stable/1.4.x/django/contrib/auth/models.py#L376-L404 - to know which model to query when you called `user.get_profile()`.

In Django 1.7 both the setting and the `User.get_profile()` method are gone, but that’s not something that migrations could help you with anyway, since it was an API at the Python level.

I hope that helps.

--
Loic

> --
> You received this message because you are subscribed to the Google Groups "Django developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to django-develop...@googlegroups.com.
> To post to this group, send email to django-d...@googlegroups.com.
> Visit this group at http://groups.google.com/group/django-developers.
> To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CABpHFHTc277wKDVSKM302EfeN5Fi76UmkU-aZ32EHNfJiELjaA%40mail.gmail.com.
> For more options, visit https://groups.google.com/groups/opt_out.

[Ryan Hiebert]

Thanks Carl. I suspected that the code migration is seen as a small enough issue not to warrant keeping get_profile() around, thanks for understanding and answering that specifically. I think that's what the OP was all about, and I wanted to make sure we all understood the tradeoff.

I personally use South, so this is not any issue for me, but I understand the use case being presented.

[Brian Neal]

Dear All:

After reading this discussion I see that my fears were misplaced. I can now see that schema migrations are not necessary to stop using the AUTH_PROFILE stuff thanks to the explanations from Russ and Carl. Had I done a bit more investigating I probably would have realized this. Sorry for the noise.

If Django wants help to add a note to the docs about this perhaps I can help with that. I suspect a few people might be scared about this change (I was).

Best,
BN