On Thu, Jan 23, 2014 at 7:42 PM, Russell Keith-Magee < [email protected]> wrote:
> > > On Fri, Jan 24, 2014 at 9:33 AM, Ryan Hiebert <[email protected]>wrote: > >> >> >> >> On Thu, Jan 23, 2014 at 7:24 PM, Russell Keith-Magee < >> [email protected]> wrote: >> >>> >>> On Fri, Jan 24, 2014 at 9:05 AM, Brian Neal <[email protected]> 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. >>> >> >> 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? >> > > 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 %-) > 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. -- 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 [email protected]. To post to this group, send email to [email protected]. 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/CABpHFHQchVpgRa_-qQdGj6SMVO-P1XpzNNcsHj_qrNZdRkGKTg%40mail.gmail.com. For more options, visit https://groups.google.com/groups/opt_out.
