summaryrefslogtreecommitdiff
path: root/feature
diff options
context:
space:
mode:
authorBoris Kolpackov <boris@codesynthesis.com>2015-01-21 11:50:32 +0200
committerBoris Kolpackov <boris@codesynthesis.com>2015-01-21 11:50:32 +0200
commit1d32d12e1f2d7d5f6565bbcddfb9edb9218ec1fe (patch)
treeb550622d14cf06f3be25186f1fe4e4f738c3f449 /feature
parenta72e784f565cc29167b4b736929136cb3f4c17b9 (diff)
Add feature: duplicate/expression columns
Diffstat (limited to 'feature')
-rw-r--r--feature/list19
1 files changed, 19 insertions, 0 deletions
diff --git a/feature/list b/feature/list
index dff0004..f2043e0 100644
--- a/feature/list
+++ b/feature/list
@@ -23,3 +23,22 @@
Got two questions on the mailing list about that in one week. Maybe
always diagnose lack of public ctor? Maybe with a warning if no
relationship? The no_ctor pragma like no_id?
+
+? Duplicate columns
+
+ It can sometimes be useful to map multiple data members to the same
+ column. For example, to map a shared_ptr to another object via id.
+ Or to update object id.
+
+ To implement this, we will have to be able to ignore duplicates in
+ the INSERT statement and in generated schema. So there will have to
+ be quite a bit of work throughout (bind, init, column counts, etc).
+
+ Also not clear if it is a good idea to always ignore duplicates
+ (could actually be a mistake) or only if the column name is
+ specified explicitly (still can be a mistake). Or mark it as a
+ duplicate with a special pragma.
+
+ Is this a special case of something like "expression columns"? It
+ seems the only place where such a duplicate column will actually
+ be mentioned is the SELECT statement.