Opened 8 years ago

Closed 8 years ago

#27435 closed Bug (needsinfo)

Raise an error when using --keepdb without an explicit TEST.PASSWORD on Oracle

Reported by: Simon Charette Owned by: Mariusz Felisiak
Component: Testing framework Version: 1.10
Severity: Release blocker Keywords: oracle
Cc: carsten.fuchs@… Triage Stage: Accepted
Has patch: no Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: no UI/UX: no

Description

This can be a source of confusion as the kept database is not usable anymore on the second run since we randomly generate a password when TEST.PASSWORD is not provided.

Change History (12)

comment:1 by Mariusz Felisiak, 8 years ago

Triage Stage: UnreviewedAccepted

I think that the best solution will be to set up password randomly every time where it's not set and we use --keepdb flag:

--- a/django/db/backends/oracle/creation.py
+++ b/django/db/backends/oracle/creation.py
@@ -225,7 +225,7 @@ class DatabaseCreation(BaseDatabaseCreation):
         acceptable_ora_err = 'ORA-01920' if keepdb else None
         success = self._execute_allow_fail_statements(cursor, statements, parameters, verbosity, acceptable_ora_err)
         # If the password was randomly generated, change the user accordingly.
-        if not success and self._test_settings_get('PASSWORD') is None:
+        if (not success or keepdb) and self._test_settings_get('PASSWORD') is None:
             set_password = "ALTER USER %(user)s IDENTIFIED BY %(password)s"
             self._execute_statements(cursor, [set_password], parameters, verbosity)
         # Most test-suites can be run without the create-view privilege. But some need it.

I can prepare PR.

comment:2 by Mariusz Felisiak, 8 years ago

Triage Stage: AcceptedUnreviewed

comment:3 by Shai Berger, 8 years ago

Triage Stage: UnreviewedAccepted

Not sure I'd call it a release blocker, but since we're going to fix this area anyway for the next release...

comment:4 by Simon Charette, 8 years ago

@felixxm

I think that the best solution will be to set up password randomly every time where it's not set and we use --keepdb flag:

I'm not too familar with Oracle's authentication management but how are you going to re-connect to the kept database on the second run if you generate a random on the first one?

in reply to:  4 comment:5 by Shai Berger, 8 years ago

Replying to Simon Charette:

@felixxm

I think that the best solution will be to set up password randomly every time where it's not set and we use --keepdb flag:

I'm not too familar with Oracle's authentication management but how are you going to re-connect to the kept database on the second run if you generate a random on the first one?

I'm glad to see it wasn't just me who missed @felixx's intention...

He suggested that we use our administrative user to change the test user's password to a new random password on each run. I think this is a better solution.

comment:6 by Simon Charette, 8 years ago

He suggested that we use our administrative user to change the test user's password to a new random password on each run. I think this is a better solution.

Thanks for the clarification Shai. It sounds like a better solution to me too.

comment:7 by Mariusz Felisiak, 8 years ago

Owner: changed from nobody to Mariusz Felisiak
Status: newassigned

Sorry for unclear explanation.

comment:8 by Mariusz Felisiak, 8 years ago

Now I see that we already change the test user's password on each run (see 1). ORA-01920 means that user already exists.

I think that the problem may be in the ALTER USER permission missing. It's hard to say without error details.

comment:9 by Carsten Fuchs, 8 years ago

Cc: carsten.fuchs@… added

comment:10 by Simon Charette, 8 years ago

I think that the problem may be in the ALTER USER permission missing. It's hard to say without error details.

This ticket might be invalid as I didn't reproduce the error myself. Are we sure that --keepdb actually works when no test password is defined? Or is the database simply dropped by the admin user if we can't connect to it on the second run?

in reply to:  10 comment:11 by Mariusz Felisiak, 8 years ago

Replying to Simon Charette:

I think that the problem may be in the ALTER USER permission missing. It's hard to say without error details.

This ticket might be invalid as I didn't reproduce the error myself. Are we sure that --keepdb actually works when no test password is defined? Or is the database simply dropped by the admin user if we can't connect to it on the second run?

If administrative user has DBA permission (which includes ALTER USER) then test works properly with --keepdb option. I checked this few times. IMO this ticket should be close.

comment:12 by Shai Berger, 8 years ago

Resolution: needsinfo
Status: assignedclosed

Per the last two messages, closing until further details of the actual problem encountered can be provided.

Thanks, @felixxm.

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