Docs tweaks (thanks timgraham)

import re

from .base import FIELD_TYPE

from django.utils.datastructures import SortedSet

from django.utils.datastructures import OrderedSet

from django.db.backends import BaseDatabaseIntrospection, FieldInfo

from django.utils.encoding import force_text

        for constraint, column, ref_table, ref_column in cursor.fetchall():

            if constraint not in constraints:

                constraints[constraint] = {

                    'columns': SortedSet(),

                    'columns': OrderedSet(),

                    'primary_key': False,

                    'unique': False,

                    'index': False,

        for table, non_unique, index, colseq, column in [x[:5] for x in cursor.fetchall()]:

            if index not in constraints:

                constraints[index] = {

                    'columns': SortedSet(),

                    'columns': OrderedSet(),

                    'primary_key': False,

                    'unique': False,

                    'index': True,

        """

        Returns a dict of migration plans which will achieve the

        change from from_state to to_state. The dict has app labels

        as kays and a list of migrations as values.

        as keys and a list of migrations as values.

        The resulting migrations aren't specially named, but the names

        do matter for dependencies inside the set.

from django.utils.datastructures import SortedSet

from django.utils.datastructures import OrderedSet

from django.db.migrations.state import ProjectState

    branch merges can be detected and resolved.

    Migrations files can be marked as replacing another set of migrations -

    this is to support the "squash" feature. The graph handler isn't resposible

    this is to support the "squash" feature. The graph handler isn't responsible

    for these; instead, the code to load them in here should examine the

    migration files and if the replaced migrations are all either unapplied

    or not present, it should ignore the replaced ones, load in just the

            for n in children:

                results = _dfs(n, get_children, path) + results

            path.pop()

            # Use SortedSet to ensure only one instance of each result

            results = list(SortedSet(results))

            # Use OrderedSet to ensure only one instance of each result

            results = list(OrderedSet(results))

            # Populate DP cache

            cache[(start, get_children)] = results

            # Done!

        super(SortedDict, self).clear()

        self.keyOrder = []

class SortedSet(object):

class OrderedSet(object):

    """

    A set which keeps the ordering of the inserted items.

    Currently backs onto OrderedDict.

.. django-admin:: makemigrations

.. versionadded:: 1.7

Creates new migrations based on the changes detected to your models.

Migrations, their relationship with apps and more are covered in depth in

:doc:`the migrations documentation</topics/migrations>`.

Providing one or more app names as arguments will limit the migrations created

to the app specified and any dependencies needed (the table at the other end

of a ForeignKey, for example)

to the app(s) specified and any dependencies needed (the table at the other end

of a ``ForeignKey``, for example).

.. django-admin-option:: --empty

The ``--empty`` option will cause ``makemigrations`` to output an empty

migration for the specified apps, for manual editing. This option is only

for advanced users and should not be used unless you are familiar with

the migration format, migration operations and the dependencies between

the migration format, migration operations, and the dependencies between

your migrations.

migrate [<appname> [<migrationname>]]

.. django-admin:: migrate

Synchronises the database state with the current set of models and migrations.

.. versionadded:: 1.7

Synchronizes the database state with the current set of models and migrations.

Migrations, their relationship with apps and more are covered in depth in

:doc:`the migrations documentation</topics/migrations>`.

The behaviour of this command changes depending on the arguments provided:

The behavior of this command changes depending on the arguments provided:

* No arguments: All migrated apps have all of their migrations run,

  and all unmigrated apps are synchronized with the database,