--
Ticket URL: <https://code.djangoproject.com/ticket/13245#comment:7>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
* cc: timo (added)
* needs_better_patch: 1 => 0
* has_patch: 1 => 0
* easy: 0 => 1
* needs_tests: 1 => 0
Comment:
The validation should be added in
`django.core.management.validation.get_validation_errors()` with a test in
`tests/invalid_models/invalid_models/models.py`. The validation and the
test will have to be conditional on `connection.ops.max_name_length()` --
there's already an example in `invalid_models/models.py` for
`connection.features.interprets_empty_strings_as_nulls`.
--
Ticket URL: <https://code.djangoproject.com/ticket/13245#comment:8>
* cc: shaib (added)
* keywords: => oracle
Comment:
The current behavior of the Oracle backend is to truncate, unless the
given name is quoted.
That is, if `Meta` has
{{{
db_table='supercallifragilisticexpialidocious'
}}}
it will be truncated; if it has
{{{
db_table='"supercallifragilisticexpialidocious"'
}}}
we assume the programmer knows what they're doing. I don't like it much as
an API (it is also related to case issues), but I don't think anything
needs to be changed for this bug.
Is there is any related issue on other backends? Has anyone played with
over-63-chars-long table names on PostgreSQL? Otherwise, I think this can
be closed.
--
Ticket URL: <https://code.djangoproject.com/ticket/13245#comment:9>
* easy: 1 => 0
Comment:
Hi Shai, I looked into this on PostgreSQL. Specifying `db_name="string
longer ... than 63 characters"` results in the table name being silently
truncated at 63 characters (does not use
`django.db.backends.utils.truncate_name`). Arguably this should be fixed,
perhaps there's already a ticket, although it seems quite uncommon and low
priority.
The action item I was proposing for this ticket was what Russ proposed in
comment 2: "I would expect to see a validation error if you ever tried to
synchronize a model with a db_table specification that exceeded the limits
of the backend."
Do you disagree with that? Of course, this ticket seems a bit trickier
than I expected given the Oracle specific logic in it's definition of
`quote_name` you mentioned regarding a quoted `db_name`.
--
Ticket URL: <https://code.djangoproject.com/ticket/13245#comment:10>
Comment (by shai):
Hi Tim,
Yes, I disagree with the proposed solution -- actually, with the bug
itself as it stands -- because it means some perfectly-working apps will
suddenly stop working on Oracle; apps developed on other backends are
particularly susceptible to this.
We probably need a documentation fix here. Other than that, we need to be
consistent, but the other backends' limitations are so seldom met, that it
is indeed very low priority.
--
Ticket URL: <https://code.djangoproject.com/ticket/13245#comment:11>
* cc: shaib (removed)
* cc: shai (added)
--
Ticket URL: <https://code.djangoproject.com/ticket/13245#comment:12>
Comment (by shai):
Suggested documentation fixes in
https://github.com/django/django/pull/1787
--
Ticket URL: <https://code.djangoproject.com/ticket/13245#comment:13>
* component: Database layer (models, ORM) => Documentation
* has_patch: 0 => 1
* type: Bug => Cleanup/optimization
* stage: Accepted => Ready for checkin
--
Ticket URL: <https://code.djangoproject.com/ticket/13245#comment:14>
* status: new => closed
* resolution: => fixed
Comment:
In [changeset:"6de3726423b8df4fb8ab05caa109a8c6308e6060"]:
{{{
#!CommitTicketReference repository=""
revision="6de3726423b8df4fb8ab05caa109a8c6308e6060"
Fixed #13245: Explained Oracle's behavior w.r.t db_table
and how to prevent table-name truncation
Thanks russellm & timo for discussion, and timo for review.
Backported from master 317040a73b77be8f8210801793b2ce6d1a69301e
}}}
--
Ticket URL: <https://code.djangoproject.com/ticket/13245#comment:15>
Comment (by Shai Berger <shai@…>):
In [changeset:"cc0dcfc64405419d95e87c8dcc612bd441a8d6de"]:
{{{
#!CommitTicketReference repository=""
revision="cc0dcfc64405419d95e87c8dcc612bd441a8d6de"
Fixed #13245: Explained Oracle's behavior w.r.t db_table
and how to prevent table-name truncation
Thanks russellm & timo for discussion, and timo for review.
Backported from master 317040a73b77be8f8210801793b2ce6d1a69301e
}}}
--
Ticket URL: <https://code.djangoproject.com/ticket/13245#comment:16>
Comment (by Shai Berger <shai@…>):
In [changeset:"27f3f341369c8e18ea4a360a1f7c01531836b68b"]:
{{{
#!CommitTicketReference repository=""
revision="27f3f341369c8e18ea4a360a1f7c01531836b68b"
Fixed #13245: Explained Oracle's behavior w.r.t db_table
and how to prevent table-name truncation
Thanks russellm & timo for discussion, and timo for review.
Backported from master 317040a73b77be8f8210801793b2ce6d1a69301e
}}}
--
Ticket URL: <https://code.djangoproject.com/ticket/13245#comment:17>
Comment (by Shai Berger <shai@…>):
In [changeset:"317040a73b77be8f8210801793b2ce6d1a69301e"]:
{{{
#!CommitTicketReference repository=""
revision="317040a73b77be8f8210801793b2ce6d1a69301e"
Fixed #13245: Explained Oracle's behavior w.r.t db_table
and how to prevent table-name truncation
Thanks russellm & timo for discussion, and timo for review.
}}}
--
Ticket URL: <https://code.djangoproject.com/ticket/13245#comment:18>
Comment (by shai):
Hmm, cherry-picking this was too easy... I forgot to add branch prefixes
to the header line.
6de3726423b8df4fb8ab05caa109a8c6308e6060 is for 1.4.x
cc0dcfc64405419d95e87c8dcc612bd441a8d6de is for 1.5.x
27f3f341369c8e18ea4a360a1f7c01531836b68b is for 1.6.x
317040a73b77be8f8210801793b2ce6d1a69301e is for master
--
Ticket URL: <https://code.djangoproject.com/ticket/13245#comment:19>