Code

Changes between Initial Version and Version 1 of Ticket #6148, comment 116


Ignore:
Timestamp:
06/07/12 10:58:57 (2 years ago)
Author:
ikelly
Comment:

Legend:

Unmodified
Added
Removed
Modified
  • Ticket #6148, comment 116

    initial v1  
    33I want to suggest that we also consider foreign-schema creation to be out of scope for databases like Oracle, where schemas and users are the same things.  The current code that attempts to do all this through a single configured Oracle connection is a bit naive; it assumes that all users have the same password, and it appears to also assume that the configured Django user has the CREATE ANY TABLE privilege, which would be an unusual production setup. 
    44 
    5 Instead, a Django user who wants to manage multiple Oracle schemas with Django should set up a separate database connection for each schema.  This way we're not trying to create or alter objects belonging to other users.  For the REFERENCES issue, there are two cases -- either the foreign schema is not also managed by Django, in which case the user is responsible for ensuring the necessary grants, or both schemas are managed by Django, in which case we might better be able to automate the grant with the using() construct. 
     5Instead, a Django user who wants to manage multiple Oracle schemas with Django should set up a separate database connection for each schema.  This way we're not trying to create or alter objects belonging to other users.  For the REFERENCES issue, there are two cases -- either the referenced schema is not also managed by Django, in which case the user is responsible for ensuring the necessary grants, or both schemas are managed by Django, in which case we might better be able to automate the grant with the using() construct.