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

[Simon Charette]

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.

[Mariusz Felisiak]

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.

[Shai Berger]

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

[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?

[Shai Berger]

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.

[Simon Charette]

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.

[Mariusz Felisiak]

Sorry for unclear explanation.

[Mariusz Felisiak]

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.

[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?

[Mariusz Felisiak]

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.

[Shai Berger]

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

Thanks, @felixxm.