Opened 6 years ago

Closed 6 years ago

Last modified 3 years ago

#10844 closed (duplicate)

r10547 broke testing with Oracle

Reported by: jbronn Owned by: ikelly
Component: Database layer (models, ORM) Version: master
Severity: Keywords: oracle test
Cc: Triage Stage: Unreviewed
Has patch: no Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: UI/UX:


More than typos were fixed in r10547, as I can no longer run any part of the test suite. I haven't figured out why (nor have I looked too deeply) -- if a fix can't be found I propose just reverting back to r10032.

C:\django\trunk\tests>python --settings=settings --verbosity=2 aggregation
Importing model aggregation
Creating test database...
Creating test database...
_create_test_db(): dbname = test_orcl
               DATAFILE 'test_orcl.dbf' SIZE 20M

               TEMPFILE 'test_orcl_temp.dbf' SIZE 20M

Creating test user...
_create_test_user(): username = test_geo
CREATE USER test_geo
               IDENTIFIED BY Im_a_lumberjack
               DEFAULT TABLESPACE test_orcl
               TEMPORARY TABLESPACE test_orcl_temp

Traceback (most recent call last):
  File "", line 191, in <module>
    django_tests(int(options.verbosity), options.interactive, args)
  File "", line 161, in django_tests
    failures = test_runner(test_labels, verbosity=verbosity, interactive=interactive, extra_tests=extra_tests)
  File "C:\django\trunk\django\test\", line 191, in run_tests
    connection.creation.create_test_db(verbosity, autoclobber=not interactive)
  File "C:\django\trunk\django\db\backends\", line 326, in create_test_db
    can_rollback = self._rollback_works()
  File "C:\django\trunk\django\db\backends\", line 383, in _rollback_works
    cursor = self.connection.cursor()
  File "C:\django\trunk\django\db\backends\", line 81, in cursor
    cursor = self._cursor()
  File "C:\django\trunk\django\db\backends\oracle\", line 307, in _cursor
    self.connection = Database.connect(conn_string, **self.settings_dict['DATABASE_OPTIONS'])
cx_Oracle.DatabaseError: ORA-12154: TNS:could not resolve the connect identifier specified

Change History (9)

comment:1 follow-up: Changed 6 years ago by Alex

  • Needs documentation unset
  • Needs tests unset
  • Patch needs improvement unset

I'm not an expert, but why is the Oracle backend modifying the global settings, we specifically changed all the backends *not* to do that.

comment:2 in reply to: ↑ 1 Changed 6 years ago by ikelly

Replying to Alex:

I'm not an expert, but why is the Oracle backend modifying the global settings, we specifically changed all the backends *not* to do that.

I don't recall off-hand whether it's necessary or not, but the Oracle backend still modifies the global settings when running the test suite because that's what all the other backends do. See

comment:3 Changed 6 years ago by mboersma

It was commit [10547] that broke the tests for Oracle. I agree the code is messy, but there was no actual reproducible bug described, no test case, and evidently it was checked in without actually running the tests against Oracle. We're a bit past due on Django 1.1, so let's save the code beautification projects for later and just revert it.

comment:4 Changed 6 years ago by Alex

I understand the use of settings.TEST_* settings, what I don't understand is why [10547] would assign to settings.DATABASE_*. The settings.TEST_* is something that's going to have to be dealt with as a part of multidb(my inclination is to move it to DATABASE_OPTIONS), but for now we should be keeping our hands off of settings.DATABASE_* as that's just a regression.

comment:5 Changed 6 years ago by ramiro

Two things to remember, if the decision to revert the changes is finally made:

comment:6 Changed 6 years ago by ikelly

I'm agreed with Matt. The change that was made in [10547] looks like it's just fixing some omissions, but it actually significantly changes the way testing works in Oracle (admittedly, oracle/ is rather confusing in terms of where it pulls parameters from and how it applies them). This should be reverted, and the changes made should only be considered for 1.2.

comment:7 Changed 6 years ago by kmtracey

  • Resolution set to duplicate
  • Status changed from new to closed

We've also got #10716 re-opened for this problem, which is where I put a patch as I hadn't seen this one yet. Can anyone with more Oracle knowledge than me comment on the patch I added to #10716? It does revert the database name change, but instead of reverting the ettings->settings typo fix it tries to fix the problem that that typo fix revealed.

comment:8 Changed 6 years ago by mtredinnick

If it needs to be reverted, then revert it. I checked that patch in because it was fixing one very obvious bug and the other changes looked reasonable and probably necessary. By checking it in, it got tested and a problem was found, which was the whole point! So now can somebody who can test on Oracle please bring this to a close.

comment:9 Changed 3 years ago by jacob

  • milestone 1.1 deleted

Milestone 1.1 deleted

Note: See TracTickets for help on using tickets.
Back to Top