2010年5月17日。
欢迎来到Django 1.2！
近一年的制作过程中，Django1.2推出了令人印象深刻的 new features 还有很多错误修复。这些发行说明涵盖了新功能，以及从django 1.1或旧版本升级时需要注意的重要更改。
Django 1.2引入了几个重要的新功能，包括：
支持 multiple database connections 在一个Django实例中。
Model validation 灵感来自Django的表单验证。
大大地 improved protection against Cross-Site Request Forgery (CSRF)。
一种新的 user "messages" framework 支持匿名和经过身份验证的用户的基于Cookie和会话的消息。
用于的挂钩 object-level permissions ， permissions for anonymous users ，以及 more flexible username requirements 。
定制电子邮件发送方式 email backends .
新的 "smart" if template tag 它支持比较运算符。
这些只是亮点；完整的细节和完整的功能列表 may be found below 。
参见
Django Advent 在django 1.2的发行版中，有一系列文章和教程深入介绍了一些新特性。
在可能的情况下，根据 our API stability policy 政策。
但是，一些特性 have 改变的方式，对某些用户来说，将是向后不兼容的。巨大的变化是：
对python 2.3的支持已被放弃。请参阅下面的完整注释。
新的CSRF保护框架与旧系统不向后兼容。在Django 1.4中删除旧系统之前，旧系统的用户不会受到影响。
但是，升级到新的CSRF保护框架需要一些重要的向后不兼容的更改，详情请参见 CSRF Protection ，在下面。
自定义作者 Field 子类应该知道，很多方法在原型方面都有了变化，详情如下 get_db_prep_*() methods on Field ，在下面。
模板标记的内部已经发生了一些变化；需要存储状态的自定义模板标记（例如自定义控制流标记）的作者应该确保其代码遵循 stateful template tags
这个 user_passes_test() ， login_required() ，以及 permission_required() ，装饰师来自 django.contrib.auth 仅适用于函数，不再处理方法。有一个简单的单行解决方案 detailed below 。
同样，这些只是影响大多数用户的主要功能。强烈建议从以前版本的django升级的用户查阅 backwards-incompatible changes 和名单 deprecated features .
虽然这不是一个新特性，但必须注意的是，Django1.2引入了自Django首次公开亮相以来我们的Python兼容性策略的第一个转变。以前的django版本是在2.3以上的2.x Python版本上测试和支持的；但是django 1.2放弃了对python 2.3的官方支持。因此，Django所需的最低python版本现在是2.4，并且在python 2.4、2.5和2.6上测试和支持Django，并且将在尚未发布的python 2.7上得到支持。
这种更改只会影响少数Django用户，因为目前大多数操作系统供应商都将python 2.4或更新版本作为其默认版本。但是，如果您仍在使用python 2.3，则需要一直使用django 1.1，直到可以升级；per our support policy ，django 1.1将继续获得安全支持，直到django 1.3发布。
Django对2.x python的总体支持以及最终过渡到python 3.x的路线图目前正在开发中，并将在Django1.3发布之前公布。
Django 1.2增加了使用能力 more than one database 在你的Django项目中。可以使用 using() 方法对 QuerySet 对象。通过提供 using 你调用时的争吵 save() .
模型实例现在支持 validating their own data ，模型和表单字段现在都接受可配置的 validators 指定可重用的封装验证行为。但是，请注意，验证仍然必须显式地执行。只需调用模型实例的 save() 方法不会对实例的数据执行任何验证。
Django现在对 Cross-Site Request Forgery (CSRF) attacks . 当恶意网站包含一个链接、一个表单按钮或一些javascript，打算使用登录用户在浏览器中访问恶意网站的凭据在您的网站上执行某些操作时，就会发生这种攻击。一种相关类型的攻击，“登录CSRF”，攻击站点诱使用户的浏览器使用其他人的证书登录站点，也包括在内。
Django现在包括一个健壮的和可配置的 messages framework 内置了对基于cookie和会话的消息传递的支持，支持匿名和经过身份验证的客户机。消息框架替换了不推荐使用的用户消息API，并允许您在一个请求中临时存储消息，并检索它们以在随后的请求（通常是下一个请求）中显示。
添加了在每个对象级别指定权限的基础。虽然在核心中没有实现此功能，但是自定义身份验证后端可以提供此功能，并且将由 django.contrib.auth.models.User . 见 authentication docs 更多信息。
如果提供一个自定义身份验证后端 supports_anonymous_user 设置为 True ，AnonymousUser将检查后端的权限，就像用户已经检查过的一样。这对于集中权限处理很有用-应用程序总是可以将某些内容是否被允许的问题委托给授权/身份验证后端。见 authentication docs 了解更多详细信息。
现在你可以 configure the way that Django sends email . 现在，您可以选择一个可配置的电子邮件后端来发送邮件，而不是使用SMTP发送所有电子邮件。如果您的主机提供商使用沙盒或其他非SMTP技术发送邮件，您现在可以构建一个电子邮件后端，允许Django的标准 mail sending methods 使用这些设施。
这也使得调试邮件发送更加容易。Django提供后端实现，允许您将电子邮件发送到 file ，到 console ，或 memory . 您甚至可以将所有电子邮件配置为 thrown away .
if 标签¶这个 if 标签已经升级为更强大的功能。首先，我们增加了对比较运算符的支持。不再需要输入：
{% ifnotequal a b %}
...
{% endifnotequal %}
现在可以这样做：
{% if a != b %}
...
{% endif %}
真的没有理由使用 {{% ifequal %}} 或 {{% ifnotequal %}} 除非你是怀旧型的。
支持的运算符有 == ， != ， < ， > ， <= ， >= ， in 和 not in 除了 and ， or 和 not ，已受支持。
此外，过滤器现在可以用于 if 表达式。例如：
<div
{% if user.email|lower == message.recipient|lower %}
class="highlight"
{% endif %}
>{{ message }}</div>
在Django的早期版本中，每次呈现模板时，都会从磁盘重新加载模板。在Django 1.2中，可以使用 cached template loader 要加载一次模板，然后缓存每个后续渲染的结果。如果将模板分成许多较小的子模板（使用 {{% extends %}} 或 {{% include %}} 标签）。
作为副作用，现在支持非Django模板语言要容易得多。
作为引入 Template caching 按照Django的一般趋势，模板加载器API被修改为使用封装在Python类中的模板加载机制，而不是函数，这是Django1.1之前唯一可用的方法。
所有模板加载程序 shipped with Django 已经移植到新的API，但它们仍然实现基于函数的API，模板核心机器仍然接受基于函数的加载程序（内置或第三方），因此不需要立即修改 TEMPLATE_LOADERS 设置在现有的项目中，如果您不动它，包括django 1.3版本，事情将继续工作。
如果您已经开发了自己的自定义模板加载器，我们建议考虑将它们移植到基于类的实现中，因为与基于函数的加载器向后兼容的代码将在Django 1.2中启动其取消预测过程，并将在Django 1.4中删除。这些加载程序类必须在模板API引用中实现的API有一个描述，您还可以检查Django附带的加载程序的源代码。
设备现在可以引用远程对象 自然键 . 这种查找方案是夹具中基于主键的对象引用的一种替代方案，可以提高可读性，并解决涉及主键值可能无法预测或已知的对象的问题。
两个 test 子命令 django-admin.py 以及 runtests.py 用于运行Django自己的测试套件的脚本现在支持 --failfast 选择权。如果指定了此选项，则此选项将导致测试运行程序在遇到故障后退出，而不是继续测试运行。此外，处理 Ctrl-C 在测试运行期间，已改进以触发从测试运行中优雅退出，该测试运行报告了中断前运行的测试的详细信息。
BigIntegerField¶模型现在可以使用64位 BigIntegerField 类型。
贾戈 internationalization framework 已使用支持区域设置的格式和表单处理进行扩展。这意味着，如果启用，模板上的日期和数字将使用为当前区域设置指定的格式显示。Django在分析表单中的数据时也将使用本地化格式。见 格式本地化 了解更多详细信息。
readonly_fields in ModelAdmin¶django.contrib.admin.ModelAdmin.readonly_fields 已添加以启用模型和内联的“添加/更改”页中的不可编辑字段。字段和计算值可以与可编辑字段一起显示。
您现在可以使用 DJANGO_COLORS 用于修改或禁用使用的颜色的环境变量 django-admin.py 提供 syntax highlighting 。
最重要的新功能 GeoDjango 在1.2中是对多个空间数据库的支持。因此，以下内容 spatial database backends 现在包括：
django.contrib.gis.db.backends.postgis
django.contrib.gis.db.backends.mysql
django.contrib.gis.db.backends.oracle
django.contrib.gis.db.backends.spatialite
geodjango现在支持Postgis1.5版本中添加的丰富功能。新功能包括支持 geography type 使能 distance queries 地理坐标系上的非点几何图形。
添加了对三维几何图形字段的支持，可以通过设置 dim 关键字为3 GeometryField . 这个 Extent3D 骨料和 extent3d() GeoQuerySet 方法已作为此功能的一部分添加。
这个 force_rhr() ， reverse_geom() 和 geohash() GeoQuerySet 方法是新的。
当平台上可用时，更新geos接口以使用线程安全的C库函数。
gdal接口现在允许用户设置 spatial_filter 在迭代 Layer .
最后， GeoDjango's documentation 现在包含在Django中，不再单独托管在 geodjango.org 。
now 模板标记格式说明符字符： c 和 u¶关于 now 获得了两个新的格式字符： c 指定日期时间值应采用ISO 8601格式，以及 u 它允许输出日期时间或时间值的微秒部分。
这些也可以在其他部分使用，如 date 和 time 模板过滤器 humanize 模板标记库和新的 format localization 框架。
尽可能以向后兼容的方式根据 our API stability policy 政策。这意味着几乎所有与django 1.1一起工作的现有代码都将继续与django 1.2一起工作；但是，这些代码将开始发出警告（有关详细信息，请参见下文）。
但是，一些特性 have 改变的方式，对某些用户来说，将立即向后不兼容。下面详细介绍这些更改。
我们对CSRF保护的工作方式做了很大的改变，详情见 the CSRF documentation . 以下是您应该注意的主要变化：
CsrfResponseMiddleware 和 CsrfMiddleware 已弃用，将在django 1.4中完全删除，以支持应插入表单的模板标记。
所有控件应用程序都使用 csrf_protect 装饰师保护风景。这需要使用 csrf_token 模板中的模板标记。如果已经为contrib视图使用了自定义模板，则必须阅读升级说明来修复这些模板。
文件已删除
升级说明已在当前的Django文档中删除。请参阅Django 1.3或更高版本的文档以查找这些说明。
CsrfViewMiddleware 包含在 MIDDLEWARE_CLASSES 默认情况下。这将在默认情况下启用CSRF保护，因此需要编写接受POST请求的视图来使用中间件。有关如何执行此操作的说明，请参阅CSRF文档。
所有CSRF都已从contrib转移到了core（旧位置的向后兼容导入，已弃用，将不再在django 1.4中受支持）。
get_db_prep_*() methods on Field¶在Django 1.2之前，自定义 Field 可以选择定义几个函数来支持将python值转换为与数据库兼容的值。自定义字段可能类似于：
class CustomModelField(models.Field):
...
def db_type(self): ...
def get_db_prep_save(self, value): ...
def get_db_prep_value(self, value): ...
def get_db_prep_lookup(self, lookup_type, value): ...
在1.2中，这三种方法的原型发生了变化，并引入了另外两种方法：
class CustomModelField(models.Field):
...
def db_type(self, connection): ...
def get_prep_value(self, value): ...
def get_prep_lookup(self, lookup_type, value): ...
def get_db_prep_save(self, value, connection): ...
def get_db_prep_value(self, value, connection, prepared=False): ...
def get_db_prep_lookup(self, lookup_type, value, connection, prepared=False): ...
这些更改是支持多个数据库所必需的-- db_type 和 get_db_prep_* 无法再对其正在准备的数据库进行任何假设。这个 connection 参数现在为准备方法提供了准备值的特定连接。
存在两种新的方法来区分一般的数据准备需求和特定于数据库的需求。这个 prepared 参数用于向数据库准备方法指示是否已执行泛型值准备。如果未准备好（即， prepared=False ）值提供给 get_db_prep_*() 调用，它们应该调用相应的 get_prep_*() 调用以执行通用数据准备。
我们提供了转换函数，可以透明地将依附于旧原型的函数转换为与新原型兼容的函数。但是，这些转换函数将在django 1.4中删除，因此您应该升级 Field 定义尽快使用新原型。
如果你 get_db_prep_*() 方法没有使用数据库连接，应该可以通过重命名来升级 get_db_prep_value() 到 get_prep_value() 和 get_db_prep_lookup() 到 get_prep_lookup() . 如果需要特定于数据库的转换，则需要提供一个实现 get_db_prep_* 使用 connection 用于解析数据库特定值的参数。
user_passes_test, login_required and permission_required¶django.contrib.auth.decorators 提供装饰 login_required ， permission_required 和 user_passes_test . 以前，可以在函数（其中第一个参数是“request”）和方法（其中第一个参数是“self”，第二个参数是“request”）上使用这些修饰符。不幸的是，在支持这一点的代码中发现了缺陷：它只在有限的情况下工作，并且在不工作时产生非常难以调试的错误。
因此，“自动适应”行为已被移除，如果您在方法上使用这些修饰符，则需要手动应用 django.utils.decorators.method_decorator() 将修饰符转换为使用方法的修饰符。例如，您可以从此处更改代码：
class MyClass(object):
@login_required
def my_view(self, request):
pass
对此：
from django.utils.decorators import method_decorator
class MyClass(object):
@method_decorator(login_required)
def my_view(self, request):
pass
或：
from django.utils.decorators import method_decorator
login_required_m = method_decorator(login_required)
class MyClass(object):
@login_required_m
def my_view(self, request):
pass
对于那些一直关注开发主干的人来说，这个更改也适用于1.1之后引入的其他修饰符，包括 csrf_protect ， cache_control 以及任何使用 decorator_from_middleware .
if 标签更改¶由于中的新功能 if 模板标记，它不再接受“and”、“or”和“not”作为有效标记 变量 名字。以前，这些字符串可以用作变量名。现在，关键字状态始终是强制的，模板代码如 {{% if not %}} 或 {{% if and %}} 会扔 TemplateSyntaxError . 也， in 是新关键字，因此不是此标记中的有效变量名。
LazyObject¶LazyObject 是一个未记录但经常使用的实用程序类，用于延迟包装其他未知类型的对象。
在Django1.1和更早的版本中，它以非标准方式处理自省，这取决于被包装的对象实现名为 get_all_members() . 由于这很容易导致名称冲突，因此已将其更改为使用标准的python自省方法，包括 __members__ 和 __dir__() .
如果你用过 LazyObject 在您自己的代码中并实现 get_all_members() 方法对于包装的对象，需要进行以下几项更改：
首先，如果您的类没有对自省的特殊要求（即，您没有实现 __getattr__() 或者其他允许普通机制无法发现的属性的方法），您可以简单地删除 get_all_members() 方法。上的默认实现 LazyObject 会做正确的事。
如果您对内省有更复杂的要求，请首先重命名 get_all_members() 方法到 __dir__() . 这是Python2.6及更高版本的标准自省方法。如果需要对2.6之前的Python版本的支持，请向类中添加以下代码：
__members__ = property(lambda self: self.__dir__())
__dict__ 在模型实例上¶历史上， __dict__ 模型实例的属性只包含与模型上的字段对应的属性。
为了支持多个数据库配置，Django1.2添加了一个 _state 属性到对象实例。此属性将出现在 __dict__ 对于模型实例。如果代码依赖于迭代 __dict__ 要获取字段列表，现在必须准备处理或筛选 _state 属性。
测试运行者的退出状态代码 (tests/runtests.py 和 python manage.py test ）不再表示失败的测试数，因为256个或更多测试的失败导致错误的退出状态代码。测试运行程序的退出状态代码现在为0表示成功（没有失败的测试），1表示任意数量的测试失败。如果需要，可以在测试运行程序输出的末尾找到测试失败的次数。
ModelForm.is_valid() and ModelForm.errors¶模型表单的大部分验证工作都已向下移动到模型级别。结果，你第一次调用 ModelForm.is_valid() 访问 ModelForm.errors 或者触发表单验证，您的模型将被就地清除。此转换通常在保存模型时发生。如果需要模型的未修改实例，则应将副本传递给 ModelForm 建造师。
BooleanField 关于MySQL¶在Django的早期版本中，一个模型的 BooleanField 在mysql下，它的值返回为 1 或 0 ，而不是 True 或 False 对于大多数人来说，这不是问题，因为 bool 是的子类 int 在 Python 中。然而，在Django 1.2中， BooleanField 在mysql上正确返回 bool . 唯一一次这应该是一个问题是如果你正在期待 repr A的 BooleanField 印刷 1 或 0 .
max_num 在FormSets¶作为对表单集处理、默认值和 max_num 参数 django.forms.formsets.formset_factory() 和 django.forms.models.modelformset_factory() 功能略有变化。这种变化也会影响 max_num 参数用于内联管理对象。
以前，默认值为 max_num 是 0 （零）。然后使用的布尔值 max_num 确定是否对生成的表单数量施加限制。默认值为 0 这意味着表单集中的表单数量没有默认限制。
从1.2开始，默认值为 max_num 已更改为 None 和Formset将区分 None 和一个值 0 . 一个值 None 表示不限制表格数量；值为 0 指示最多应强制使用0个窗体。这并不一定意味着将不显示任何窗体--请参见 ModelFormSet documentation 了解更多详细信息。
如果手动指定的值为 0 对于 max_num ，您需要更新表单集和/或管理定义。
email_re¶用于验证电子邮件地址的未记录正则表达式已从 django.form.fields 到 django.core.validators . 如果正在使用导入，则需要更新导入。
最后，Django1.2否决了早期版本的一些特性。这些特性仍然受到支持，但将在接下来的几个发布周期中逐步淘汰。
利用以下任何功能的代码将引发 PendingDeprecationWarning 在Django 1.2。默认情况下，此警告将保持沉默，但可以使用python的 warnings 模块，或者使用 -Wd 或 -Wall 标识。
在Django 1.3中，这些警告将成为 DeprecationWarning ，这就是 not 沉默。在Django 1.4中，对这些功能的支持将被完全删除。
参见
有关详细信息，请参阅文档 Django's release process 以及我们的 deprecation timeline .`
在django 1.2之前，django使用了许多设置来控制对单个数据库的访问。Django1.2引入了对多个数据库的支持，因此您定义数据库设置的方式发生了变化。
任何现有的django设置文件将继续按预期工作，直到django 1.4。在此之前，旧样式的数据库设置将自动转换为新样式的格式。
在旧样式（1.2之前版本）格式中，您有许多 DATABASE_ 设置文件中的设置。例如：：
DATABASE_NAME = "test_db"
DATABASE_ENGINE = "postgresql_psycopg2"
DATABASE_USER = "myusername"
DATABASE_PASSWORD = "s3krit"
这些设置现在位于名为 DATABASES . 字典中的每个项都对应于一个数据库连接，名称为 'default' 描述默认数据库连接。设置名称也被缩短了。以前的示例设置现在如下所示：
DATABASES = {
"default": {
"NAME": "test_db",
"ENGINE": "django.db.backends.postgresql_psycopg2",
"USER": "myusername",
"PASSWORD": "s3krit",
}
}
这会影响以下设置：
旧设置 |
新设置 |
|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
如果您已使用 DatabaseWrapper() 从您选择的数据库后端。
除了结构上的变化，Django1.2还删除了对内置数据库后端的特殊处理。所有数据库后端现在必须由完全限定的模块名（即， django.db.backends.postgresql_psycopg2 而不仅仅是 postgresql_psycopg2 ）
postgresql 数据库后端¶这个 psycopg1 类库自2005年10月起未更新。因此， postgresql 使用此库的数据库后端已被弃用。
如果您当前正在使用 postgresql 后端，您应该使用 postgresql_psycopg2 后端。要更新代码，请安装 psycopg2 类库和改变 ENGINE 设置使用 django.db.backends.postgresql_psycopg2 .
CsrfResponseMiddleware ，自动将CSRF令牌插入 POST 传出页中的表单已被弃用，取而代之的是模板标记方法（见上文），将在Django 1.4中完全删除。 CsrfMiddleware ，其中包括 CsrfResponseMiddleware 和 CsrfViewMiddleware ，同样被否决。
此外，CSRF模块已经从contrib移到了core，旧的导入被弃用，如升级说明中所述。
文件已删除
升级说明已在当前的Django文档中删除。请参阅Django 1.3或更高版本的文档以查找这些说明。
SMTPConnection¶这个 SMTPConnection 类已被弃用，取而代之的是通用电子邮件后端API。显式实例化smtpconnection实例的旧代码：
from django.core.mail import SMTPConnection
connection = SMTPConnection()
messages = get_notification_email()
connection.send_messages(messages)
…现在应该调用 get_connection() 要实例化通用电子邮件连接，请执行以下操作：
from django.core.mail import get_connection
connection = get_connection()
messages = get_notification_email()
connection.send_messages(messages)
取决于 EMAIL_BACKEND 设置，这可能不会返回SMTP连接。如果显式要求与之建立SMTP连接以发送电子邮件，则可以显式请求SMTP连接：：
from django.core.mail import get_connection
connection = get_connection("django.core.mail.backends.smtp.EmailBackend")
messages = get_notification_email()
connection.send_messages(messages)
如果调用构造的实例 SMTPConnection 需要其他参数，这些参数可以传递给 get_connection() 调用：
connection = get_connection(
"django.core.mail.backends.smtp.EmailBackend", hostname="localhost", port=1234
)
用于在用户中存储消息的API Message 模型（通过） user.message_set.create ）现已弃用，将根据标准在Django 1.4中删除。 release process .
要升级代码，您需要替换此的任何实例：
user.message_set.create("a message")
…包括以下内容：
from django.contrib import messages
messages.add_message(request, messages.INFO, "a message")
此外，如果使用该方法，则需要替换以下内容：
for message in user.get_and_delete_messages():
...
……：：
from django.contrib import messages
for message in messages.get_messages(request):
...
有关详细信息，请参阅完整的 messages documentation . 您应该开始更新代码以立即使用新的API。
django.utils.translation.get_date_formats() 和 django.utils.translation.get_partial_date_formats() 已被弃用，转而支持对 django.utils.formats.get_format() ，它在以下情况下是区域感知的 USE_L10N 设置为 True ，如果设置为，则回退到默认设置 False 。
要获取不同的日期格式，而不是编写以下内容：
from django.utils.translation import get_date_formats
date_format, datetime_format, time_format = get_date_formats()
使用方法：
from django.utils import formats
date_format = formats.get_format("DATE_FORMAT")
datetime_format = formats.get_format("DATETIME_FORMAT")
time_format = formats.get_format("TIME_FORMAT")
或者，直接格式化日期值时：
from django.utils import formats
value_formatted = formats.date_format(value, "DATETIME_FORMAT")
这同样适用于 django.forms.fields ：
DEFAULT_DATE_INPUT_FORMATS
DEFAULT_TIME_INPUT_FORMATS
DEFAULT_DATETIME_INPUT_FORMATS
使用 django.utils.formats.get_format() 以获得适当的格式。
Django1.2更改测试运行程序工具以使用基于类的方法。旧的基于函数的测试运行程序仍然可以运行，但是应该更新以使用新的 class-based runners .
在1.1版之前，Django使用技术消息ID为定位器提供转换日期和时间格式的可能性。它们是可翻译的 translation strings 因为它们都是大写的（例如 DATETIME_FORMAT ， DATE_FORMAT ， TIME_FORMAT ）为了支持新的 格式本地化 允许定位器在 formats.py 文件在相应的 django/conf/locale/<locale name>/ 目录。
为了支持多个数据库，对geodjango数据库内部进行了实质性的更改。最大的向后不兼容变化是模块 django.contrib.gis.db.backend 重命名为 django.contrib.gis.db.backends 在那里，羽毛球 spatial database backends 现在存在。以下部分提供了受这些更改影响的最流行的API的信息。
SpatialBackend¶在创建单独的空间后端之前， django.contrib.gis.db.backend.SpatialBackend 对象被提供为一个抽象，用于对空间数据库的功能进行自省。由提供的所有属性和例程 SpatialBackend 现在是 ops 数据库后端的属性。
旧模块 django.contrib.gis.db.backend 仍然提供向后兼容性访问 SpatialBackend 对象，它只是 ops 模块 违约 空间数据库连接。
依赖于中未记录的模块和对象的用户 django.contrib.gis.db.backend 而是由 SpatialBackend ，需要修改其代码。例如，以下导入将在1.1及以下版本中工作：
from django.contrib.gis.db.backend.postgis import PostGISAdaptor
需要更改：
from django.db import connection
PostGISAdaptor = connection.ops.Adapter
SpatialRefSys 和 GeometryColumns 模型¶在先前版本的geodjango中， django.contrib.gis.db.models 有 SpatialRefSys 和 GeometryColumns 查询OGC空间元数据表的模型 spatial_ref_sys 和 geometry_columns ，分别。
虽然仍提供这些别名，但它们仅用于 违约 只有在默认连接使用支持的空间数据库后端时才存在数据库连接。
备注
由于不同空间数据库的OGC空间元数据表的表结构不同，因此 SpatialRefSys 和 GeometryColumns 模型不能再与 gis 应用程序名称。因此，在使用 get_models 下面的示例中的方法：
>>> from django.db.models import get_app, get_models
>>> get_models(get_app("gis"))
[]
为了获得正确的 SpatialRefSys 和 GeometryColumns 对于您的空间数据库，使用空间后端提供的方法：
>>> from django.db import connections >>> SpatialRefSys = connections["my_spatialite"].ops.spatial_ref_sys() >>> GeometryColumns = connections["my_postgis"].ops.geometry_columns()
备注
当使用从返回的模型时， spatial_ref_sys() 和 geometry_columns() 方法，在查询非默认连接时仍然需要使用正确的数据库别名。换句话说，为了确保上面示例中的模型使用正确的数据库：
sr_qs = SpatialRefSys.objects.using("my_spatialite").filter(...)
gc_qs = GeometryColumns.objects.using("my_postgis").filter(...)
no¶挪威博克马尔语目前使用的语言代码 no 正在被更常见的语言代码替换 nb .
Django1.2将模板加载机制更改为使用基于类的方法。旧样式的基于函数的模板加载器仍然可以工作，但是应该更新以使用新的基于类的模板加载器。
7月 22, 2024