<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Migration on Caktus Group</title><link>https://www.caktusgroup.com/tags/migration/</link><description>Recent content in Migration on Caktus Group</description><generator>Hugo</generator><language>en</language><lastBuildDate>Tue, 25 May 2021 17:34:09 +0000</lastBuildDate><atom:link href="https://www.caktusgroup.com/tags/migration/index.xml" rel="self" type="application/rss+xml"/><item><title>How to Simplify Django Migrations and Deployment</title><link>https://www.caktusgroup.com/blog/2021/05/25/django-migrations-and-deployment/</link><pubDate>Tue, 25 May 2021 17:34:09 +0000</pubDate><guid>https://www.caktusgroup.com/blog/2021/05/25/django-migrations-and-deployment/</guid><description>&lt;p>&lt;strong>When removing fields from Django models, or adding non-nullable
fields, it can be hard to avoid a mismatch between code running on some
servers and the database in use.&lt;/strong>&lt;/p></description></item><item><title>How to Switch to a Custom Django User Model Mid-Project</title><link>https://www.caktusgroup.com/blog/2019/04/26/how-switch-custom-django-user-model-mid-project/</link><pubDate>Fri, 26 Apr 2019 16:32:33 +0000</pubDate><guid>https://www.caktusgroup.com/blog/2019/04/26/how-switch-custom-django-user-model-mid-project/</guid><description>&lt;p>The Django documentation recommends always &lt;a href="https://docs.djangoproject.com/en/2.2/topics/auth/customizing/#using-a-custom-user-model-when-starting-a-project" target="_blank" rel="noopener noreferrer">starting your project with a
custom user
model&lt;/a>
(even if it's identical to Django's to begin with), to make it easier
to customize later if you need to. But what are you supposed to do if
you didn't see this when starting a project, or if you inherited a
project without a custom user model and you need to add one?&lt;/p></description></item><item><title>Writing Unit Tests for Django Migrations</title><link>https://www.caktusgroup.com/blog/2016/02/02/writing-unit-tests-django-migrations/</link><pubDate>Tue, 02 Feb 2016 13:00:00 +0000</pubDate><guid>https://www.caktusgroup.com/blog/2016/02/02/writing-unit-tests-django-migrations/</guid><description>&lt;p>&lt;em>Editor's note: This post was originally published in February 2016 and
was updated in August 2017 to incorporate improvements suggested by our
readers. It has also been tested for compatibility as of the Django 1.11
release.&lt;/em>&lt;/p></description></item><item><title>Initial Data in Django</title><link>https://www.caktusgroup.com/blog/2015/11/10/initial-data-django/</link><pubDate>Tue, 10 Nov 2015 13:00:00 +0000</pubDate><guid>https://www.caktusgroup.com/blog/2015/11/10/initial-data-django/</guid><description>&lt;p>I&amp;rsquo;ve struggled to find an ideal way to load initial data for Django projects. By “initial data,” I&amp;rsquo;m referring to the kind of data that you need on a new system for it to be functional, but could change later. These are largely lists of possible choices, such as time zones, countries, or crayon colors.&lt;/p></description></item><item><title>Contributing Back to Symposion</title><link>https://www.caktusgroup.com/blog/2014/07/21/contributing-back-to-Symposion/</link><pubDate>Mon, 21 Jul 2014 12:00:00 +0000</pubDate><guid>https://www.caktusgroup.com/blog/2014/07/21/contributing-back-to-Symposion/</guid><description>&lt;p>Recently Caktus collaborated with the organizers of PyOhio, a free regional Python conference, to launch the &lt;a href="http://pyohio.org" target="_blank" rel="noopener noreferrer">PyOhio 2014 conference website&lt;/a>. The conference starts this weekend, July 26 - 27. As in prior years, the conference web site utilizes Eldarion’s &lt;a href="http://eldarion.com/symposion/" target="_blank" rel="noopener noreferrer">Symposion&lt;/a>, an opensource conference management system. Symposion powers a number of annual conference sites including &lt;a href="http://www.pycon.org" target="_blank" rel="noopener noreferrer">PyCon&lt;/a> and &lt;a href="http://djangocon.us" target="_blank" rel="noopener noreferrer">DjangoCon&lt;/a>. In fact, as of this writing, there are &lt;a href="https://github.com/pinax/symposion/network" target="_blank" rel="noopener noreferrer">78 forks of Symposion&lt;/a>, a nod to its widespread use for events both large and small. This collaboration afforded us the opportunity to abide by one our core tenets, that of giving back to the community.&lt;/p></description></item><item><title>Migrating to a Custom User Model in Django</title><link>https://www.caktusgroup.com/blog/2013/08/07/migrating-custom-user-model-django/</link><pubDate>Wed, 07 Aug 2013 13:10:00 +0000</pubDate><guid>https://www.caktusgroup.com/blog/2013/08/07/migrating-custom-user-model-django/</guid><description>&lt;p>&lt;strong>UPDATE: Read a&lt;/strong> &lt;a href="https://www.caktusgroup.com/blog/2019/04/26/how-switch-custom-django-user-model-mid-project/">&lt;strong>newer blog post on this
topic&lt;/strong>&lt;/a>.&lt;/p>
&lt;p>The new &lt;a href="https://docs.djangoproject.com/en/1.5/topics/auth/customizing/" target="_blank" rel="noopener noreferrer">custom user model
configuration&lt;/a>
that arrived in Django makes it relatively straightforward to swap in
your own model for the Django user model. In most cases, Django's
built-in &lt;code>User&lt;/code> model works just fine, but there are times when certain
limitations (such as the &lt;a href="https://docs.djangoproject.com/en/1.5/ref/models/fields/#emailfield" target="_blank" rel="noopener noreferrer">length of the email
field&lt;/a>)
require a custom user model to be installed. If you're starting out
with a custom user model, setup and configuration are relatively
straightforward, but if you need to migrate an existing legacy project
(e.g., one that started out in Django 1.4 or earlier), there are a few
gotchas that you might run into. We did this recently for one of our
larger, long-term client projects at Caktus, and here's an outline of
how we'd recommend tackling this issue:&lt;/p></description></item><item><title>Migrating from django-photologue 1.x to 2.x</title><link>https://www.caktusgroup.com/blog/2009/03/27/migrating-from-django-photologue-1x-to-2x/</link><pubDate>Fri, 27 Mar 2009 17:52:30 +0000</pubDate><guid>https://www.caktusgroup.com/blog/2009/03/27/migrating-from-django-photologue-1x-to-2x/</guid><description>&lt;p>We're in the process of updating a web app for a client that was built
last year about this time using &lt;a href="http://www.djangoproject.com" target="_blank" rel="noopener noreferrer">Django&lt;/a>
and &lt;a href="http://code.google.com/p/django-photologue/" target="_blank" rel="noopener noreferrer">Photologue&lt;/a>. Needless
to say, there have been a lot of changes to both over the past year!&lt;/p></description></item></channel></rss>