https://www.johnpaulett.com/posts/2011/Recent content in 2011 on John PaulettHugoen-usFri, 18 Mar 2011 04:12:22 +0000https://www.johnpaulett.com/2011/django-13-south/Fri, 18 Mar 2011 04:12:22 +0000https://www.johnpaulett.com/2011/django-13-south/<p>Running the latest <a href="http://www.djangoproject.com/weblog/2011/mar/03/13-rc/">Django Release Candidate</a>, I noticed that all of my <a href="http://south.aeracode.org/">South</a> data migrations were failing.</p> <p>Debugging via <code>pdb</code> led me to a a recent change in which the database was being flushed after south ran, but before the tests ran. I found a changeset that was committed after Django 1.3 beta-1, <a href="http://code.djangoproject.com/ticket/14661">#14661</a> that introduced the flush to correct an issue with MySQL. It is a documented as a <a href="http://docs.djangoproject.com/en/dev/releases/1.3/#use-of-custom-sql-to-load-initial-data-in-tests">backwards incompatible change</a>, which will prevent SQL fixtures (and unfortunately South data migrations).</p>https://www.johnpaulett.com/2011/django-durationfield-v033/Fri, 18 Mar 2011 03:58:45 +0000https://www.johnpaulett.com/2011/django-durationfield-v033/<p>I just released an implementation of <a href="http://django-durationfield.readthedocs.org/">DurationField for Django</a> to PyPi.</p> <p>The latest release uses <code>datetime.timedelta</code> for its internal representation of durations (thanks to <a href="https://github.com/poswald">Paul Oswald</a>)) and has support for <a href="http://south.aeracode.org/">South</a> thanks to <a href="https://github.com/winhamwr">Wes Winham</a>.</p> <p>The documentation is now hosted on <a href="http://django-durationfield.readthedocs.org/">ReadTheDocs</a> and the package data is available on <a href="http://djangopackages.com/packages/p/django-durationfield">Django Packages</a>.</p> <p>After a discussion with a few Django core developers, it seems like keeping the DurationField implementation as a separate, reusable application is the preferred option. By staying independent, we keep the ability to make changes independent of the Django release cycle. Additionally, we avoid adding bloat to Django-core. Since not all databases implement an interval or duration data type (PostgreSQL does), django-durationfield is in some ways a hack by using a <code>bigint</code> datatype to store integer instances of <code>timedelta</code>.</p>