Opened 6 years ago

Closed 6 years ago

Last modified 4 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:

Description

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 runtests.py --settings=settings --verbosity=2 aggregation
Importing model aggregation
Creating test database...
Creating test database...
_create_test_db(): dbname = test_orcl
CREATE TABLESPACE test_orcl
               DATAFILE 'test_orcl.dbf' SIZE 20M
               REUSE AUTOEXTEND ON NEXT 10M MAXSIZE 100M

CREATE TEMPORARY TABLESPACE test_orcl_temp
               TEMPFILE 'test_orcl_temp.dbf' SIZE 20M
               REUSE AUTOEXTEND ON NEXT 10M MAXSIZE 100M

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

GRANT CONNECT, RESOURCE TO test_geo
Traceback (most recent call last):
  File "runtests.py", line 191, in <module>
    django_tests(int(options.verbosity), options.interactive, args)
  File "runtests.py", line 161, in django_tests
    failures = test_runner(test_labels, verbosity=verbosity, interactive=interactive, extra_tests=extra_tests)
  File "C:\django\trunk\django\test\simple.py", line 191, in run_tests
    connection.creation.create_test_db(verbosity, autoclobber=not interactive)
  File "C:\django\trunk\django\db\backends\creation.py", line 326, in create_test_db
    can_rollback = self._rollback_works()
  File "C:\django\trunk\django\db\backends\creation.py", line 383, in _rollback_works
    cursor = self.connection.cursor()
  File "C:\django\trunk\django\db\backends\__init__.py", line 81, in cursor
    cursor = self._cursor()
  File "C:\django\trunk\django\db\backends\oracle\base.py", 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 http://code.djangoproject.com/browser/django/trunk/django/db/backends/creation.py#L324

comment:3 Changed 6 years ago by mboersma

It was commit [10547] that broke the tests for Oracle. I agree the creation.py 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/creation.py 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 4 years ago by jacob

  • milestone 1.1 deleted

Milestone 1.1 deleted

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