#6148: Add generic support for database schemas
-------------------------------------+-------------------------------------
Reporter: ikelly | Owner: akaariai
Type: New feature | Status: new
Component: Database layer | Version: master
(models, ORM) | Resolution:
Severity: Normal | Triage Stage: Design
Keywords: oracle postgresql | decision needed
mysql schemas | Needs documentation: 1
Has patch: 1 | Patch needs improvement: 1
Needs tests: 0 | UI/UX: 0
Easy pickings: 0 |
-------------------------------------+-------------------------------------
Changes (by akaariai):
* needs_tests: 1 => 0
Comment:
I updated the patch to current master, it can be found from
[https://github.com/akaariai/django/tree/db_schemas here].
The patch is currently at ~1700 lines added, 500 removed. So, it is a
pretty big patch.
It does work on my select test list on every core db. I have tested it
using the following tests: introspection transactions inspectdb fixtures
queries extra_regress prefetch_related test_runner aggregation_regress
dbschemas
GIS isn't yet dealt with.
Everybody who wishes this feature into core should test the patch. No need
for code reviews, just test it for your use case. Testing should be
simple: download the code from the branch (by using git directly,
virtualenv git magic or using this link:
[https://github.com/akaariai/django/tarball/db_schemas]). Preferably run
your existing project's tests against the downloaded Django version. You
can use DB schemas by either using database alias setting 'SCHEMA':
'my_testing_schema', or by using Model meta attribute db_schema =
'someschema'.
Please, do test this. I will assume there is no interest in this feature
if nobody reports any test results.
There is still the question if we want to add the complexity of supporting
DB schemas. The complexity comes from three sources:
1. Introspection, creation: multischema awareness makes things more
complicated here. This will also make life harder for 3rd party apps,
South and external database backends come to mind here.
2. Different backends have different requirements: PostgreSQL is easy
here - it has fully namespaced schemas. Oracle and MySQL do not have
these: Django's databases live in the same namespace as schemas. Thus, in
testing the schemas must be 'test_' prefixed to avoid collisions. SQLite
just uses table name prefixing. As an example of other complexities
encountered: Oracle requires creating additional connections to create
foreign keys properly. If somebody knows of a way to overcome this, I am
all ears.
3. Model's name isn't guaranteed to stay the same in testing and in
production. This means problems for raw-SQL users (use
connection.qname(MyModel) to get a fully qualified name). This also causes
some complexities in the patch.
I am going to rebase the branch from time to time. That is, do not base
your work on the branch.
--
Ticket URL: <https://code.djangoproject.com/ticket/6148#comment:114>
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.
