From a0ce708c1cfa29c13d7334bb27d9c91f570307e8 Mon Sep 17 00:00:00 2001 From: Mariusz Felisiak Date: Tue, 15 Sep 2015 22:01:31 +0200 Subject: [PATCH] [1.8.x] Made assorted improvements to the Oracle documentation. Backport of 6f1b09bb5c1bafe4633514cbff37f9a7ed7a63ae from master --- docs/intro/tutorial01.txt | 13 +++++++------ docs/ref/databases.txt | 16 +++++++++------- docs/ref/django-admin.txt | 7 ++++--- docs/ref/models/querysets.txt | 4 ++-- docs/ref/unicode.txt | 6 ++++++ 5 files changed, 28 insertions(+), 18 deletions(-) diff --git a/docs/intro/tutorial01.txt b/docs/intro/tutorial01.txt index ac0e4fff26..2c45246566 100644 --- a/docs/intro/tutorial01.txt +++ b/docs/intro/tutorial01.txt @@ -201,8 +201,9 @@ and creates any necessary database tables according to the database settings in your :file:`mysite/settings.py` file and the database migrations shipped with the app (we'll cover those later). You'll see a message for each migration it applies. If you're interested, run the command-line client for your -database and type ``\dt`` (PostgreSQL), ``SHOW TABLES;`` (MySQL), or -``.schema`` (SQLite) to display the tables Django created. +database and type ``\dt`` (PostgreSQL), ``SHOW TABLES;`` (MySQL), ``.schema`` +(SQLite), or ``SELECT TABLE_NAME FROM USER_TABLES;`` (Oracle) to display the +tables Django created. .. admonition:: For the minimalists @@ -518,7 +519,7 @@ Note the following: * It's tailored to the database you're using, so database-specific field types such as ``auto_increment`` (MySQL), ``serial`` (PostgreSQL), or ``integer primary key autoincrement`` (SQLite) are handled for you automatically. Same - goes for the quoting of field names -- e.g., using double quotes or + goes for the quoting of field names -- e.g., using double quotes or single quotes. * The :djadmin:`sqlmigrate` command doesn't actually run the migration on your @@ -565,9 +566,9 @@ but for now, remember the three-step guide to making model changes: * Run :djadmin:`python manage.py migrate ` to apply those changes to the database. -The reason that there are separate commands to make and apply migrations is -because you'll commit migrations to your version control system and ship them -with your app; they not only make your development easier, they're also +The reason that there are separate commands to make and apply migrations is +because you'll commit migrations to your version control system and ship them +with your app; they not only make your development easier, they're also useable by other developers and in production. Read the :doc:`django-admin documentation ` for full diff --git a/docs/ref/databases.txt b/docs/ref/databases.txt index a9308a76a0..bad0a06b98 100644 --- a/docs/ref/databases.txt +++ b/docs/ref/databases.txt @@ -762,13 +762,15 @@ for Django's own test suite. All of these privileges are included in the DBA role, which is appropriate for use on a private developer's database. -The Oracle database backend uses the ``SYS.DBMS_LOB`` package, so your user -will require execute permissions on it. It's normally accessible to all users -by default, but in case it is not, you'll need to grant permissions like so: +The Oracle database backend uses the ``SYS.DBMS_LOB`` and ``SYS.DBMS_RANDOM`` +packages, so your user will require execute permissions on it. It's normally +accessible to all users by default, but in case it is not, you'll need to grant +permissions like so: .. code-block:: sql GRANT EXECUTE ON SYS.DBMS_LOB TO user; + GRANT EXECUTE ON SYS.DBMS_RANDOM TO user; Connecting to the database -------------------------- @@ -892,10 +894,10 @@ some limitations on the usage of such LOB columns in general: * LOB columns may not be used in a ``SELECT DISTINCT`` list. This means that attempting to use the ``QuerySet.distinct`` method on a model that - includes ``TextField`` columns will result in an error when run against - Oracle. As a workaround, use the ``QuerySet.defer`` method in conjunction - with ``distinct()`` to prevent ``TextField`` columns from being included in - the ``SELECT DISTINCT`` list. + includes ``TextField`` columns will result in an ``ORA-00932`` error when + run against Oracle. As a workaround, use the ``QuerySet.defer`` method in + conjunction with ``distinct()`` to prevent ``TextField`` columns from being + included in the ``SELECT DISTINCT`` list. .. _third-party-notes: diff --git a/docs/ref/django-admin.txt b/docs/ref/django-admin.txt index 5c8690f712..a92727abd8 100644 --- a/docs/ref/django-admin.txt +++ b/docs/ref/django-admin.txt @@ -217,11 +217,12 @@ Runs the command-line client for the database engine specified in your * For PostgreSQL, this runs the ``psql`` command-line client. * For MySQL, this runs the ``mysql`` command-line client. * For SQLite, this runs the ``sqlite3`` command-line client. +* For Oracle, this runs the ``sqlplus`` command-line client. This command assumes the programs are on your ``PATH`` so that a simple call to -the program name (``psql``, ``mysql``, ``sqlite3``) will find the program in -the right place. There's no way to specify the location of the program -manually. +the program name (``psql``, ``mysql``, ``sqlite3``, ``sqlplus``) will find the +program in the right place. There's no way to specify the location of the +program manually. The :djadminopt:`--database` option can be used to specify the database onto which to open a shell. diff --git a/docs/ref/models/querysets.txt b/docs/ref/models/querysets.txt index c5f83a7cf4..5dbac1c4ae 100644 --- a/docs/ref/models/querysets.txt +++ b/docs/ref/models/querysets.txt @@ -732,7 +732,7 @@ object. If it's ``None``, Django uses the :ref:`current time zone .. _pytz: http://pytz.sourceforge.net/ .. _Time Zones: http://www.postgresql.org/docs/current/static/datatype-datetime.html#DATATYPE-TIMEZONES - .. _Choosing a Time Zone File: http://docs.oracle.com/cd/B19306_01/server.102/b14225/ch4datetime.htm#i1006667 + .. _Choosing a Time Zone File: http://docs.oracle.com/cd/E11882_01/server.112/e10729/ch4datetime.htm#NLSPG258 .. _mysql_tzinfo_to_sql: http://dev.mysql.com/doc/refman/5.6/en/mysql-tzinfo-to-sql.html none @@ -2732,7 +2732,7 @@ SQL equivalents:: SELECT ... WHERE title REGEXP BINARY '^(An?|The) +'; -- MySQL - SELECT ... WHERE REGEXP_LIKE(title, '^(an?|the) +', 'c'); -- Oracle + SELECT ... WHERE REGEXP_LIKE(title, '^(An?|The) +', 'c'); -- Oracle SELECT ... WHERE title ~ '^(An?|The) +'; -- PostgreSQL diff --git a/docs/ref/unicode.txt b/docs/ref/unicode.txt index d4f560861f..f52076d2f7 100644 --- a/docs/ref/unicode.txt +++ b/docs/ref/unicode.txt @@ -23,11 +23,17 @@ able to store certain characters in the database, and information will be lost. * PostgreSQL users, refer to the `PostgreSQL manual`_ (section 22.3.2 in PostgreSQL 9) for details on creating databases with the correct encoding. +* Oracle users, refer to the `Oracle manual`_ for details on how to set + (`section 2`_) or alter (`section 11`_) the database character set encoding. + * SQLite users, there is nothing you need to do. SQLite always uses UTF-8 for internal encoding. .. _MySQL manual: http://dev.mysql.com/doc/refman/5.6/en/charset-database.html .. _PostgreSQL manual: http://www.postgresql.org/docs/current/static/multibyte.html +.. _Oracle manual: http://docs.oracle.com/cd/E11882_01/server.112/e10729/toc.htm +.. _section 2: http://docs.oracle.com/cd/E11882_01/server.112/e10729/ch2charset.htm#NLSPG002 +.. _section 11: http://docs.oracle.com/cd/E11882_01/server.112/e10729/ch11charsetmig.htm#NLSPG011 All of Django's database backends automatically convert Unicode strings into the appropriate encoding for talking to the database. They also automatically