|author||Boris Kolpackov <firstname.lastname@example.org>||2015-05-23 15:53:30 +0200|
|committer||Boris Kolpackov <email@example.com>||2015-05-23 15:53:30 +0200|
Expand on ability not to generate schema for certain objects/containers
1 files changed, 24 insertions, 0 deletions
diff --git a/feature/list b/feature/list
index 3ba0ee5..681dba2 100644
@@ -21,6 +21,30 @@
See email from <firstname.lastname@example.org>/13-Mar-2015.
+ Perhaps this should be also extended to columns. E.g., column
+ that is an expression.
+ See email from <email@example.com>/30-Apr-2015.
+ The problem with columns is that it is only a part of the
+ solution. We should also ignore them in the INSERT statements,
+ and that will get hairy. Also it seems we may want to have
+ no_scema but insert column or no_schema/no_insert (expression).
+ Or perhaps if there is no_schema then also assume we are not
+ responsible for the insertion.
+ What if we don't treat it as a column but as an expression
+ rather? I.e., it doesn't even end up in column_counts? Maybe
+ it ends up in expression_count? Will probably have problems
+ with things like empty(-looking) sections.
+ Coming from another side: this will be pretty trivial to
+ implement with an object-loading view. Could we somehow
+ have a custom load implementation (via OVL)? Would also
+ be necessary for query. What about defining other
+ (potentially OL) views based on it. We cannot define a
+ view based on another view.
! Primary key in to-many container table
Can we add 'unique' (similar to 'unordered') to container of object