Mercurial > public > pelican-blog
changeset 16:4280c90d5030
New Django related post about migrating away from get_profile().
author | Brian Neal <bgneal@gmail.com> |
---|---|
date | Sat, 24 May 2014 15:33:04 -0500 |
parents | 4ed3f207aa65 |
children | fa54eda9b809 |
files | content/Coding/030-retiring-get-profile-and-auth-profile-module.rst |
diffstat | 1 files changed, 153 insertions(+), 0 deletions(-) [+] |
line wrap: on
line diff
--- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/content/Coding/030-retiring-get-profile-and-auth-profile-module.rst Sat May 24 15:33:04 2014 -0500 @@ -0,0 +1,153 @@ +Retiring get_profile and AUTH_PROFILE_MODULE +############################################ + +:date: 2014-05-24 14:08 +:tags: django +:slug: retiring-get-profile-and-auth-profile-module +:author: Brian Neal +:summary: Here is how I prepared for the upcoming deprecation in Django 1.7 of + the get_profile() and AUTH_PROFILE_MODULE functionality. + +Django 1.7 is coming soon! This looks like an exciting release with cool +features like migrations and an app loading framework. However it also comes +with many deprecations_ that we need to prepare for. In particular, now is the +time to finally move away from the AUTH_PROFILE_MODULE_ setting and the +`get_profile()`_ method on the ``User`` model. I had been putting this off +until the last minute, but after finally sitting down and doing it, I am happy +to report it isn't difficult. + +My initial fears about removing this feature were unfounded. Originally +I thought perhaps database schema changes were needed. And without migrations +support I would be doomed. I was also confusing this deprecation with the +introduction of the new `configurable user model`_ from Django 1.5. + +It turns out that no database changes are needed to migrate away from +``get_profile()``. You simply replace your profile model's ForeignKey_ with +a OneToOneField_. This does not change the database schema at all. You can +observe this yourself by running the ``manage.py sql`` command before and after +making the change. You then need to fix up your code by removing all +``get_profile()`` calls. + +Django 1.5 introduced the ability to define your own user model, but you do not +need to jump to this to move away from ``get_profile()``. That is a separate +decision to make. You may in fact wish to abandon a separate user profile model +and create your own combined user model. But this can be done after following +the steps I outline below. + +In my case, I decided it makes more sense to maintain a separate user profile +model. It did not feel right to add non-authentication related fields into the +user model. It is true that you will incur the overhead of database joins with +a separate profile model. However, in practice, at least for me, this was not +particularly burdensome. Most of the time this meant adding an additional +`select_related()`_ call on an ORM query. Your mileage may vary of course. But +if you are happy with the additional profile model solution you need only +follow these steps and be done. + +Here is an outline of the steps I followed to remove the ``get_profile()`` +functionality from my code base. + +Remove the AUTH_PROFILE_MODULE setting +-------------------------------------- + +This step is easy. Find your ``AUTH_PROFILE_MODULE`` setting and delete it. + +.. sourcecode:: python + + # In your settings.py: + AUTH_PROFILE_MODULE = 'myapp.profile' # delete this line + + +Change your profile model +------------------------- + +In this step we change the ``ForeignKey`` to Django's ``User`` model to +a ``OneToOneField``. Again, this does not affect the database schema. + +Before: + +.. sourcecode:: python + + from django.db import models + from django.contrib.auth.models import User + + class Profile(models.Model): + """model to represent additional information about users""" + user = models.ForeignKey(User, unique=True) # change this line + # ... other custom stuff here + +After: + +.. sourcecode:: python + + from django.db import models + from django.contrib.auth.models import User + + class Profile(models.Model): + """model to represent additional information about users""" + user = models.OneToOneField(User) + # ... other custom stuff here + +Update the code +--------------- + +You now need to go through your code and find all the ``get_profile()`` calls +and replace them. For example: + +Before: + +.. sourcecode:: python + + profile = request.user.get_profile() + +After: + +.. sourcecode:: python + + profile = request.user.profile + +After making all these changes you are basically done! Congratulations! + +Cleanup and sanity checking +--------------------------- + +There are a few other things I recommend doing at this point. First I would +search your code for all occurrences of your ``Profile`` model. There were +several places in my code where the extra database calls caused by +``get_profile`` were hurting my performance. I had replaced ``get_profile()`` +with custom code that queried the ``Profile`` manager directly to reduce +database calls. I reviewed these changes and replaced them with +``select_related()`` calls. This simplified things. I love deleting lines of +code. While I was doing this, I noticed a few places that I could use +`prefetch_related()`_ (on other related fields) since my code pre-dated this +method. + +Next you should run any unit tests and verify they still pass. Hopefully you +have unit tests, right? It was a big relief to have my tests passing after +making these numerous changes. + +Finally I would suggest using a profiler like the `Django Debug Toolbar`_ to do +some spot checking on the number of SQL queries your pages generate after making +these changes. In most cases I was able to reduce the number of calls or at +least keep them the same. Using the magic of version control, I ran a version +of my site both with and without my changes side-by-side. Using the profiler +I convinced myself I was in fact making things better and not worse. + +Conclusion +---------- + +I am not familiar with early Django history, but I'm guessing that +``get_profile()`` must have pre-dated the OneToOneField_. After making the +switch, my code seems more straightforward with less "magic". In any event, +I hope this post will make you less fearful about this change. It was not the +major change I had thought it was going to be. + + +.. _deprecations: https://docs.djangoproject.com/en/1.6/releases/1.5/#auth-profile-module +.. _AUTH_PROFILE_MODULE: https://docs.djangoproject.com/en/1.6/ref/settings/#auth-profile-module +.. _get_profile(): https://docs.djangoproject.com/en/1.6/ref/contrib/auth/#django.contrib.auth.models.User.get_profile +.. _configurable user model: https://docs.djangoproject.com/en/1.6/releases/1.5/#configurable-user-model +.. _ForeignKey: https://docs.djangoproject.com/en/1.6/ref/models/fields/#foreignkey +.. _OneToOneField: https://docs.djangoproject.com/en/1.6/ref/models/fields/#onetoonefield +.. _select_related(): https://docs.djangoproject.com/en/1.6/ref/models/querysets/#select-related +.. _prefetch_related(): https://docs.djangoproject.com/en/1.6/ref/models/querysets/#prefetch-related +.. _Django Debug Toolbar: https://github.com/django-debug-toolbar/django-debug-toolbar