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 %-) -- 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/CAJxq84_40cVmrPpSD8LVFX1q6FrjgFub7pJ1JSnZkM66AFhPCA%40mail.gmail.com. For more options, visit https://groups.google.com/groups/opt_out.
