#6148: Add generic support for database schemas
-------------------------------------+-------------------------------------
     Reporter:  ikelly               |                    Owner:  akaariai
         Type:  New feature          |                   Status:  new
    Component:  Database layer       |                  Version:  master
  (models, ORM)                      |
     Severity:  Normal               |               Resolution:
     Keywords:  oracle postgresql    |             Triage Stage:  Accepted
  mysql schemas                      |
    Has patch:  1                    |      Needs documentation:  1
  Needs tests:  0                    |  Patch needs improvement:  1
Easy pickings:  0                    |                    UI/UX:  0
-------------------------------------+-------------------------------------

Comment (by akaariai):

 If we ever want to proceed on this ticket, I think we need to split this
 to two parts:
   - Make core ORM usable with multi-schema setups
   - Allow migrations for multi-schema setups

 I claim that the first item is easier than one would first imagine, and
 the correct approach is to make Meta.db_table a class that implements
 as_table_sql(). The return value is a 3-tuple, containing sql, params,
 always_alias=True/False. The SQL is either table reference ("a_table"),
 schema qualified reference ("some_schema"."a_table") or a subquery
 ("(select * from foobar)"). The possibility to use subqueries will make it
 much easier to create view-like functionality to Django ORM.

 We can't add a SchemaQualifiedTable class to Django before we have some
 migrations support. Support for migrations will be harder to tackle. (how
 exactly do you create schemas with different databases backends? What
 about SQLite that doesn't even have schemas?) But just having the ability
 to use hand-created tables or existing tables in schema-qualified form
 (and also the view like functionality) will be extremely useful.

 I guess we can approach this with a semi-private-api approach. Allow for
 as_table_sql(), and make basic things work (basic queries, joins, update,
 insert, delete), and then proceed from there. It is possible (but not
 certain at all) that this doesn't need changes to other places than join
 generation and the Join + BaseTable classes.

--
Ticket URL: <https://code.djangoproject.com/ticket/6148#comment:165>
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 unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
To post to this group, send email to [email protected].
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/064.e889808cf4063109fa9670b87806c361%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to