This is a pre-production deployment of Warehouse. Changes made here affect the production instance of PyPI (pypi.python.org).
Help us improve Python packaging - Donate today!
Project Description

Motivation

South isn’t great at handling differing requirements from multiple databases in a django application.

South assumes that there will at least be a south_migration_history table available at the point of running migrate against a given database.

This is fine when your django app is only dealing with one default database, but becomes much less pleasant when wanting to add extra database sources that perhaps south shouldn’t have jurisdiction over.

Let’s say your django.conf settings look something like:

DATABASES = {
    'default': {
        ...
        'NAME': 'my_own_db',
        ...
    },

    'super_secure': {
        ...
        'NAME': 'super_secure',
        ...
    }
}

You wouldn’t want syncdb to create tables in the super_secure DB, and that would be achieved by creating a database router, along with an allow_syncdb method and include that in a DATABASE_ROUTER setting. Done.

You also wouldn’t want migrate to do anything in super_secure. As it stands, south fails at this because the first thing it does is see if there are any migrations in the database by looking at the south_migration_history table. Because syncdb didn’t create this you get FAILURE.

Solution

South jurisdiction introduces a new setting to the django settings module:

SOUTH_MANAGED_DBS = []

This is intended to be populated with the keys of the databases that you want south to manage. In the above example it would read:

SOUTH_MANAGED_DBS = ['default']

Any attempt to migrate on a database not included in SOUTH_MANAGED_DBS is rejected gracefully.

If this setting is not included in your django settings module then all databases will be looked at for migration as normal.

Configuration

  • Add "south_jurisdiction" to INSTALLED_APPS in your settings, after the "south" app.
  • Use the new SOUTH_MANAGED_DBS setting available to you.
  • If you don’t want to run the south_jurisdiction tests, use the SKIP_SOUTH_TESTS setting in the same way as you do for south.
Release History

Release History

0.1.2

This version

History Node

TODO: Figure out how to actually get changelog content.

Changelog content for this version goes here.

Donec et mollis dolor. Praesent et diam eget libero egestas mattis sit amet vitae augue. Nam tincidunt congue enim, ut porta lorem lacinia consectetur. Donec ut libero sed arcu vehicula ultricies a non tortor. Lorem ipsum dolor sit amet, consectetur adipiscing elit.

Show More

0.1.1

History Node

TODO: Figure out how to actually get changelog content.

Changelog content for this version goes here.

Donec et mollis dolor. Praesent et diam eget libero egestas mattis sit amet vitae augue. Nam tincidunt congue enim, ut porta lorem lacinia consectetur. Donec ut libero sed arcu vehicula ultricies a non tortor. Lorem ipsum dolor sit amet, consectetur adipiscing elit.

Show More

0.1

History Node

TODO: Figure out how to actually get changelog content.

Changelog content for this version goes here.

Donec et mollis dolor. Praesent et diam eget libero egestas mattis sit amet vitae augue. Nam tincidunt congue enim, ut porta lorem lacinia consectetur. Donec ut libero sed arcu vehicula ultricies a non tortor. Lorem ipsum dolor sit amet, consectetur adipiscing elit.

Show More

Download Files

Download Files

Download the file for your platform. If you're not sure which to choose, learn more about installing packages.

File Name & Checksum SHA256 Checksum Help Version File Type Upload Date
south_jurisdiction-0.1.2.tar.gz (2.9 kB) Copy SHA256 Checksum SHA256 Source Feb 2, 2013

Supported By

WebFaction WebFaction Technical Writing Elastic Elastic Search Pingdom Pingdom Monitoring Dyn Dyn DNS Sentry Sentry Error Logging CloudAMQP CloudAMQP RabbitMQ Heroku Heroku PaaS Kabu Creative Kabu Creative UX & Design Fastly Fastly CDN DigiCert DigiCert EV Certificate Rackspace Rackspace Cloud Servers DreamHost DreamHost Log Hosting