Opened 12 years ago
Last modified 10 years ago
#18844 new New feature
Allow Oracle DatabaseWrapper to support session options extra kwargs as settings.DATABASE_OPTIONS
Reported by: | Owned by: | nobody | |
---|---|---|---|
Component: | Database layer (models, ORM) | Version: | 1.4 |
Severity: | Normal | Keywords: | oracle session options |
Cc: | Triage Stage: | Accepted | |
Has patch: | no | Needs documentation: | no |
Needs tests: | no | Patch needs improvement: | no |
Easy pickings: | no | UI/UX: | no |
Description
It would be nice to support extra keyword arguments on backends.oracle.DatabaseWrapper to set session options like NLS_DATE_FORMAT, NLS_LANGUAGE, NLS_TERRITORY, etc. Some databases have different options and those are fixed.
Change History (3)
comment:1 by , 12 years ago
Triage Stage: | Unreviewed → Accepted |
---|
comment:2 by , 12 years ago
comment:3 by , 12 years ago
One option would be to allow doing this in subclasses. Currently (in master) the session state is set up in init_session_state(). It does a bit more than just set the NLS options. If we splitted out the NLS options setup to init_nls_options() then it would be trivial to subclass & override the options.
The only problem with the above plan is that the API of the backend isn't public, so we couldn't actually document this.
Any idea what the settings file format should look like?
For reference here are the NLS specific commands ran on connection initialization:
cursor.execute("ALTER SESSION SET NLS_TERRITORY = 'AMERICA'") # Set oracle date to ansi date format. This only needs to execute # once when we create a new connection. We also set the Territory # to 'AMERICA' which forces Sunday to evaluate to a '1' in # TO_CHAR(). cursor.execute( "ALTER SESSION SET NLS_DATE_FORMAT = 'YYYY-MM-DD HH24:MI:SS'" " NLS_TIMESTAMP_FORMAT = 'YYYY-MM-DD HH24:MI:SS.FF'" + (" TIME_ZONE = 'UTC'" if settings.USE_TZ else '')) }}} [http://lockerdome.com/blog]
I support this, presuming that allowing setting NLS_LANG as an option in the settings file would address the concerns stated in my comment to #15313.