1. Yosuke Ikeda
  2. ae35.bitbucket.org

Commits

ae35  committed c2635fb

delete all

  • Participants
  • Parent commits 5beb1ab
  • Branches default

Comments (0)

Files changed (68)

File south-doc-ja/_sources/about.txt

-.. _about:
-
-South について
-==============
-
-.. About South
-   ===========
-
-.. South brings migrations to Django applications. Its main objectives are to
-   provide a simple, stable and database-independent migration layer to prevent
-   all the hassle schema changes over time bring to your Django applications.
-
-South は Django アプリケーションにマイグレーション機能を追加します。
-Django アプリケーションへの、あのいつもの煩わしいスキーマの変更の手間を抑えるために、
-シンプルで安定した、特定のデータベースに依存しないマイグレーション層の提供を主な目的としています。
-
-.. We try to make South both as easy-to-use and intuitive as possible, by making it
-   automate most of your schema-changing tasks, while at the same time providing a
-   powerful set of tools for large or complex projects; you can easily write your
-   own migrations by hand, or even use the database altering API directly.
-
-スキーマ変更タスクのほとんどを自動化させることによって、South はできる限り扱いやすくて直感的なものになっています。
-また同時に、巨大で複雑なプロジェクトのためのパワフルなツール集も提供しています; 
-自分でマイグレーションを簡単に書くこともできますし、データベース変更 API を直接使用することもできます。
-
-.. While South started as a relative unknown in the Django database-schema-altering
-   world, it has slowly risen in popularity and is now widely regarded as the most
-   popular schema migration tool for Django.
-
-South は Django のデータベーススキーマ変更ツール界隈では、ほとんど無名の状態でスタートしましたが、
-徐々に評判が広まり、今や最も人気のある Django のマイグレーションツールとして、広く認知されています。
-
-
-主な機能
---------
-
-.. Key features
-   ------------
-
-.. South has a few key features:
-
-..  - Automatic migration creation: South can see what's changed in your models.py
-      file and automatically write migrations that match your changes.
-..  - Database independence: As far as possible, South is completely
-      database-agnostic, supporting five different database backends.
-..  - App-savvy: South knows and works with the concept of Django apps, allowing
-      you to use migrations for some of your apps and leave the rest to carry on
-      using syncdb.
-..  - VCS-proof: South will notice if someone else commits migrations to the same
-      app as you and they conflict.
-
-South の主な機能は:
-
- - 自動マイグレーション作成: South は models.py ファイルがどのように変更されたかを監視して、
-   その変更に沿ったマイグレーションを自動的に作成します。
- - 特定のデータベースへの依存性排除: South は特定のデータベースへの依存を可能な限り排除(database-agnostic)し、
-   5つの異なるデータベースバックエンドに対応しています。
- - アプリケーションに精通: South は Django アプリケーションの概念を理解しており、それに沿って動作します。
-   このため、いくつかのアプリにだけマイグレーションを使い、残りのアプリは今まで通り syncdb を使う、ということも可能です。
- - バージョン管理システム対応: 同じアプリケーションのマイグレーションを、誰かがコミットしてコンフリクトが発生した場合でも、
-   South はきちんとそれを検知することができます。
-
-
-略歴
-----
-
-.. A brief history
-   ---------------
-
-.. South was originally developed at `Torchbox <http://www.torchbox.com>`_ in 2008,
-   when no existing solution provided the workflow and features that were needed.
-   It was open-sourced shortly thereafter, and quickly gained steam after the
-   Schema Evolution panel at DjangoCon 2008.
-
-South はそれまで必要とされていたワークフローや機能に対する解決策が全くなかった2008年に、
-`Torchbox <http://www.torchbox.com>`_ において開発されたのち、まもなくオープンソース化され、
-DjangoCon 2008 における Schema Evolution パネルトークの後に急速に勢いを増していきました。
-
-.. Sometime in 2009, it became the most popular of the various migration
-   alternatives, and seems to have been going strong ever since. While there have
-   been growing calls to integrate South, or something like it, into Django itself,
-   such an integration has not yet been made, mostly due to the relative
-   immaturity of database migration solutions.
-
-2009年ごろには South は Django のマイグレーションツールの中で最も人気のあるものとなり、その人気は現在でも衰えずに高まっています。
-South や似たような機能を持つツールを Django に統合してほしい、という要望が高まってきていますが、
-主にデータベースのマイグレーションソリューションが比較的未成熟なために、そのような統合は未だに行なわれていない状況です。

File south-doc-ja/_sources/autodetector.txt

-
-.. _autodetector:
-
-The Autodetector
-================
-
-The autodetector is the part of South you'll probably be using the most, as well
-as being the feature that people seem to like the most.
-
-The general use of the autodetector is covered in :ref:`tutorial-part-1`; this
-is more of a reference of what it's capable of.
-
-When the autodetector runs, it compares your current models with those frozen
-in your most recent migration on the app, and if it finds any changes, yields
-one or more Actions to the South migration-file-writer.
-
-.. _autodetector-supported-actions:
-
-Supported Actions
------------------
-
-Model creation and deletion
-^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-South will happily detect the creation and deletion of models; this is the
-oldest and most well-worn feature of the autodetector, and so has very few
-caveats.
-
-One thing to note is that, while South calls the post_syncdb hook on your
-models (much like ``syncdb`` does), it calls it when it initially creates the
-table, not at the end of the migration, so your hook might well get called
-when the model doesn't have its full table.
-
-Consider moving your hook code into its own data migration, or use one of
-our own :ref:`signals`.
-
-
-Field addition and removal
-^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-South detects addition and removal of fields fine, and should correctly create
-indexes and constraints for new fields.
-
-Note that when you add or remove a field, you need a default specified; there's
-more explanation on this in the :ref:`tutorial-part-2-defaults` part of the
-tutorial.
-
-
-Field changes
-^^^^^^^^^^^^^
-
-South will detect if you change a field, and should correctly change the field
-type, with one exception:
-
- - If you alter to a field with a CHECK constraint (e.g. ``PositiveIntegerField``)
-   the constraint won't be added to the column (it is removed if you alter away,
-   however). This will be fixed in a future release.
-
-
-ManyToMany addition and removal
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-ManyToMany fields are detected on addition and removal; when you add the field,
-South will create the table the ManyToMany represents, and when you remove the
-field, the table will be deleted.
-
-The one exception to this is when you have a 'through model' (i.e. you're using
-the ``through=`` option) - since the table for the model is already created when
-the model is detected, South does nothing with these types of ManyToMany fields.
-
-
-Unique changes
-^^^^^^^^^^^^^^
-
-If you change the ``unique=`` attribute on a field, or the ``unique_together``
-in a model's Meta, South will detect and change the constraints on the database
-accordingly (except on SQLite, where we don't get have the code to edit UNIQUE
-constraints).
-
-
-

File south-doc-ja/_sources/commands.txt

