On Fri, Jan 24, 2014 at 12:50 PM, Ryan Hiebert <[email protected]> wrote:
> On Thu, Jan 23, 2014 at 10:30 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. >>>>>>> >>>>>> >> 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. > 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 %-) -- 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/CAJxq848pZov6R8XnrqortqpL8dBV66imxNVZKgK7r7fjDQN7GQ%40mail.gmail.com. For more options, visit https://groups.google.com/groups/opt_out.
