Refs #36485 -- Rewrapped docs to 79 columns line length.

Lines in the docs files were manually adjusted to conform to the
79 columns limit per line (plus newline), improving readability and
consistency across the content.

1 files changed, 26 insertions, 25 deletions

diff --git a/docs/ref/databases.txt b/docs/ref/databases.txt
index d3df35a106..e54776359e 100644
--- a/docs/ref/databases.txt
+++ b/docs/ref/databases.txt
@@ -439,10 +439,10 @@ Django supports MySQL 8.0.11 and higher.
 Django's ``inspectdb`` feature uses the ``information_schema`` database, which
 contains detailed data on all database schemas.
 
-Django expects the database to support Unicode (UTF-8 encoding) and delegates to
-it the task of enforcing transactions and referential integrity. It is important
-to be aware of the fact that the two latter ones aren't actually enforced by
-MySQL when using the MyISAM storage engine, see the next section.
+Django expects the database to support Unicode (UTF-8 encoding) and delegates
+to it the task of enforcing transactions and referential integrity. It is
+important to be aware of the fact that the two latter ones aren't actually
+enforced by MySQL when using the MyISAM storage engine, see the next section.
 
 .. _mysql-storage-engines:
 
@@ -691,8 +691,8 @@ storage engine, you have a couple of options.
 Table names
 -----------
 
-There are `known issues`_ in even the latest versions of MySQL that can cause the
-case of a table name to be altered when certain SQL statements are executed
+There are `known issues`_ in even the latest versions of MySQL that can cause
+the case of a table name to be altered when certain SQL statements are executed
 under certain conditions. It is recommended that you use lowercase table
 names, if possible, to avoid any problems that might arise from this behavior.
 Django uses lowercase table names when it auto-generates table names from
@@ -710,10 +710,10 @@ Both the Django ORM and MySQL (when using the InnoDB :ref:`storage engine
 
 If you use the MyISAM storage engine please be aware of the fact that you will
 receive database-generated errors if you try to use the :ref:`savepoint-related
-methods of the transactions API <topics-db-transactions-savepoints>`. The reason
-for this is that detecting the storage engine of a MySQL database/table is an
-expensive operation so it was decided it isn't worth to dynamically convert
-these methods in no-op's based in the results of such detection.
+methods of the transactions API <topics-db-transactions-savepoints>`. The
+reason for this is that detecting the storage engine of a MySQL database/table
+is an expensive operation so it was decided it isn't worth to dynamically
+convert these methods in no-op's based in the results of such detection.
 
 Notes on specific fields
 ------------------------
@@ -748,9 +748,9 @@ MySQL can store fractional seconds, provided that the column definition
 includes a fractional indication (e.g. ``DATETIME(6)``).
 
 Django will not upgrade existing columns to include fractional seconds if the
-database server supports it. If you want to enable them on an existing database,
-it's up to you to either manually update the column on the target database, by
-executing a command like:
+database server supports it. If you want to enable them on an existing
+database, it's up to you to either manually update the column on the target
+database, by executing a command like:
 
 .. code-block:: sql
 
@@ -762,11 +762,12 @@ or using a :class:`~django.db.migrations.operations.RunSQL` operation in a
 ``TIMESTAMP`` columns
 ~~~~~~~~~~~~~~~~~~~~~
 
-If you are using a legacy database that contains ``TIMESTAMP`` columns, you must
-set :setting:`USE_TZ = False <USE_TZ>` to avoid data corruption.
+If you are using a legacy database that contains ``TIMESTAMP`` columns, you
+must set :setting:`USE_TZ = False <USE_TZ>` to avoid data corruption.
 :djadmin:`inspectdb` maps these columns to
 :class:`~django.db.models.DateTimeField` and if you enable timezone support,
-both MySQL and Django will attempt to convert the values from UTC to local time.
+both MySQL and Django will attempt to convert the values from UTC to local
+time.
 
 Row locking with ``QuerySet.select_for_update()``
 -------------------------------------------------
@@ -795,9 +796,10 @@ Automatic typecasting can cause unexpected results
 When performing a query on a string type, but with an integer value, MySQL will
 coerce the types of all values in the table to an integer before performing the
 comparison. If your table contains the values ``'abc'``, ``'def'`` and you
-query for ``WHERE mycolumn=0``, both rows will match. Similarly, ``WHERE mycolumn=1``
-will match the value ``'abc1'``. Therefore, string type fields included in Django
-will always cast the value to a string before using it in a query.
+query for ``WHERE mycolumn=0``, both rows will match. Similarly, ``WHERE
+mycolumn=1`` will match the value ``'abc1'``. Therefore, string type fields
+included in Django will always cast the value to a string before using it in a
+query.
 
 If you implement custom model fields that inherit from
 :class:`~django.db.models.Field` directly, are overriding
@@ -865,14 +867,13 @@ __ https://www.sqlite.org/datatype3.html#storage_classes_and_datatypes
 SQLite is meant to be a lightweight database, and thus can't support a high
 level of concurrency. ``OperationalError: database is locked`` errors indicate
 that your application is experiencing more concurrency than ``sqlite`` can
-handle in default configuration. This error means that one thread or process has
-an exclusive lock on the database connection and another thread timed out
+handle in default configuration. This error means that one thread or process
+has an exclusive lock on the database connection and another thread timed out
 waiting for the lock the be released.
 
-Python's SQLite wrapper has
-a default timeout value that determines how long the second thread is allowed to
-wait on the lock before it times out and raises the ``OperationalError: database
-is locked`` error.
+Python's SQLite wrapper has a default timeout value that determines how long
+the second thread is allowed to wait on the lock before it times out and raises
+the ``OperationalError: database is locked`` error.
 
 If you're getting this error, you can solve it by: