Skip to content
This repository

HTTPS clone URL

Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP
Browse code

Fixed #13739 -- Updated release notes to make a note of the changes t…

…o Field.db_type.

git-svn-id: http://code.djangoproject.com/svn/django/trunk@13350 bcc190cf-cafb-0310-a4f2-bffc1f526a37
  • Loading branch information...
commit ab908685fb7dea7395eb52a6eff02af04e12991e 1 parent 2597f31
Russell Keith-Magee authored June 11, 2010

Showing 1 changed file with 19 additions and 14 deletions. Show diff stats Hide diff stats

  1. 33  docs/releases/1.2.txt
33  docs/releases/1.2.txt
@@ -21,11 +21,11 @@ Overview
21 21
 Django 1.2 introduces several large, important new features, including:
22 22
 
23 23
     * Support for `multiple database connections`_ in a single Django instance.
24  
-    
  24
+
25 25
     * `Model validation`_ inspired by Django's form validation.
26  
-    
  26
+
27 27
     * Vastly `improved protection against Cross-Site Request Forgery`_ (CSRF).
28  
-    
  28
+
29 29
     * A new `user "messages" framework`_ with support for cookie- and session-based
30 30
       message for both anonymous and authenticated users.
31 31
 
@@ -49,9 +49,9 @@ be found below`_.
49 49
 
50 50
 .. seealso::
51 51
 
52  
-    `Django Advent`_ covered the release of Django 1.2 with a series of 
  52
+    `Django Advent`_ covered the release of Django 1.2 with a series of
53 53
     articles and tutorials that cover some of the new features in depth.
54  
-        
  54
+
55 55
 .. _django advent: http://djangoadvent.com/
56 56
 
57 57
 Wherever possible these features have been introduced in a backwards-compatible
@@ -66,7 +66,7 @@ backwards-incompatible. The big changes are:
66 66
     * The new CSRF protection framework is not backwards-compatible with
67 67
       the old system. Users of the old system will not be affected until
68 68
       the old system is removed in Django 1.4.
69  
-      
  69
+
70 70
       However, upgrading to the new CSRF protection framework requires a few
71 71
       important backwards-incompatible changes, detailed in `CSRF Protection`_,
72 72
       below.
@@ -74,12 +74,12 @@ backwards-incompatible. The big changes are:
74 74
     * Authors of custom :class:`~django.db.models.Field` subclasses should be
75 75
       aware that a number of methods have had a change in prototype, detailed
76 76
       under `get_db_prep_*() methods on Field`_, below.
77  
-      
  77
+
78 78
     * The internals of template tags have changed somewhat; authors of custom
79 79
       template tags that need to store state (e.g. custom control flow tags)
80 80
       should ensure that their code follows the new rules for `stateful template
81 81
       tags`_
82  
-    
  82
+
83 83
     * The :func:`~django.contrib.auth.decorators.user_passes_test`,
84 84
       :func:`~django.contrib.auth.decorators.login_required`, and
85 85
       :func:`~django.contrib.auth.decorators.permission_required`, decorators
@@ -435,6 +435,8 @@ database-compatible values. A custom field might look something like::
435 435
 
436 436
     class CustomModelField(models.Field):
437 437
         # ...
  438
+        def db_type(self):
  439
+            # ...
438 440
 
439 441
         def get_db_prep_save(self, value):
440 442
             # ...
@@ -451,6 +453,9 @@ two extra methods have been introduced::
451 453
     class CustomModelField(models.Field):
452 454
         # ...
453 455
 
  456
+        def db_type(self, connection):
  457
+            # ...
  458
+
454 459
         def get_prep_value(self, value):
455 460
             # ...
456 461
 
@@ -467,10 +472,10 @@ two extra methods have been introduced::
467 472
             # ...
468 473
 
469 474
 These changes are required to support multiple databases --
470  
-``get_db_prep_*`` can no longer make any assumptions regarding the
471  
-database for which it is preparing. The ``connection`` argument now
472  
-provides the preparation methods with the specific connection for
473  
-which the value is being prepared.
  475
+``db_type`` and ``get_db_prep_*`` can no longer make any assumptions
  476
+regarding the database for which it is preparing. The ``connection``
  477
+argument now provides the preparation methods with the specific
  478
+connection for which the value is being prepared.
474 479
 
475 480
 The two new methods exist to differentiate general data-preparation
476 481
 requirements from requirements that are database-specific. The
@@ -603,13 +608,13 @@ new keyword and so is not a valid variable name in this tag.
603 608
 --------------
604 609
 
605 610
 ``LazyObject`` is an undocumented-but-often-used utility class used for lazily
606  
-wrapping other objects of unknown type. 
  611
+wrapping other objects of unknown type.
607 612
 
608 613
 In Django 1.1 and earlier, it handled introspection in a non-standard way,
609 614
 depending on wrapped objects implementing a public method named
610 615
 ``get_all_members()``. Since this could easily lead to name clashes, it has been
611 616
 changed to use the standard Python introspection method, involving
612  
-``__members__`` and ``__dir__()``. 
  617
+``__members__`` and ``__dir__()``.
613 618
 
614 619
 If you used ``LazyObject`` in your own code
615 620
 and implemented the ``get_all_members()`` method for wrapped objects, you'll need

0 notes on commit ab90868

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