#4140: oracle: manage.py syncdb fails with ORA-06552 when a fieldname is a 
keyword
-------------------------------------+-------------------------------------
     Reporter:  frank.hoffsummer@…   |                    Owner:  (none)
         Type:  Bug                  |                   Status:  closed
    Component:  Database layer       |                  Version:  dev
  (models, ORM)                      |
     Severity:  Normal               |               Resolution:  invalid
     Keywords:  oracle Oracle        |             Triage Stage:
                                     |  Unreviewed
    Has patch:  0                    |      Needs documentation:  0
  Needs tests:  0                    |  Patch needs improvement:  0
Easy pickings:  0                    |                    UI/UX:  0
-------------------------------------+-------------------------------------
Changes (by Mariusz Felisiak):

 * resolution:   => invalid
 * stage:  Accepted => Unreviewed
 * status:  new => closed

Comment:

 I've tried to create a model with the `timestamp` field and all field
 names are correctly quoted:
 {{{
 $  python manage.py makemigrations
 Migrations for 'test_one':
   test_one/migrations/0001_initial.py
     + Create model LogMessage
 $  python manage.py sqlmigrate test_one 0001
 --
 -- Create model LogMessage
 --
 CREATE TABLE "TEST_ONE_LOGMESSAGE" ("ID" NUMBER(19) GENERATED BY DEFAULT
 ON NULL AS IDENTITY NOT NULL PRIMARY KEY, "TIMESTAMP" TIMESTAMP NOT NULL,
 "LEVEL" NUMBER(11) NOT NULL, "MESSAGE" NCLOB NULL);

 $  python manage.py migrate
 Operations to perform:
   Apply all migrations: admin, auth, contenttypes, sessions, test_one
 Running migrations:
   Applying contenttypes.0001_initial... OK
   Applying auth.0001_initial... OK
   Applying admin.0001_initial... OK
   Applying admin.0002_logentry_remove_auto_add... OK
   Applying admin.0003_logentry_add_action_flag_choices... OK
   Applying contenttypes.0002_remove_content_type_name... OK
   Applying auth.0002_alter_permission_name_max_length... OK
   Applying auth.0003_alter_user_email_max_length... OK
   Applying auth.0004_alter_user_username_opts... OK
   Applying auth.0005_alter_user_last_login_null... OK
   Applying auth.0006_require_contenttypes_0002... OK
   Applying auth.0007_alter_validators_add_error_messages... OK
   Applying auth.0008_alter_user_username_max_length... OK
   Applying auth.0009_alter_user_last_name_max_length... OK
   Applying auth.0010_alter_group_name_max_length... OK
   Applying auth.0011_update_proxy_permissions... OK
   Applying auth.0012_alter_user_first_name_max_length... OK
   Applying sessions.0001_initial... OK
   Applying test_one.0001_initial... OK
 }}}

 Moreover the `timestamp` field appears multiple times in our current test
 suite. As far as I'm aware, this can be closed as invalid, especially that
 we no longer (924a89e135fe54bc7622aa6f03405211e75c06e9) create triggers
 internally.
-- 
Ticket URL: <https://code.djangoproject.com/ticket/4140#comment:22>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
To view this discussion visit 
https://groups.google.com/d/msgid/django-updates/0107019a16de8fda-4b774cb8-da49-4fe3-9c6d-f706ef442f44-000000%40eu-central-1.amazonses.com.

Reply via email to