mirror of
https://github.com/django/django.git
synced 2025-08-03 10:34:04 +00:00
Edited stuff from [17543] to [17629]
git-svn-id: http://code.djangoproject.com/svn/django/trunk@17630 bcc190cf-cafb-0310-a4f2-bffc1f526a37
This commit is contained in:
parent
3ed0b6ed64
commit
2ade1e916f
16 changed files with 100 additions and 101 deletions
|
@ -155,13 +155,13 @@ MySQL has several `storage engines`_ (previously called table types). You can
|
|||
change the default storage engine in the server configuration.
|
||||
|
||||
Until MySQL 5.5.4, the default engine was MyISAM_ [#]_. The main drawbacks of
|
||||
MyISAM are that it doesn't support transactions or enforce foreign keys
|
||||
MyISAM are that it doesn't support transactions or enforce foreign-key
|
||||
constraints. On the plus side, it's currently the only engine that supports
|
||||
full-text indexing and searching.
|
||||
|
||||
Since MySQL 5.5.5, the default storage engine is InnoDB_. This engine is fully
|
||||
transactional and supports foreign key references. It's probably the best
|
||||
choice at this point in time.
|
||||
choice at this point.
|
||||
|
||||
.. versionchanged:: 1.4
|
||||
|
||||
|
|
|
@ -379,8 +379,8 @@ installation will be aborted, and any data installed in the call to
|
|||
.. admonition:: MySQL with MyISAM and fixtures
|
||||
|
||||
The MyISAM storage engine of MySQL doesn't support transactions or
|
||||
constraints, so you won't get a rollback if multiple transaction files are
|
||||
found, or validation of fixture data, if you use MyISAM tables.
|
||||
constraints, so if you use MyISAM, you won't get validation of fixture
|
||||
data, or a rollback if multiple transaction files are found.
|
||||
|
||||
Database-specific fixtures
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
|
|
@ -228,8 +228,8 @@ Methods
|
|||
parts = request.META[field].split(',')
|
||||
request.META[field] = parts[-1].strip()
|
||||
|
||||
This middleware should be positionned before any other middleware that
|
||||
relies on the value of :meth:`~HttpRequest.get_host()`, for instance
|
||||
This middleware should be positioned before any other middleware that
|
||||
relies on the value of :meth:`~HttpRequest.get_host()` -- for instance,
|
||||
:class:`~django.middleware.common.CommonMiddleware` or
|
||||
:class:`~django.middleware.csrf.CsrfViewMiddleware`.
|
||||
|
||||
|
|
|
@ -9,9 +9,9 @@ Settings
|
|||
.. warning::
|
||||
|
||||
Be careful when you override settings, especially when the default value
|
||||
is a non-empty tuple or dict, like :setting:`MIDDLEWARE_CLASSES` and
|
||||
:setting:`TEMPLATE_CONTEXT_PROCESSORS`. Make sure you keep the components
|
||||
required by the features of Django you wish to use.
|
||||
is a non-empty tuple or dictionary, such as :setting:`MIDDLEWARE_CLASSES`
|
||||
and :setting:`TEMPLATE_CONTEXT_PROCESSORS`. Make sure you keep the
|
||||
components required by the features of Django you wish to use.
|
||||
|
||||
Available settings
|
||||
==================
|
||||
|
@ -705,9 +705,9 @@ Default::
|
|||
'%B %d, %Y', '%d %B %Y', '%d %B, %Y')
|
||||
|
||||
A tuple of formats that will be accepted when inputting data on a date field.
|
||||
Formats will be tried in order, using the first valid. Note that these format
|
||||
strings are specified in Python's datetime_ module syntax, that is different
|
||||
from the one used by Django for formatting dates to be displayed.
|
||||
Formats will be tried in order, using the first valid one. Note that these
|
||||
format strings use Python's datetime_ module syntax, not the format strings
|
||||
from the ``date`` Django template tag.
|
||||
|
||||
When :setting:`USE_L10N` is ``True``, the locale-dictated format has higher
|
||||
precedence and will be applied instead.
|
||||
|
@ -747,9 +747,9 @@ Default::
|
|||
'%m/%d/%y %H:%M:%S', '%m/%d/%y %H:%M', '%m/%d/%y')
|
||||
|
||||
A tuple of formats that will be accepted when inputting data on a datetime
|
||||
field. Formats will be tried in order, using the first valid. Note that these
|
||||
format strings are specified in Python's datetime_ module syntax, that is
|
||||
different from the one used by Django for formatting dates to be displayed.
|
||||
field. Formats will be tried in order, using the first valid one. Note that
|
||||
these format strings use Python's datetime_ module syntax, not the format
|
||||
strings from the ``date`` Django template tag.
|
||||
|
||||
When :setting:`USE_L10N` is ``True``, the locale-dictated format has higher
|
||||
precedence and will be applied instead.
|
||||
|
@ -1344,7 +1344,7 @@ decorator, for example.
|
|||
.. note::
|
||||
You can use :func:`~django.core.urlresolvers.reverse_lazy` to reference
|
||||
URLs by their name instead of providing a hardcoded value. Assuming a
|
||||
``urls.py`` with an URL pattern named ``home``::
|
||||
``urls.py`` with an URLpattern named ``home``::
|
||||
|
||||
urlpatterns = patterns('',
|
||||
url('^welcome/$', 'test_app.views.home', name='home'),
|
||||
|
@ -2082,9 +2082,9 @@ TIME_INPUT_FORMATS
|
|||
Default: ``('%H:%M:%S', '%H:%M')``
|
||||
|
||||
A tuple of formats that will be accepted when inputting data on a time field.
|
||||
Formats will be tried in order, using the first valid. Note that these format
|
||||
strings are specified in Python's datetime_ module syntax, that is different
|
||||
from the one used by Django for formatting dates to be displayed.
|
||||
Formats will be tried in order, using the first valid one. Note that these
|
||||
format strings use Python's datetime_ module syntax, not the format strings
|
||||
from the ``date`` Django template tag.
|
||||
|
||||
When :setting:`USE_L10N` is ``True``, the locale-dictated format has higher
|
||||
precedence and will be applied instead.
|
||||
|
|
|
@ -600,8 +600,8 @@ For a complete discussion on the usage of the following see the
|
|||
requests a sublanguage where we have a main language, we send out the main
|
||||
language.
|
||||
|
||||
If ``check_path`` is ``True`` the function first checks the requested URL
|
||||
whether its path begins with a language code listed in the
|
||||
If ``check_path`` is ``True``, the function first checks the requested URL
|
||||
for whether its path begins with a language code listed in the
|
||||
:setting:`LANGUAGES` setting.
|
||||
|
||||
.. function:: to_locale(language)
|
||||
|
|
Loading…
Add table
Add a link
Reference in a new issue