-
-.. _commands:
-
-コマンドリファレンス
-====================
-
-.. Command Reference
-   =================
-
-South is mainly used via the console and its three important commands: migrate,
-schemamigration and datamigration. It also overrides a few parts of syncdb.
-
-migrate
--------
-
-The migrate command is used to control the migration of the system forwards or
-backwards through the series of migrations for any given app.
-
-The most common use is::
-
- ./manage.py migrate myapp
- 
-This will migrate the app myapp forwards through all the migrations.
-If you want to migrate all the apps at once, run::
-
- ./manage.py migrate
-
-This has the same effect as calling the first example for every app,
-and will deal with Dependencies properly.
-
-You can also specify a specific migration to migrate to::
-
- ./manage.py migrate myapp 0002_add_username
-
-Note that, if the system has already migrated past the specified migration,
-it will roll back to it instead. If you want to migrate all the way back,
-specify the special migration name zero::
-
- ./manage.py migrate myapp zero
-
-You can also just give prefixes of migrations, to save typing::
-
- ./manage.py migrate myapp 0002
-
-But they must be unique::
-
- $ ./manage.py migrate myapp 000
- Running migrations for myapp:
-  - Prefix 00 matches more than one migration:
-      0001_initial
-      0002_add_username
-
-Options
-^^^^^^^
-
- - ``--all``: Used instead of an app name, allows you to migrate all
-   applications to the same target. For example,
-   ``./manage.py migrate --all --fake 0001`` if you are converting a lot of apps.
- - ``--list``: Shows what migrations are available, and puts a * next to
-   ones which have been applied.
- - ``--merge``: Runs any missed (out-of-order) migrations without rolling
-   back to them.
- - ``--no-initial-data``: Doesn't load in any initial data fixtures after a
-   full upwards migration, if there are any.
- - ``--fake``: Records the migration sequence as having been applied, but
-   doesn't actually run it. Useful for ConvertingAnApp.
- - ``--db-dry-run``: Loads and runs the migration, but doesn't actually
-   access the database (the SQL generated is thrown away at the last minute).
-   The migration is also not recorded as being run; this is useful for
-   sanity-testing migrations to check API calls are correct.
-
-Conflict Resolution
-^^^^^^^^^^^^^^^^^^^
-
-South's migration system really comes into its own when you start getting
-conflicting migrations - that is, migrations that have been applied in
-the wrong sequence.
-
-One example is if Anne writes new migrations 0003_foo and 0004_bar, runs the
-migration up to 0004 to make sure her local copy is up-to-date, and then updates
-her code from (say) Subversion. In the meantime, her coworker Bob has written a
-migration 0003_baz, which gets pulled in.
-
-Now, there's a problem. 0003_phou should have been applied before 0004_bar,
-but it hasn't been; in this situation, South will helpfully say something like::
-
-  Running migrations for aeblog:
-   - Current migration: 5 (after 0004_bar)
-   - Target migration: 5 (after 0004_bar)
-   ! These migrations should have been applied already, but aren't:
-     - 0003_phou
-   ! Please re-run migrate with one of these switches:
-     --skip: Ignore this migration mismatch and keep going
-     --merge: Just apply the missing migrations out of order
-     If you want to roll back to the first of these migrations
-     and then roll forward, do:
-       ./manage.py migrate --skip 0002_add_username
-       ./manage.py migrate
-
-As you can see, you have two real options; ``--merge``, which will just apply
-the missing migration and continue, and the two commands which roll back to
-before the missing migration (using ``--skip`` to ignore the error we're dealing
-with) and then migrating properly, in order, from there to the end.
-
-Using ``--skip`` by itself will let you continue, but isn't much of a solution;
-South will still complain the next time you run a migrate without ``--skip``.
-
-Sometimes, even worse things happen and South finds out that an applied
-migration has gone missing from the filesystem. In this scenario, it will
-politely tell you to go fix the problem yourself, although in more recent
-versions, you also have the option to tell South to wipe all records of the
-missing migrations being applied.
-
-Initial Data and post_syncdb
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-South will load initial_data files in the same way as syncdb, but it loads them
-at the end of every successful migration process, so ensure they are kept
-up-to-date, along with the rest of your fixtures (something to help ease the
-pain of migrating fixtures may appear shortly in South).
-
-South also sends the post_syncdb signal when a model's table is first created
-(this functionality requires that you generated those migrations with
-startmigration). This behaviour is intended to mirror the behaviour of syncdb,
-although for sanity reasons you may want to consider moving any setup code
-connected to such a signal into a migration.
-
-schemamigration
----------------
-
-*(In South 0.6 and below, this is called startmigration)*
-
-While migrate is the real meat and bones of South, schemamigration is by
-comparison an entirely optional extra. It's a utility to help write some of
-your migrations (specifically, the ones which change the schema) for
-you; if you like, you can ignore it and write everything youself, in which
-case we wish you good luck, and happy typing.
-
-However, if you have a sense of reason, you'll realise that having the large
-majority of your migrations written for you in undoubtedly a good thing.
-
-The main use of schemamigration is when you've just finished your shiny new
-models.py and want to load up your database. In vanilla Django, you'd just run
-syncdb - however, with migrations, you'll need a migration to create the tables.
-
-In this scenario, you just run::
-
- ./manage.py schemamigration myapp --initial
-
-That will write one big migration to create all the tables for the models in
-your app; just run ``./manage.py migrate`` to get it in and you're done in only
-one more step than syncdb!
-
-Later on, you'll add models to your app, or change your fields. Each time you do
-this, run schemamigration with the --auto flag::
-
- ./manage.py schemamigration myapp --auto changed_user_model_bug_434
-
-You can also manually specify changes::
-
- ./manage.py schemamigration mitest some_cols --add-field User.age --add-model User
-
-See the tutorial for more.
-
-Finally, if you're writing a schema migration that South can't automatically create
-for you (yet!) then you can just create a skeleton:
-
-./manage.py schemamigration myapp my_new_column_migration --empty
-
-Note that if you're writing a data migration, you should use the
-:ref:`commands-datamigration` command instead.
-
-Options
-^^^^^^^
-
-Note that you can combine as many ``--add-X`` options as you like.
-
- - ``--add-model``: Generates a creation migration for the given modelname.
- - ``--add-field``: Generates an add-column migration for modelname.field.
- - ``--add-index``: Generates an add-index migration for modelname.field.
- - ``--initial``: Like having --model for every model in your app.
-   You should use this only for your first migration.
- - ``--auto``: Generates a migration with automatically-detected actions.
- - ``--stdout``: Writes the migration to stdout instead of a file.
-
-.. _commands-datamigration: 
- 
-datamigration
--------------
-
-*(In South 0.6 and below, this is called startmigration)*
-
-When you want to create a data migration, use this command to create a blank
-template to write your migration with::
-
- ./manage.py datamigration books capitalise_titles
- 
-You can also freeze in additional apps if you want::
-
- ./manage.py datamigration books capitalise_titles --freeze awards
-
-Options
-^^^^^^^
-
- - ``--freeze``: Use appname or appname.modelname to freeze additional models into the app.
- - ``--stdout``: Writes the migration to stdout instead of a file.
- 
- 
-graphmigrations
----------------
-
-*(New in South 0.7)*
-
-Run this command to generate a graphviz .dot file for your migrations; you
-can then use this to generate a graph of your migrations' dependencies.
-
-Typical usage::
-
- ./manage.py graphmigrations | dot -Tpng -omigrations.png
- 
-This command can be particularly helpful to examine complex dependency sets
-between lots of different apps [#]_.
-
- .. [#] This command was written and used for the first time while helping the
-        debug the rather complex set of dependencies in django-cms; it's quite
-        a sight to behold.
-
-Options
-^^^^^^^
-
-This command has no options.
-
-
-syncdb
-------
-
-South overrides the Django syncdb command; as well as changing the output
-to show apps delineated by their migration status, it also makes syncdb only
-work on a subset of the apps - those without migrations.
-
-If you want to run syncdb on all of the apps, then use ``--all``, but be warned;
-this will put your database schema and migrations out of sync. If you do this,
-you *might* be able to fix it with::
-
- ./manage.py migrate --fake
-
-Options
-^^^^^^^
-
- - ``--all``: Makes syncdb operate on all apps, not just unmigrated ones.

File south-doc-ja/_sources/convertinganapp.txt

-
-.. _converting-an-app:
-
-Converting An App
-=================
-
-Converting an app to use South is very easy:
-
- - Edit your settings.py and put 'south' into `INSTALLED_APPS`
-   (assuming you've installed it to the right place)
- 
- - Run ``./manage.py syncdb`` to load the South table into the database.
-   Note that syncdb looks different now - South modifies it.
-
- - Run ``./manage.py convert_to_south myapp`` - South will automatically make and
-   pretend to apply your first migration.
- 
-Converting other installations and servers
-------------------------------------------
-
-The convert_to_south command only works entirely on the first machine you run it
-on. Once you've committed the initial migrations it made into the database,
-you'll have to run ``./manage.py migrate myapp 0001 --fake`` on every machine that
-has a copy of the codebase (make sure they were up-to-date with models and
-schema first).
-
-Remember that new installations of the codebase after this don't need these
-steps; you need only do a syncdb then a normal migrate.

File south-doc-ja/_sources/customfields.txt

-
-.. _custom-fields:
-
-カスタムフィールド
-==================
-
-.. Custom Fields
-   =============
-
-問題点
-------
-
-.. The Problem
-   -----------
-
-South stores field definitions by storing both their class and the arguments that
-need to be passed to the field's constructor, so it can recreate the field
-instance simply by calling the class with the stored arguments.
-
-However, since Python offers no way to get the arguments used in a class'
-constructor directly, South uses something called the *model introspector* to
-work out what arguments fields were passed. This knows what variables the
-arguments are stored into on the field, and using this knowledge, can
-reconstruct the arguments directly.
-
-This isn't the case for custom fields [#]_, however; South has never seen them
-before, and it can't guess at which variables mean what arguments, or what
-arguments are even needed; it only knows the rules for Django's internal fields
-and those of common third-party apps (those which are either South-aware, or
-which South ships with a rules module for, such as django-tagging).
-
-.. [#] 'Custom Fields' in this context refers to any field that is not part
-       of Django's core. GeoDjango fields are part of the core, but ones in
-       third-party apps are 'custom'. Note also that a field is considered
-       custom even if it inherits directly from a core field and doesn't
-       override anything; there's no way for South to reliably tell that it does
-       so.
-
-解決策
-------
-
-.. The Solution
-   ------------
-
-There are two ways to tell South how to work with a custom field; if it's
-similar in form to other fields (in that it has a set type and a few options)
-you'll probably want to :ref:`extend South's introspection rules
-<extending-introspection>`.
-
-However, if it's particularly odd - such as a field which takes fields as
-arguments, or dynamically changes based on other factors - you'll probably find
-it easier to :ref:`add a south_field_triple method <south-field-triple>`.
-
-
-.. _extending-introspection:
-
-Extending Introspection
-=======================
-
-(Note: This is also featured in the tutorial in :ref:`tutorial-part-4`)
-
-South does the majority of its field introspection using a set of simple rules;
-South works out what class a field is, and then runs all rules which have been
-defined for either that class or a parent class of it.
-
-This way, all of the common options (such as ``null=``) are defined against the 
-main ``Field`` class (which all fields inherit from), while specific options
-(such as ``max_length``) are defined on the specific fields they apply to
-(in this case, ``CharField``).
-
-If your custom field inherits from a core Django field, and doesn't add any new
-attributes, then you probably won't have to add any rules for it, as it will
-inherit all those from its parents.
-
-However, South first checks that it has explicitly been told a class is
-introspectable first; even though it will probably have rules defined (since it
-inherits from Field, at least), there's no way to guarantee that it knows about
-all of the possible rules until it has been told so.
-
-Thus, there are two stages to adding support for your custom field to South;
-firstly, adding some rules for the new arguments it introduces (or possibly
-not adding any), and secondly, adding its field name to the list of patterns
-South knows are safe to introspect.
-
-Rules
------
-
-Rules are what make up the core logic of the introspector; you'll need to pass
-South a (possibly empty) list of them. They consist of a tuple, containing:
-
- - A class or tuple of classes to which the rules apply (remember, the rules
-   apply to the specified classes and all subclasses of them).
-   
- - Rules for recovering positional arguments, in order of the arguments (you are
-   strongly advised not to use this feature, and use keyword argument instead).
- 
- - A dictionary of keyword argument rules, with the key being the name of the
-   keyword argument, and the value being the rule.
-
-Each rule is itself a list or tuple with two elements:
-
- - The first element is the name of the attribute the value is taken from - if
-   a field stored its max_length argument as ``self.max_length``, say, this
-   would be ``"max_length"``.
-   
- - The second element is a (possibly empty) dictionary of options describing the
-   various different variations on handling of the value.
-
-An example (this is the South rule for the many-to-one relationships in core
-Django)::
-
-  rules = [
-    (
-      (models.ForeignKey, models.OneToOneField),
-      [],
-      {
-          "to": ["rel.to", {}],
-          "to_field": ["rel.field_name", {"default_attr": "rel.to._meta.pk.name"}],
-          "related_name": ["rel.related_name", {"default": None}],
-          "db_index": ["db_index", {"default": True}],
-      },
-    )
-  ]
-
-You'll notice that you're allowed to have dots in the attribute name; ForeignKeys,
-for example, store their destination model as ``self.rel.to``, so the attribute
-name is ``"rel.to"``.
-
-The various options are detailed below; most of them allow you to specify the
-default value for a parameter, so arguments can be omitted for clarity where
-they're not necessary.
-
-.. _is-value-keyword:
-
-The one special case is the ``is_value`` keyword; if this is present and True,
-then the first item in the list will be interpreted as the actual value, rather
-than the attribute path to it on the field. For example::
-
- "frozen_by_south": [True, {"is_value": True}],
-
-Parameters
-^^^^^^^^^^
-
- - default: The default value of this field (directly as a Python object).
-   If the value retrieved ends up being this, the keyword will be omitted
-   from the frozen result. For example, the base Field class' "null" attribute
-   has {'default':False}, so it's usually omitted, much like in the models.
-
- - default_attr: Similar to default, but the value given is another attribute
-   to compare to for the default. This is used in to_field above, as this
-   attribute's default value is the other model's pk name.
-
- - default_attr_concat: For when your default value is even more complex,
-   default_attr_concat is a list where the first element is a format string,
-   and the rest is a list of attribute names whose values should be formatted
-   into the string.
-
- - ignore_if: Specifies an attribute that, if it coerces to true, causes this
-   keyword to be omitted. Useful for ``db_index``, which has
-   ``{'ignore_if': 'primary_key'}``, since it's always True in that case.
- 
- - ignore_dynamics: If this is True, any value that is "dynamic" - such as model
-   instances - will cause the field to be omitted instead. Used internally
-   for the ``default`` keyword.
-
- - is_value: If present, the 'attribute name' is instead used directly as the
-   value. See :ref:`above <is-value-keyword>` for more info.
- 
- 
-Field name patterns
--------------------
-
-The second of the two steps is to tell South that your field is now safe to
-introspect (as you've made sure you've added all the rules it needs). 
-
-Internally, South just has a long list of regular expressions it checks fields'
-classes against; all you need to do is provide extra arguments to this list.
-
-Example (this is in the GeoDjango module South ships with, and presumes
-``rules`` is the rules triple you defined previously)::
-
- from south.modelsinspector import add_introspection_rules
- add_introspection_rules(rules, ["^django\.contrib\.gis"])
- 
-Additionally, you can ignore some fields completely if you know they're not
-needed. For example, django-taggit has a manager that actually shows up as a
-fake field (this makes the API for using it much nicer, but confuses South to no
-end). The django-taggit module we ship with contains this rule to ignore it::
-
- from south.modelsinspector import add_ignored_fields
- add_ignored_fields(["^taggit\.managers"])
- 
-Where to put the code
----------------------
-
-You need to put the call to ``add_introspection_rules`` somewhere where it will
-get called before South runs; it's probably a good choice to have it either in
-your ``models.py`` file or the module the custom fields are defined in.
-
-General Caveats
----------------
-
-If you have a custom field which adds other fields to the model dynamically
-(i.e. it overrides contribute_to_class and adds more fields onto the model),
-you'll need to write your introspection rules appropriately, to make South
-ignore the extra fields at migration-freezing time, or to add a flag to your
-field which tells it not to make the new fields again. An example can be
-found `here <http://bitbucket.org/carljm/django-markitup/src/tip/markitup/fields.py#cl-68>`_.
-
-.. _south-field-triple:
-
-south_field_triple
-==================
-
-There are some cases where introspection of fields just isn't enough;
-for example, field classes which dynamically change their database column
-type based on options, or other odd things.
-
-Note: :ref:`Extending the introspector <extending-introspection>` is often far
-cleaner and easier than this method.
-
-The method to implement for these fields is ``south_field_triple()``.
-
-It should return the standard triple of::
-
- ('full.path.to.SomeFieldClass', ['positionalArg1', '"positionalArg2"'], {'kwarg':'"value"'})
-
-(this is the same format used by the :ref:`ORM Freezer <orm-freezing>`;
-South will just use your output verbatim).
-
-Note that the strings are ones that will be passed into eval, so for this
-reason, a variable reference would be ``'foo'`` while a string
-would be ``'"foo"'``.
-
-Example
--------
-
-Here's an example of this method for django-modeltranslation's TranslationField.
-This custom field stores the type it's wrapping in an attribute of itself,
-so we'll just use that::
-
- def south_field_triple(self):
-     "Returns a suitable description of this field for South."
-     # We'll just introspect the _actual_ field.
-     from south.modelsinspector import introspector
-     field_class = self.translated_field.__class__.__module__ + "." + self.translated_field.__class__.__name__
-     args, kwargs = introspector(self.translated_field)
-     # That's our definition!
-     return (field_class, args, kwargs)

File south-doc-ja/_sources/databaseapi.txt

-
-.. _database-api:
-
-データベース API
-================
-
-.. Database API
-   ============
-
-South ships with a full database-agnostic API for performing schema changes
-on databases, much like Django's ORM provides data manipulation support.
-
-Currently, South supports:
-
- - PostgreSQL
- - MySQL
- - SQLite
- - Microsoft SQL Server (beta support)
- - Oracle (alpha support)
-
-
-.. _accessing-the-api:
-
-API へのアクセス
-----------------
-
-.. Accessing The API
-   -----------------
-
-South automatically exposes the correct set of database API operations as
-``south.db.db``; it detects which database backend you're using from your
-Django settings file. It's usually imported using::
-
- from south.db import db
-
-If you're using multiple database support (Django 1.2 and higher),
-there's a corresponding ``south.db.dbs`` dictionary
-which contains a DatabaseOperations object (the object which has the methods
-defined above) for each database alias in your configuration file::
-
- from south.db import dbs
- dbs['users'].create_table(...)
- 
-You can tell which backend you're talking to inside of a migration by examining
-``db.backend_name`` - it will be one of ``postgres``, ``mysql``, ``sqlite3``, 
-``pyodbc`` or ``oracle``.
-
-
-.. Database-Specific Issues
-   ------------------------
-
-特定のデータベースについて
---------------------------
-
-South provides a large amount of features, and not all features are supported by
-all database backends.
-
- - PostgreSQL supports all of the South features; if you're unsure which database
-   engine to pick, it's the one we recommend for migrating on.
-
- - MySQL doesn't have transaction support for schema modification, meaning that
-   if a migration fails to apply, the database is left in an inconsistent state,
-   and you'll probably have to manually fix it. South will try and sanity-check
-   migrations in a dry-run phase, and give you hints of what to do when it
-   fails, however.
-
- - SQLite doesn't natively support much schema altering at all, but South
-   has workarounds to allow deletion/altering of columns. Unique indexes are
-   still unsupported, however; South will silently ignore any such commands.
- 
- - SQL Server has been supported for a while, and works in theory, but the
-   implementation itself may have bugs, as it's a contributed module and isn't
-   under primary development. Patches and bug reports are welcome.
- 
- - Oracle is a new module as of the 0.7 release, and so is very much alpha.
-   The most common operations work, but others may be missing completely;
-   we welcome bug reports and patches against it (as with all other modules).
-
-
-.. Methods
-   -------
-
-メソッド
---------
-
-These are how you perform changes on the database. See :ref:`accessing-the-api`
-to see how to get access to the ``db`` object.
-
-.. contents::
-   :local:
-   :depth: 1
- 
-
-
-db.add_column
-^^^^^^^^^^^^^
-
-::
-
- db.add_column(table_name, field_name, field, keep_default=True)
- 
-Adds a column called ``field_name`` to the table ``table_name``, of the type
-specified by the field instance field.
-
-If ``keep_default`` is True, then any default value specified on the field will
-be added to the database schema for that column permanently. If not, then the
-default is only used when adding the column, and then dropped afterwards.
-
-Note that the default value for fields given here is only ever used when
-adding the column to a non-empty table; the default used by the ORM in your
-application is the one specified on the field in your models.py file, as Django
-handles adding default values before the query hits the database.
-
-The only case where having the default stored in the database as well would make
-a difference would be where you are interacting with the database from somewhere
-else, or Django doesn't know about the added column at all.
-
-Also, note that the name you give for the column is the **field name**, not the
-column name - if the field you pass in is a ForeignKey, for example, the
-real column name will have _id on the end.
-
-Examples
-""""""""
-
-A normal column addition (the column is nullable, so all existing rows will have
-it set to NULL)::
-
- db.add_column('core_profile', 'height', models.IntegerField(null=True))
-
-Providing a default value instead, so all current rows will get this value for
-'height'::
-
- db.add_column('core_profile', 'height', models.IntegerField(default=-1))
-
-Same as above, but the default is not left in the database schema::
-
- db.add_column('core_profile', 'height', models.IntegerField(default=-1), keep_default=False)
-
-
-
-db.alter_column
-^^^^^^^^^^^^^^^
-
-::
-
- db.alter_column(table_name, column_name, field, explicit_name=True)
- 
-Alters the column ``column_name`` on the table ``table_name`` to match
-``field``. Note that this cannot alter all field attributes; for example, if
-you want to make a field ``unique=True``, you should instead use
-``db.add_index`` with ``unique=True``, and if you want to make it a primary
-key, you should look into ``db.drop_primary_key`` and ``db.create_primary_key``.
-
-If explicit_name is false, ForeignKey? fields will have _id appended to the end
-of the given column name - this lets you address fields as they are represented
-in the model itself, rather than as the column name.
-
-Examples
-""""""""
-
-A simple change of the length of a VARCHAR column::
-
- # Assume the table was created with name = models.CharField(max_length=50)
- db.alter_column('core_nation', 'name', models.CharField(max_length=200))
-
-We can also change it to a compatible field type::
-
- db.alter_column('core_nation', 'name', models.TextField())
-
-If we have a ForeignKey? named 'user', we can address it without the implicit '_id' on the end::
-
- db.alter_column('core_profile', 'user', models.ForeignKey(orm['auth.User'], null=True, blank=True), explicit_name=False)
-
-Or you can specify the same operation with an explicit name::
-
- db.alter_column('core_profile', 'user_id', models.ForeignKey(orm['auth.User'], null=True, blank=True))
-
-
-
-db.clear_table
-^^^^^^^^^^^^^^
-
-::
-
- db.clear_table(table_name)
-
-Deletes all rows from the table (truncation). Never used by South's
-autogenerators, but can prove useful if you're writing data migrations.
-
-Examples
-""""""""
-
-Clear all cached geocode results, as the schema is changing::
-
- db.clear_table('core_geocoded')
- db.add_column('core_geocoded', ...) 
-
-
-
-db.commit_transaction
-^^^^^^^^^^^^^^^^^^^^^
-
-::
-
- db.commit_transaction()
- 
-Commits the transaction started at a ``db.start_transaction`` call.
-
-
-
-db.create_index
-^^^^^^^^^^^^^^^
-
-::
-
- db.create_index(table_name, column_names, unique=False, db_tablespace='')
- 
-Creates an index on the list of columns ``column_names`` on the table
-``table_name``.
-
-By default, the index is simply for speed; if you would like a unique index,
-then specify ``unique=True``, although you're better off using
-``db.create_unique`` for that.
-
-``db_tablespace`` is an Oracle-specific option, and it's likely you won't need
-to use it.
-
-Examples
-""""""""
-
-Creating an index on the 'name' column::
-
- db.create_index('core_profile', ['name'])
- 
-Creating a unique index on the combination of 'name' and 'age' columns::
-
- db.create_index('core_profile', ['name', 'age'], unique=True)
-
-
-
-db.create_primary_key
-^^^^^^^^^^^^^^^^^^^^^
-
-::
-
- db.create_primary_key(table_name, columns)
- 
-Creates a primary key spanning the given ``columns`` for the table. Remember,
-you can only have one primary key per table; use ``db.delete_primary_key``
-first if you already have one.
-
-Examples
-""""""""
-
-Swapping from the ``id`` to ``uuid`` as a primary key::
-
- db.delete_primary_key('core_upload')
- db.create_primary_key('core_upload', ['uuid'])
- 
-Adding a new composite primary key on "first name" and "last name"::
-
- db.create_primary_key('core_people', ['first_name', 'last_name'])
- 
-
-
-db.create_table
-^^^^^^^^^^^^^^^
-
-::
-
- db.create_table(table_name, fields)
- fields = ((field_name, models.SomeField(somearg=4)), ...)
- 
-This call creates a table called *table_name* in the database with the schema
-specified by *fields*, which is a tuple of ``(field_name, field_instance)``
-tuples.
-
-Note that this call will not automatically add an id column;
-you are responsible for doing that.
-
-We recommend you create calls to this function using ``schemamigration``, either
-in ``--auto`` mode, or by using ``--add-model``.
-
-Examples
-""""""""
-
-A simple table, with one field, name, and the default id column::
-
- db.create_table('core_planet', (
-     ('id', models.AutoField(primary_key=True)),
-     ('name', models.CharField(unique=True, max_length=50)),
- ))
- 
-A more complex table, which uses the ORM Freezer for its foreign keys::
-
- db.create_table('core_nation', (
-     ('name', models.CharField(max_length=255)),
-     ('short_name', models.CharField(max_length=50)),
-     ('slug', models.SlugField(unique=True)),
-     ('planet', models.ForeignKey(orm.Planet, related_name="nations")),
-     ('flag', models.ForeignKey(orm.Flag, related_name="nations")),
-     ('planet_name', models.CharField(max_length=50)),
-     ('id', models.AutoField(primary_key=True)),
- ))
-
-
-
-db.create_unique
-^^^^^^^^^^^^^^^^
-
-::
-
- create_unique(table_name, columns)
- 
-Creates a unique index or constraint on the list of columns ``columns`` on the
-table ``table_name``.
-
-Examples
-""""""""
-
-Declare the pair of fields ``first_name`` and ``last_name`` to be unique::
-
- db.create_unique('core_people', ['first_name', 'last_name'])
-
-
-
-db.delete_column
-^^^^^^^^^^^^^^^^
-
-::
-
- db.delete_column(table_name, column_name)
- 
-Deletes the column ``column_name`` from the table ``table_name``.
-
-Examples
-""""""""
-
-Delete a column from a table::
-
- db.delete_column('core_nation', 'title')
-
-
-
-db.delete_foreign_key
-^^^^^^^^^^^^^^^^^^^^^
-
-::
-
- delete_foreign_key(table_name, column)
- 
-Drops any foreign key constraints on the given column, if the database backend
-supported them in the first place.
-
-Examples
-""""""""
-
-Remove the foreign key constraint from user_id:
-
- db.delete_foreign_key('core_people', 'user_id')
-
-
-
-db.delete_primary_key
-^^^^^^^^^^^^^^^^^^^^^
-
-::
-
- db.delete_primary_key(table_name)
- 
-Deletes the current primary key constraint on the table. Does not remove the
-columns the primary key was using.
-
-Examples
-""""""""
-
-Swapping from the ``id`` to ``uuid`` as a primary key::
-
- db.delete_primary_key('core_upload')
- db.create_primary_key('core_upload', ['uuid'])
- 
-
- 
-db.delete_table
-^^^^^^^^^^^^^^^
-
-::
-
- db.delete_table(table_name, cascade=True)
-
-Deletes (drops) the named table from the database. If cascade is True, drops any
-related constraints as well.
-
-Examples
-""""""""
-
-Usual call::
-
- db.delete_table("core_planet")
-
-Not cascading (beware, may fail)::
-
- db.delete_table("core_planet", cascade=False)
-
-
-
-db.delete_unique
-^^^^^^^^^^^^^^^^
-
-::
-
- delete_unique(table_name, columns)
- 
-Deletes a unique index or constraint on the list of columns ``columns`` on the
-table ``table_name``. The constraint/index. must already exist.
-
-Examples
-""""""""
-
-Declare the pair of fields ``first_name`` and ``last_name`` to no longer
-be unique::
-
- db.delete_unique('core_people', ['first_name', 'last_name'])
-
-
-
-db.execute
-^^^^^^^^^^
-
-::
-
- db.execute(sql, params=[])
- 
-Executes the **single** raw SQL statement ``sql`` on the database; optionally
-use params to replace the %s instances in sql (this is the recommended way of
-doing parameters, as it escapes them correctly for all databases).
-
-If you want to execute a series of SQL statements instead, use
-``db.execute_many``.
-
-Note that you should avoid using raw SQL wherever possible, as it will break the
-database abstraction in many cases. If you want to handle data, consider using
-the ORM Freezer, and remember that many operations such as creating indexes and
-changing primary keys have functions in the DB layer.
-
-If there's a common operation you'd like to see added to the DB abstraction
-layer in South, consider asking on the mailing list or creating a ticket.
-
-Examples
-""""""""
-
-VACUUMing a table::
-
- db.execute("VACUUM ANALYZE core_profile")
-
-Updating values (this sort of task should really be done using the frozen ORM)::
-
- db.execute("UPDATE core_profile SET name = %s WHERE name = %s", ["andy", "andrew"])
-
-
-
-db.execute_many
-^^^^^^^^^^^^^^^
-
-::
-
- db.execute_many(sql, regex=r"(?mx) ([^';]* (?:'[^']*'[^';]*)*)", comment_regex=r"(?mx) (?:^\s*$)|(?:--.*$)")
- 
-Executes the given multi-statement SQL string ``sql``. The two parameters are
-the regular expressions for splitting up statements (``regex``) and removing
-comments (``comment_regex``). We recommend you leave these at their default
-values, as they work on almost all SQL files.
-
-If you only want to execute a single SQL statement, consider using
-``db.execute``, as it offers parameter escaping, and the regexes sometimes get
-the splitting wrong.
-
-Examples
-""""""""
-
-Run the PostGIS initialisation file::
-
- db.execute_many(open("/path/to/lwpostgis.sql").read())
-
-
-
-db.rename_column
-^^^^^^^^^^^^^^^^
-
-::
-
- db.rename_column(table_name, column_name, new_column_name)
- 
-Renames the column ``column_name`` in table ``table_name`` to
-``new_column_name``.
-
-Examples
-""""""""
-
-Simple rename::
-
- db.rename_column('core_nation', 'name', 'title')
-
- 
-
-db.rename_table
-^^^^^^^^^^^^^^^
-
-::
-
- db.rename_table(table_name, new_table_name)
-
-Renames the table table_name to the new name new_table_name.
-
-This won't affect what tables your models are looking for, of course;
-this is useful, for example, if you've renamed a model
-(and don't want to specify the old table name in Meta).
-
-Examples
-""""""""
-
-Simple rename::
-
- db.rename_table('core_profile', 'core_userprofile')
-
-
-
-db.rollback_transaction
-^^^^^^^^^^^^^^^^^^^^^^^
-
-::
-
- db.rollback_transaction()
- 
-Rolls back the transaction started at a ``db.start_transaction`` call.
-
-
-
-db.send_create_signal
-^^^^^^^^^^^^^^^^^^^^^
-
-::
-
- db.send_create_signal(app_label, model_names)
- 
-Sends the post_syncdb signal for the given models ``model_names`` in the app
-``app_label``.
-
-This signal is used by various bits of django internals - such as contenttypes
-- to hook new models into themselves, so you should really call it after the
-relevant ``db.create_table`` call. ``startmigration`` will add this
-automatically for you.
-
-Note that the signals are not sent until the end of the whole migration
-sequence, so your handlers will not get called until all migrations are done.
-This is so that your handlers can deal with the most recent version of the
-model's schema, rather than the one in the migration where the signal is
-originally sent.
-
-Examples
-""""""""
-
-Sending a signal for the 'Profile' and 'Planet' models in my app 'core'::
-
- db.send_create_signal('core', ['Profile', 'Planet'])
-
-
-
-db.start_transaction
-^^^^^^^^^^^^^^^^^^^^
-
-::
-
- db.start_transaction()
- 
-Wraps the following code (until it meets a ``db.rollback_transaction`` or
-``db.commit_transaction`` call) in a transaction.
-
- 
-

File south-doc-ja/_sources/dependencies.txt

-
-.. _dependencies:
-
-Dependencies
-============
-
-Migrations for apps are nice 'n all, but when you start writing a large project,
-with a lot of apps, you realise you have foreign key relationships between apps
-and working out what order migrations would need to be applied in for each app
-is just painful.
-
-Luckily, we also had this problem, so South has a dependency system. Inside a
-migration, you can declare that it depends on having another app having run a
-certain migration first; for example, if my app "forum" depends on the
-"accounts" app having created its user profile table, we can do::
-
-    # forum/migrations/0002_post.py
-    class Migration:
-        
-        depends_on = (
-            ("accounts", "0003_add_user_profile"),
-        )
-    
-        def forwards(self):
-            ....
-
-Then, if you try and migrate to or beyond 0002_post in the forum app, it will
-first make sure accounts is migrated at least up to 0003_add_user_profile,
-and if not will migrate it for you.
-
-Dependencies also work in reverse; South knows not to undo that
-0003_add_user_profile migration until it has undone the 0002_post migration.
-
-You can have multiple dependencies, and all sorts of wacky structures;
-there are, however, two rules:
-
- - No circular dependencies (two or more migrations depending on each other)
- - No upwards dependencies in the same app (so you can't make 0002_post in the forum app depend on 0003_room in the same app, either directly or through a dependency chain.
-
-Reverse Dependencies
---------------------
-
-South also supports "reverse dependencies" - a dependecy where you say your
-migration must be run before another, rather than vice-versa. This is useful
-if you're trying to run a migration before another in a separate, third-party
-(or unchangeable) code.
-
-Declaring these is just like the other kind, except you use needed_by::
-
-    class Migration:
-        
-        needed_by = (
-            ("accounts", "0005_make_fks"),
-        )
-    
-        def forwards(self):
-            ....

File south-doc-ja/_sources/fixtures.txt

-.. Fixtures
-   ========
-
-フィクスチャ
-============
-
-A few things change when you're using fixtures with South.
-
-initial_data
-------------
-
-Much like syncdb, South will load the initial_data fixture when an app has been
-successfully migrated to the latest migration for an app. Note that the data in
-the fixture will not be available before then; South only applies it at the end,
-as it may not match the current database schema.
-
-Fixtures from migrations
-------------------------
-
-If you need to load a fixture as part of your database setup - say, you have a
-migration that depends on it being around - the best thing to do is to write a
-new migration to load the fixture in. That way, the fixture will always be
-loaded at the correct time.
-
-To make such a migration, first make a blank migration::
-
- ./manage.py startmigration appname load_myfixture
-
-Then, open the new migration file, and restructure your forwards() method
-so it looks like this::
-
-    def forwards(self, orm):
-        from django.core.management import call_command
-        call_command("loaddata", "my_fixture.json")
- 
-(you'll have to leave backwards() empty,
-as there's no much you can do to reverse this).
-
-Then, when this migration is run, it will load the given fixture.

File south-doc-ja/_sources/generics.txt

-Generic Relations
-=================
-
-Generic relations' fields are be frozen, but unfortunately
-not the GenericForeignKey itself (see :ref:`orm-freezing` for a reason why).
-To add it back onto a model, add the import
-for generic at the top of the migration and then in the body of forwards() put::
-
-    gfk = generic.GenericForeignKey()
-    gfk.contribute_to_class(orm.FooModel, "object_link")
-
-This will add the GenericForeignKey onto the model as model.object_link.
-You can pass the optional content_type and id field names into the
-constructor as usual.
-
-Also, be careful when using ContentType; make sure to use the frozen
-orm['contenttypes.ContentType'], and don't import it directly,
-otherwise comparisons may fail.

File south-doc-ja/_sources/index.txt

-
-.. _index:
-
-South ドキュメント
-==================
-
-.. South documentation
-   ===================
-
-.. South is a tool to provide consistent, easy-to-use and database-agnostic migrations for Django applications.
-
-South は一貫性を保ちつつ、扱いが簡単で、かつ特定のデータベースに依存するようなことのないマイグレーション機能を提供する、Django アプリケーション用のツールです。
-
-.. This is the documentation for the current version (0.7); previous versions'
-   documentation was written directly into our wiki, but is mostly a subset of
-   what is written here.
-
-このドキュメントは現在のバージョン(0.7)を対象としています; 前のバージョンのドキュメントは直接 wiki に書かれていましたが、
-ほとんどはこのドキュメントの内容のサブセットになっています。
-
-.. If you want to view the old docs (for example, if you need something that was
-   only in 0.6) they're `still available <http://south.aeracode.org/wiki/OldDocumentation>`_.
-
-昔のドキュメントを見たい場合(例えば、0.6 にしかない何らかのものが必要になった場合など)は、
-`こちらから参照 <http://south.aeracode.org/wiki/OldDocumentation>`_ することができます。
-
-.. Support
-   -------
-
-サポート
---------
-
-.. For initial help with problems, see our `mailing list <http://groups.google.com/group/south-users>`_, or `#django-south <irc://irc.freenode.net/django-south>`_ on `freenode <http://freenode.net/>`_. If you find a real bug, then `file a new ticket <http://south.aeracode.org/newticket>`_.
-
-基本的な問題に対するヘルプは `メーリングリスト <http://groups.google.com/group/south-users>`_ か、
-`freenode <http://freenode.net/>`_ の `#django-south <irc://irc.freenode.net/django-south>`_ を参照して下さい。
-バグを発見した場合は、 `新しいチケットを作成 <http://south.aeracode.org/newticket>`_ して下さい。
-
-.. Contents
-   --------
-
-目次
-----
-
-.. toctree::
-   :maxdepth: 2
-   
-   about
-   whataremigrations
-   installation
-   tutorial/index
-   databaseapi
-   convertinganapp
-   migrationstructure
-   dependencies
-   commands
-   unittests
-   ormfreezing
-   generics
-   customfields
-   autodetector
-   signals
-   fixtures
-   settings
-   releasenotes/index
-
-   translation

File south-doc-ja/_sources/installation.txt

-
-.. _installation:
-
-インストール
-============
-
-.. Installation
-   ============
-
-.. South's current release is :ref:`0.7 <0-7-release-notes>`.
-
-South の最新リリースは :ref:`0.7 <0-7-release-notes>` です。
-
-.. There are a few different ways to install South:
-
-South をインストールするにはいくつかの方法があります:
-
-.. - :ref:`Using easy_install <installation-easy-install>` (or pip), which is recommended if you want stable releases.
-   - :ref:`Using a Mercurial checkout <installation-mercurial>`, recommended if you want cutting-edge features.
-   - :ref:`Using our downloadable archives <installation-archives>`, useful if you don't have easy_install or Mercurial.
-
-- :ref:`easy_install を使う <installation-easy-install>` (または pip), 安定リリース版を使いたい場合におすすめです。
-- :ref:`Mercurial でチェックアウトする <installation-mercurial>`, 開発最新版を使いたい場合におすすめです。
-- :ref:`アーカイブをダウンロードする <installation-archives>`, easy_install も Mercurial も無い場合にご利用下さい。
-
-.. Some Linux distributions are also starting to include South in their package
-   repositories; if you're running unstable Debian you can
-   ``apt-get install python-django-south``, and on new Fedoras you can use
-   ``yum install Django-south``. Note that this may give you an older version - 
-   check the version before using the packages.
-
-いくつかの Linux ディストリビューションでは South がパッケージリポジトリに登録され始めました;
-unstable な Debian なら ``apt-get install python-django-south`` を、最新の Fedoraならば
-``yum install Django-south`` としてインストールできます。
-これらは古いバージョンがインストールされるかもしれないことに注意して下さい - パッケージを利用する前にバージョンをご確認下さい。
-
-.. South should work with versions of Django from 0.97-pre through to 1.2, although
-   some features (such as multi-db) may not be available for older Django versions.
-
-South は Django の 0.97-pre から 1.2 までのバージョンで動作しますが、いくつかの機能(マルチDBなど)は古いバージョンの Django ではご利用できません。
-
-
-.. _installation-easy-install:
-
-easy_install を使う
--------------------
-
-.. Using easy_install
-   ------------------ 
-
-.. If you have easy_install available on your system, just type::
-
-システムに easy_install が入っているならば、以下のようにタイプするだけです::
-
- easy_install South
-
-.. If you've already got an old version of South, and want to upgrade, use::
-
-もし既に古いバージョンの South をインストールしていて、アップグレードしたい場合は::
-
- easy_install -U South
-
-.. That's all that's needed to install the package; you'll now want to
-   :ref:`configure your Django installation <installation-configure>`.
-
-これでパッケージのインストールは完了です; 次は :ref:`Django へのインストール設定 <installation-configure>` に進んで下さい。
-
-
-.. _installation-mercurial:
-
-Mercurial を使う
-----------------
-
-.. Using Mercurial
-   ---------------
-
-.. You can install directly from our Mercurial repo, allowing you to recieve
-   updates and bugfixes as soon as they're made. You'll need Mercurial installed
-   on your system; if it's not already, you'll want to get it. The package name
-   is ``mercurial`` on most Linux distributions; OSX and Windows users can download
-   packages from http://mercurial.berkwood.com.
-
-アップデートやバグフィックスがすぐに反映されて取得可能な、Mercurial のリポジトリから直接インストールすることもできます。
-システムに Mercurial がインストールされている必要があります; まだ Mercurial が入っていない場合は、インストールしましょう。
-大抵の Linux ディストリビューションにおけるパッケージ名は ``mercurial`` です; OSX や Windows ユーザーならば、
-http://mercurial.berkwood.com からパッケージをダウンロードすることができます。
-
-.. Make sure you're in a directory where you want the ``south`` directory to
-   appear, and run::
-
-``south`` ディレクトリが出来て欲しいディレクトリにいることを確認し、次のコマンドを実行して下さい::
-
- hg clone http://bitbucket.org/andrewgodwin/south/
-
-.. To update an existing Mercurial checkout to the newest version, run::
-
-Mercurial でチェックアウトしている既存のファイルを最新版にアップデートしたい場合は、次のコマンドを実行します::
-
- hg pull
- hg up -C tip
-
-.. (Rather than running from tip, you can also use the ``stableish`` tag, which is
-   manually set on reasonably stable trunk commits, or pick a version number tag.)
-
-(最新版である tip に更新するよりも、安定版の trunk コミットとして設定されている ``stableishi`` タグや、
-バージョン番号タグを指定するほうがいいかもしれません)
-
-.. Once you have this directory, move onto :ref:`installation-from-directory`.
-
-``south`` ディレクトリが取得できたので :ref:`installation-from-directory` に進みましょう。
-
-
-.. _installation-archives:
-
-アーカイブをダウンロードする
-----------------------------
-
-.. Using downloadable archives
-   ---------------------------
-
-.. If you're averse to using Mercurial, and don't have easy_install available, then
-   you can install from one of our ``.tar.gz`` files.
-
-Mercurial を使用したくない場合や、easy_install がインストールされていない場合などには、 ``.tar.gz`` ファイルからインストールすることができます。
-
-
-.. First, download the archive of your choice from
-   `our releases page <http://aeracode.org/releases/south>`_, and extract it to
-   create a ``south`` folder. Then, proceed with our instructions for
-   :ref:`installation-from-directory`.
-
-まず、 South の `リリースページ <http://aeracode.org/releases/south>`_ からアーカイブをダウンロードして、
-``south`` フォルダができるように解凍します。次に :ref:`installation-from-directory` の説明に進んで下さい。
-
-
-.. _installation-from-directory:
-
-ディレクトリからのインストール
-------------------------------
-
-.. Installing from a directory
-   ---------------------------
-
-.. If you've obtained a copy of South using either Mercurial or a downloadable
-   archive, you'll need to install the copy you have system-wide. Try running::
-
-Mercurial を使ったり、アーカイブをダウンロードして South のコピーを取得した場合、
-システム全体で利用できるように、そのコピーからインストールする必要があります。
-次のコマンドを実行して下さい::
-
- python setup.py develop
-
-.. If that fails, you don't have ``setuptools`` or an equivalent installed; either
-   install them, or run::
-
-もしこのコマンドが失敗した場合は、 ``setuptools`` かそれと同等のモジュールが
-インストールされていないので、それらをインストールするか、次のコマンドを実行して下さい::
-
- python setup.py install
-
-.. Note that ``develop`` sets the installed version to run from the directory you
-   just created, while ``install`` copies all the files to Python's
-   ``site-packages`` folder, meaning that if you update your checkout you'll need
-   to re-run ``install``.
-
-``develop`` はインストールされたバージョンを作成したディレクトリから起動するように設定しますが、
-``install`` は全てのファイルを Python の ``site-packages`` フォルダにコピーする、という点に注意して下さい。
-つまり、チェックアウトしたファイルを更新した際には、再度 ``install`` を実行する必要があります。
-
-.. You could also install South locally for only one project, by either including
-   with your project and modifying ``sys.path`` in your settings file, or
-   (preferably) by using virtualenv, pip and a requirements.txt. A tutorial in how
-   to use these is outside the scope of this documentation, but `there are
-   tutorials elsewhere <http://www.saltycrane.com/blog/2009/05/notes-using-pip-and-virtualenv-django/>`_.
-
-south をプロジェクト内に含めて settings ファイルの ``sys.path`` を変更するか、
-(なるべくなら) virtualenv や pip の requirements.txt を使うことで、
-ひとつのプロジェクトに対してのみ South をインストールすることもできます。
-これらの使用方法は、このドキュメントの範疇ではありませんが、
-`他の場所にチュートリアルがあります <http://www.saltycrane.com/blog/2009/05/notes-using-pip-and-virtualenv-django/>`_ 。
-
-.. Once you've done one of those, you'll want to
-   :ref:`configure your Django installation <installation-configure>`.
-
-ここまでの手順が完了したならば、 :ref:`Django へのインストール設定 <installation-configure>` に進んで下さい。
-
-
-.. _installation-configure:
-
-Django へのインストール設定
----------------------------
-
-.. Configuring your Django installation
-   ------------------------------------
-
-.. Now you've installed South system-wide, you'll need to configure Django to use
-   it. Doing so is simple; just edit your ``settings.py`` and add ``'south'`` to
-   the end of ``INSTALLED_APPS``.
-
-さて、システムへの South のインストールが完了したので、次は Django で使用するために設定します。
-やることは簡単です; ``settings.py`` を開いて ``INSTALLED_APPS`` に ``'south'`` を追加するだけです。
-
-.. If Django doesn't seem to pick this up, check that you're not overriding 
-   ``INSTALLED_APPS`` elsewhere, and that you can run ``import south`` from inside
-   ``./manage.py shell`` with no errors.
-
-もし Django が認識しないようならば、どこかで ``INSTALL_APPS`` を上書きしていないか、
-または ``./manage.py shell`` において ``import south`` がエラーを出さずに実行できるか確認して下さい。
-
-.. Now South is loaded into your project and ready to go, you'll probably want to
-   take a look at our :ref:`tutorial`.
-
-さあ、South がプロジェクトに読み込まれ、使う準備ができました。次は :ref:`tutorial` に進みましょう。

File south-doc-ja/_sources/migrationstructure.txt

-
-.. _migration-structure:
-
-Migration Structure
-===================
-
-Migrations are, at the most basic level, files inside your app's migrations/
-directory.
-
-When South loads migrations, it loads all the python files inside migrations/
-in ASCII sort order (e.g. 1 is before 10 is before 2), and expects to find a
-class called Migration inside each one, with at least a ``forwards()``
-and ``backwards()`` method.
-
-When South wants to apply a migration, it simply calls the ``forwards()``
-method, and similarly when it wants to roll back a migration it calls
-``backwards()``. It's up to you what you do inside these methods; the usual
-thing is to do database changes, but you don't have to.
-
-Sort Order
-----------
-
-Since migrations are loaded in ASCII sort order, they won't be applied in the
-correct order if you call them ``1_first, 2_second, ..., 10_tenth``.
-(10 sorts before 2).
-
-Rather than force a specific naming convention, we suggest that if you want to
-use numerical migrations in this fashion (as we suggest you do) that you prefix
-the numbers with zeroes like so: ``0001_first, 0002_second, 0010_tenth``.
-
-All of South's automatic creation code will follow this scheme.
-
-Transactions
-------------
-
-Whenever ``forwards()`` or ``backwards()`` is called it is called inside a
-database transaction, which is committed if the method executes successfully
-or rolled back if it raises an error.
-
-If you need to use two or more transactions inside a migration, either use
-two separate migrations (if you think it's appropriate), or have a snippet
-like this where you want a new transaction::
-
-    db.commit_transaction()     # Commit the first transaction
-    db.start_transaction()      # Start the second, committed on completion
-
-Note that you must commit and start the next transaction if you are making
-both data and column changes. If you don't do this, you'll end up with your
-database hating you for asking it the impossible.

File south-doc-ja/_sources/ormfreezing.txt

-
-.. _orm-freezing:
-
-ORM Freezing
-============
-
-South freezes the state of the ORM and models whenever you do a migration,
-meaning that when your migrations run in the future, they see the models and
-fields they're expecting (the ones that were around when they were created),
-rather than the current set (which could be months or even years newer).
-
-This is accomplished by serialising the models into a large dictionary called
-``models`` at the bottom of every migration. It's easy to see; it's the large
-chunk of dense code at the bottom.
-
-Rationale behind the serialisation
-----------------------------------
-
-South doesn't freeze every aspect of a model; for example, it doesn't
-preserve new managers, or custom model methods, as these would require
-serialising the python code that runs those method (and the code that depends on,
-and so forth).
-
-If you want custom methods in your migration, you'll have to copy the code in,
-including any imports it relies on to work.
-Remember, however, for every import that you add, you're promising to keep
-that import valid for the life for the migration.
-
-We also use a human-readable format that's easy to change; since South relies
-on the frozen models not only for reacreating the ORM but also for detecting
-changes, it's really useful to be able to edit them now and again (and also
-serves as a valuable debugging tool if you attach failing migrations to a
-ticket).
-
-Serialisation format
---------------------
-
-``models`` is a dict of ``{'appname.modelname': fields}``, and ``fields`` is a
-dict of ``{'fieldname': (fieldclass, positional_args, kwd_args)}``. ``'Meta'``
-is also a valid entry in fields, in which case the value should be a dict
-of its attributes.
-
-Make note that the entries in positional_args and kwd_args are
-**strings passed into eval**; thus, a string would be ``'"hello"'``.
-We strongly recommend you use schemamigration/datamigration to freeze things.
-
-Accessing the ORM
------------------
-
-From inside a migration, you can access models from the frozen ORM in two ways.
-If the model you're accessing is part of the same app, you can simply call::
-
- orm.ModelName
- 
-Otherwise, you'll need to specify the app name as well, using::
-
- orm['myapp.ModelName']
- 
-For example, if you wanted to get a user with ID 1, you could use::
-
- orm['auth.User'].objects.get(id=1)
- 
-Note that you can only access models that have been frozen; South automatically
-includes anything that could be reaches via foreign keys or many-to-many
-relationships, but if you want to add other models in, simply pass ``--freeze appname``
-to the ``./manage.py datamigration`` command.

File south-doc-ja/_sources/releasenotes/0.7.1.txt

-
-.. _0-7-1-release-notes:
-
-===========
-South 0.7.1
-===========
-
-This is a minor new release of South.
-
-
-Backwards incompatible changes
-==============================
-
-None.
-
-
-Major changes
-=============
-
-South tests
------------
-
-South's internal test suite now doesn't run by default (the ``SKIP_SOUTH_TESTS``
-setting now defaults to True). This is mainly because the test suite is meant
-to be run in isolation (the test framework continually changes
-``INSTALLED_APPS`` and fiddles with the ORM as it runs, among other things), and
-was causing compatability problems with other applications.
-
-If you wish to run the tests still, simply set ``SKIP_SOUTH_TESTS = False``.

File south-doc-ja/_sources/releasenotes/0.7.txt

-
-.. _0-7-release-notes:
-
-=========
-South 0.7
-=========
-
-This is a major new release of South. A lot of work has been done to the
-internals, and a few annoying remnants from South's history have
-finally been eradicated.
-
-
-Backwards incompatible changes
-==============================
-
-Tests now run with migrations by default, not using syncdb for everything as in
-0.6. This is the behaviour most people expect; to turn it off again,
-set ``SOUTH_TESTS_MIGRATE`` to False (migrating everything can be slow).
-
-In addition, you may note that some or all of your custom fields don't work when
-you upgrade; read more about this at :ref:`custom-fields`. You may also wish to
-change your old migration files and insert the full path to custom field classes
-in the ``models`` dictionary entries, to prevent future issues.
-
-
-Major changes
-=============
-
-Core Refactoring
-----------------
-
-The entire migration and dependency engine has been refactored to be
-class-based, rather than the mess of functions and variables it was before,
-and will now be a lot easier to maintain, as well as being nice and quick.
-
-Much thanks to Simon Law for doing a lot of the legwork on this one.
-
-Command Changes
----------------
- 
-The ``startmigration`` command (which used to be one massive file) has been
-removed, and refactored into new commands:
-
- - ``schemamigration``, which is very similar to the old ``startmigration``
- - ``datamigration``, which should be used to create new data migrations
-
-In addition, the ``--model`` argument to ``startmigration`` is now
-``--add-model`` on ``schemamigration``, for consistency with the other
-arguments, and ``schemamigration`` no longer requires a migration name; if you
-don't provide one, it will autogenerate a reasonably sensible one.
-
-Finally, South now detects when you're adding a column that needs a default
-value, and prompts you for it, rather than crashing when you tried to apply
-the migration, like before.
-
-Django Support
---------------
-
-This version of South fully supports Django 1.2 (as well as 1.1 and 1.0),
-and has some limited multi-db functionality (migrate has gained a --database
-option) [#]_.
-
-.. [#] Note that multi-db functionality is unavailable if using South 0.7 with
-       earlier versions of Django.
-
-Custom Fields
--------------
-
-Custom fields are no longer parsed if they don't introspect; instead, an
-error is raised every time. This is because parsing was causing scenarios where
-migrations sometimes worked, and then failed mysteriously later; the new
-solution means they'll always work or fail.
-
-This does have the unfortunate side-effect of making South not "magically" make
-your simpler custom fields work any more; we're trying to help by shipping
-introspection modules for the more common third-party apps with South, but you
-may also want to read the new 
-:ref:`reference for your own introspection rules <extending-introspection>`, or
-:ref:`our new tutorial chapter on it <tutorial-part-4>`.
-
-Migration Directories
----------------------
-
-You can now set custom migration directories (actually done as Python modules)
-if you need per-project migrations for an app, or if you are using third-party
-apps and don't want to store the migrations with the app.
-
-You simply need to set the new :ref:`setting-south-migration-modules` setting.