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


Ignore:
Timestamp:
Sep 5, 2015, 7:25:41 AM (9 years ago)
Author:
Anssi Kääriäinen

Legend:

Unmodified
Added
Removed
Modified

  • Ticket #6148, comment 165

    initial v1  
    33  - Allow migrations for multi-schema setups
    44
    5 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.
     5I claim that the first item is easier than one would first imagine, and the correct approach is to make Meta.db_table values respect an interface. The interface has as_sql(compiler, connection). The return value will be the usual 2-tuple containing sql, params. 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. The interface also needs an "always_alias" flag, so that Django knows to always generate aliases for schema qualified tables and subqueries.
    66
    7 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.
     7We can't add a SchemaQualifiedTable class to Django before we have some migrations support  (but we can add the above mentioned interface). 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 will be extremely useful. The subqueries will also be a powerful new feature.
    88
    9 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.
     9I guess we can approach this with a semi-private-api approach. Allow for as_sql() for db_table, and make basic things work (basic queries, 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.
Back to Top