#6148: Add generic support for database schemas
-------------------------------------+-------------------------------------
Reporter: ikelly | Owner: akaariai
Type: New feature | Status: new
Component: Database layer | Version: SVN
(models, ORM) | Resolution:
Severity: Normal | Triage Stage: Accepted
Keywords: oracle postgresql | Needs documentation: 1
mysql schemas | Patch needs improvement: 1
Has patch: 1 | UI/UX: 0
Needs tests: 1 |
Easy pickings: 0 |
-------------------------------------+-------------------------------------
Comment (by akaariai):
mitar: Yes it would. However I don't think it is Django's business to
change seatch_path, at least if not explicitly asked. In addition, you
will have no problems on PostgreSQL except if you plan to install the same
application in multiple schemas which could happen to 3rd party apps for
example. Testing will not be a problem on PostgreSQL except in the
previous case.
It isn't hard to write proper raw SQL which works in testing, you need to
do cursor.execute("SELECT * FROM %s WHERE id = %%s" %
connection.qname(!ModelClass), (id_val,)). You do not need to do this
connection.qname transformation if you do not plan to support schemas.
Everything will work just as before in that case.
It would actually make sense to also have a connection.cols(!ModelClass)
-> named_tuple, as this would help in writing proper SQL with qualified
names (DRY also).
Current [https://github.com/akaariai/django/tree/schemas situation]:
MySQL, PostgreSQL and SQLite all pass full test suite when running under
custom schema. The django/db/backends changes will need to be reviewed and
there is some need for a rewrite. It is bit of a mess at the moment.
Supporting Oracle should also be pretty straightforward, as MySQL and
Oracle have similar schema support from Django's perspective.
The docs should not advertise this feature too much. For most applications
you really don't want to use schemas. On SQLite the schema support is just
a compatibility hack, on MySQL you definitely do not want to run with
global custom schema (use different database instead). However, on
PostgreSQL and Oracle this could be really valuable especially for hand-
written/legacy schemas.
--
Ticket URL: <https://code.djangoproject.com/ticket/6148#comment:106>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
--
You received this message because you are subscribed to the Google Groups
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-updates?hl=en.
