summaryrefslogtreecommitdiff
path: root/feature/list
blob: 688c9f060a05431511f009314770fa91c45fe6fd (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
- ON UPDATE clause in generated schema

  Would be nice to be able to specify this similar to on_delete.

- load_value() that returns object by value, similar to query_value()

  That would be both the database class function as well as the query
  result iterator function. The latter would be especially useful with
  views.

  Somewhat related: it could be that for views it is better not to
  dynamically allocate the instance when we do something like i->count.

- Mass UPDATE

  This could be very useful in data migration code. In fact, need to
  add an example in the manual when this is supported.

! Diagnose lack of default ctor if object used in relationship

  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.