diff options
author | Boris Kolpackov <boris@codesynthesis.com> | 2015-01-21 11:50:32 +0200 |
---|---|---|
committer | Boris Kolpackov <boris@codesynthesis.com> | 2015-01-21 11:50:32 +0200 |
commit | 1d32d12e1f2d7d5f6565bbcddfb9edb9218ec1fe (patch) | |
tree | b550622d14cf06f3be25186f1fe4e4f738c3f449 | |
parent | a72e784f565cc29167b4b736929136cb3f4c17b9 (diff) |
Add feature: duplicate/expression columns
-rw-r--r-- | feature/list | 19 |
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. |