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
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
|
! Ability to not own underlying database connections
Could be useful when trying to work with other "database drivers".
Seems what would be useful:
1. Flag to the handle ctor not to free.
2. detach() in addition to handle().
3. In connection_pool, delete the connection if it was returned
detached (handle is free).
Also make the connection guts protected.
! Ability not to generate schema for certain objects/containers
Sometimes it can be useful to overlay an object onto existing
(or another object/container) table. This is possible now for
object if one is careful with order but not for containers.
Perhaps an explicit no_schema pragma?
Once this is fixed, diagnose using of abstract classes in views.
See email from <axel50397@gmail.com>/13-Mar-2015.
! Primary key in to-many container table
Can we add 'unique' (similar to 'unordered') to container of object
pointers data member that says no duplicate pointers. We can then
generate a primary key based on the two ids. In fact, should we not
do this by default?
The other way to achieve the same end result would be via the support
for container indexes (i.e., add unique index based on the two).
See email from <CWeiguan@dso.org.sg>/13-Feb-2015.
! Virtual data member only handle simple type specification
Right now there is no way to say virtual(void*) or virtual(nullable<int>).
Can we do something about at least the simple cases, i.e., the raw pointer
(used in the object loading views; see all those *_ptr's in the manual)
and simple templates like above?
While we can instantiate the corresponding template in GCC tree, the
problem is that those types will not be in our semantics graph. This
need to "parse some more" and add things to the graph pops up regularly,
so maybe we should do it. Don't see any serious problems in supporting
something like this. In fact, this particular case, I think, happens
during parsing (or virtual data members).
- Schema to C++ classes
http://codesynthesis.com/pipermail/odb-users/2014-January/001769.html
What if instead of all these mappings, customizations, etc., we
just provide a template (or a plugin) and let the user write/customize
some C++ code to produce a mapping that they want?
Another idea: define database schema tables as persistent classes?
What if the generator is basically an ODB-based application that
the user is expected to customize?
- 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.
? 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.
|
