On Fri, Jan 24, 2014 at 12:07 PM, Ryan Hiebert <[email protected]> wrote: > > > 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. >
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 %-) -- 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/CAJxq8490zqqUgYQVUMNCpD%3Dqz_xBFmqPuffSHJtS%3DMZ0its7VA%40mail.gmail.com. For more options, visit https://groups.google.com/groups/opt_out.
