Skip to content
This repository

HTTPS clone URL

Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP
Browse code

Docs tweaks (thanks timgraham)

  • Loading branch information...
commit 7970d97a708f0d2f4fbd654eaf785338ab04cc1e 1 parent 3c3d308
Andrew Godwin authored
6  django/db/backends/mysql/introspection.py
... ...
@@ -1,6 +1,6 @@
1 1
 import re
2 2
 from .base import FIELD_TYPE
3  
-from django.utils.datastructures import SortedSet
  3
+from django.utils.datastructures import OrderedSet
4 4
 from django.db.backends import BaseDatabaseIntrospection, FieldInfo
5 5
 from django.utils.encoding import force_text
6 6
 
@@ -142,7 +142,7 @@ def get_constraints(self, cursor, table_name):
142 142
         for constraint, column, ref_table, ref_column in cursor.fetchall():
143 143
             if constraint not in constraints:
144 144
                 constraints[constraint] = {
145  
-                    'columns': SortedSet(),
  145
+                    'columns': OrderedSet(),
146 146
                     'primary_key': False,
147 147
                     'unique': False,
148 148
                     'index': False,
@@ -170,7 +170,7 @@ def get_constraints(self, cursor, table_name):
170 170
         for table, non_unique, index, colseq, column in [x[:5] for x in cursor.fetchall()]:
171 171
             if index not in constraints:
172 172
                 constraints[index] = {
173  
-                    'columns': SortedSet(),
  173
+                    'columns': OrderedSet(),
174 174
                     'primary_key': False,
175 175
                     'unique': False,
176 176
                     'index': True,
2  django/db/migrations/autodetector.py
@@ -29,7 +29,7 @@ def changes(self):
29 29
         """
30 30
         Returns a dict of migration plans which will achieve the
31 31
         change from from_state to to_state. The dict has app labels
32  
-        as kays and a list of migrations as values.
  32
+        as keys and a list of migrations as values.
33 33
 
34 34
         The resulting migrations aren't specially named, but the names
35 35
         do matter for dependencies inside the set.
8  django/db/migrations/graph.py
... ...
@@ -1,4 +1,4 @@
1  
-from django.utils.datastructures import SortedSet
  1
+from django.utils.datastructures import OrderedSet
2 2
 from django.db.migrations.state import ProjectState
3 3
 
4 4
 
@@ -13,7 +13,7 @@ class MigrationGraph(object):
13 13
     branch merges can be detected and resolved.
14 14
 
15 15
     Migrations files can be marked as replacing another set of migrations -
16  
-    this is to support the "squash" feature. The graph handler isn't resposible
  16
+    this is to support the "squash" feature. The graph handler isn't responsible
17 17
     for these; instead, the code to load them in here should examine the
18 18
     migration files and if the replaced migrations are all either unapplied
19 19
     or not present, it should ignore the replaced ones, load in just the
@@ -109,8 +109,8 @@ def _dfs(start, get_children, path):
109 109
             for n in children:
110 110
                 results = _dfs(n, get_children, path) + results
111 111
             path.pop()
112  
-            # Use SortedSet to ensure only one instance of each result
113  
-            results = list(SortedSet(results))
  112
+            # Use OrderedSet to ensure only one instance of each result
  113
+            results = list(OrderedSet(results))
114 114
             # Populate DP cache
115 115
             cache[(start, get_children)] = results
116 116
             # Done!
2  django/test/runner.py
@@ -267,7 +267,7 @@ def setup_databases(verbosity, interactive, **kwargs):
267 267
     # Second pass -- actually create the databases.
268 268
     old_names = []
269 269
     mirrors = []
270  
-    
  270
+
271 271
     for signature, (db_name, aliases) in dependency_ordered(
272 272
         test_databases.items(), dependencies):
273 273
         test_db_name = None
2  django/utils/datastructures.py
@@ -237,7 +237,7 @@ def clear(self):
237 237
         super(SortedDict, self).clear()
238 238
         self.keyOrder = []
239 239
 
240  
-class SortedSet(object):
  240
+class OrderedSet(object):
241 241
     """
242 242
     A set which keeps the ordering of the inserted items.
243 243
     Currently backs onto OrderedDict.
14  docs/ref/django-admin.txt
@@ -575,20 +575,22 @@ makemigrations [<appname>]
575 575
 
576 576
 .. django-admin:: makemigrations
577 577
 
  578
+.. versionadded:: 1.7
  579
+
578 580
 Creates new migrations based on the changes detected to your models.
579 581
 Migrations, their relationship with apps and more are covered in depth in
580 582
 :doc:`the migrations documentation</topics/migrations>`.
581 583
 
582 584
 Providing one or more app names as arguments will limit the migrations created
583  
-to the app specified and any dependencies needed (the table at the other end
584  
-of a ForeignKey, for example)
  585
+to the app(s) specified and any dependencies needed (the table at the other end
  586
+of a ``ForeignKey``, for example).
585 587
 
586 588
 .. django-admin-option:: --empty
587 589
 
588 590
 The ``--empty`` option will cause ``makemigrations`` to output an empty
589 591
 migration for the specified apps, for manual editing. This option is only
590 592
 for advanced users and should not be used unless you are familiar with
591  
-the migration format, migration operations and the dependencies between
  593
+the migration format, migration operations, and the dependencies between
592 594
 your migrations.
593 595
 
594 596
 migrate [<appname> [<migrationname>]]
@@ -596,11 +598,13 @@ migrate [<appname> [<migrationname>]]
596 598
 
597 599
 .. django-admin:: migrate
598 600
 
599  
-Synchronises the database state with the current set of models and migrations.
  601
+.. versionadded:: 1.7
  602
+
  603
+Synchronizes the database state with the current set of models and migrations.
600 604
 Migrations, their relationship with apps and more are covered in depth in
601 605
 :doc:`the migrations documentation</topics/migrations>`.
602 606
 
603  
-The behaviour of this command changes depending on the arguments provided:
  607
+The behavior of this command changes depending on the arguments provided:
604 608
 
605 609
 * No arguments: All migrated apps have all of their migrations run,
606 610
   and all unmigrated apps are synchronized with the database,
5  docs/ref/signals.txt
@@ -403,7 +403,6 @@ Arguments sent with this signal:
403 403
 ``db``
404 404
     The alias of database on which a command will operate.
405 405
 
406  
-
407 406
 pre_syncdb
408 407
 ----------
409 408
 
@@ -421,7 +420,6 @@ is present, for backwards-compatability this signal has an extra argument it sen
421 420
     A list of the model classes from any app which :djadmin:`migrate` is
422 421
     going to create, **only if the app has no migrations**.
423 422
 
424  
-
425 423
 post_migrate
426 424
 ------------
427 425
 
@@ -479,7 +477,6 @@ For example, ``yourapp/management/__init__.py`` could be written like::
479 477
 
480 478
     post_migrate.connect(my_callback, sender=yourapp.models)
481 479
 
482  
-
483 480
 post_syncdb
484 481
 -----------
485 482
 
@@ -497,8 +494,6 @@ is present, for backwards-compatability this signal has an extra argument it sen
497 494
     A list of the model classes from any app which :djadmin:`migrate` has
498 495
     created, **only if the app has no migrations**.
499 496
 
500  
-
501  
-
502 497
 Request/response signals
503 498
 ========================
504 499
 
18  docs/releases/1.7.txt
@@ -33,15 +33,16 @@ What's new in Django 1.7
33 33
 Schema migrations
34 34
 ~~~~~~~~~~~~~~~~~
35 35
 
36  
-Django now has built-in support for schema migrations, which allows models
37  
-to be updated, changed and deleted and the changes stored into migration files
38  
-and then run on any deployed database.
  36
+Django now has built-in support for schema migrations. It allows models
  37
+to be updated, changed, and deleted by creating migration files that represent
  38
+the model changes and which can be run on any development, staging or production
  39
+database.
39 40
 
40 41
 Migrations are covered in :doc:`their own documentation</topics/migrations>`,
41 42
 but a few of the key features are:
42 43
 
43 44
 * ``syncdb`` has been deprecated and replaced by ``migrate``. Don't worry - 
44  
-   calls to ``syncdb`` will still work as before.
  45
+  calls to ``syncdb`` will still work as before.
45 46
 
46 47
 * A new ``makemigrations`` command provides an easy way to autodetect changes
47 48
   to your models and make migrations for them.
@@ -60,7 +61,7 @@ but a few of the key features are:
60 61
 New method on Field subclasses
61 62
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
62 63
 
63  
-To help power both schema migrations and composite keys, the Field API now
  64
+To help power both schema migrations and composite keys, the :class:`~django.db.models.Field` API now
64 65
 has a new required method: ``deconstruct()``.
65 66
 
66 67
 This method takes no arguments, and returns a tuple of four items:
@@ -278,3 +279,10 @@ work until Django 1.9.
278 279
 it will go through a regular deprecation path. This attribute was mostly used
279 280
 by methods that bypassed ``ModelAdmin.get_fieldsets()`` but this was considered
280 281
 a bug and has been addressed.
  282
+
  283
+``syncdb``
  284
+~~~~~~~~~~
  285
+
  286
+The ``syncdb`` command has been deprecated in favour of the new ``migrate``
  287
+command. ``migrate`` takes the same arguments as ``syncdb`` used to plus a few
  288
+more, so it's safe to just change the name you're calling and nothing else.
12  docs/topics/migrations.txt
@@ -49,7 +49,7 @@ The migration files for each app live in a "migrations" directory inside
49 49
 of that app, and are designed to be committed to, and distributed as part
50 50
 of, its codebase. You should be making them once on your development machine
51 51
 and then running the same migrations on your colleagues' machines, your
52  
-staging machines and eventually your production machines.
  52
+staging machines, and eventually your production machines.
53 53
 
54 54
 Migrations will run the same way every time and produce consistent results,
55 55
 meaning that what you see in development and staging is exactly what will
@@ -60,7 +60,7 @@ Backend Support
60 60
 
61 61
 Migrations are supported on all backends that Django ships with, as well
62 62
 as any third-party backends if they have programmed in support for schema
63  
-alteration (done via the SchemaEditor class).
  63
+alteration (done via the ``SchemaEditor`` class).
64 64
 
65 65
 However, some databases are more capable than others when it comes to
66 66
 schema migrations; some of the caveats are covered below.
@@ -169,7 +169,7 @@ app - in the file, so it's possible to detect when there's two new migrations
169 169
 for the same app that aren't ordered.
170 170
 
171 171
 When this happens, Django will prompt you and give you some options. If it
172  
-thinks it's safe enough, it will offer to automatically linearise the two
  172
+thinks it's safe enough, it will offer to automatically linearize the two
173 173
 migrations for you. If not, you'll have to go in and modify the migrations
174 174
 yourself - don't worry, this isn't difficult, and is explained more in
175 175
 :ref:`migration-files` below.
@@ -184,8 +184,8 @@ you add a ForeignKey in your ``books`` app to your ``authors`` app - the
184 184
 resulting migration will contain a dependency on a migration in ``authors``.
185 185
 
186 186
 This means that when you run the migrations, the ``authors`` migration runs
187  
-first and creates the table the ForeignKey references, and then the migration
188  
-that makes the ForeignKey column runs afterwards and creates the constraint.
  187
+first and creates the table the ``ForeignKey`` references, and then the migration
  188
+that makes the ``ForeignKey`` column runs afterwards and creates the constraint.
189 189
 If this didn't happen, the migration would try to create the ForeignKey column
190 190
 without the table it's referencing existing and your database would
191 191
 throw an error.
@@ -271,7 +271,7 @@ Note that this only works given two things:
271 271
 
272 272
 * You have not manually edited your database - Django won't be able to detect
273 273
   that your database doesn't match your models, you'll just get errors when
274  
-  migrations try and modify those tables.
  274
+  migrations try to modify those tables.
275 275
 
276 276
 
277 277
 .. historical-models:

0 notes on commit 7970d97

Please sign in to comment.
Something went wrong with that request. Please try again.