|author||Boris Kolpackov <firstname.lastname@example.org>||2015-01-21 11:50:32 +0200|
|committer||Boris Kolpackov <email@example.com>||2015-01-21 11:50:32 +0200|
Add feature: duplicate/expression columns
1 files changed, 19 insertions, 0 deletions
diff --git a/feature/list b/feature/list
index dff0004..f2043e0 100644
@@ -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.