summaryrefslogtreecommitdiff
path: root/feature/list
blob: 1add61809094e021464d030131d0fa3a8f2dc5b7 (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
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
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
- Add test for calling Oracle stored procedures [oracle]

  http://stackoverflow.com/questions/25770846/call-an-oracle-stored-procedure-via-oci-and-return-the-results-with-an-out-ref-c
  http://stackoverflow.com/questions/16037569/how-to-execute-a-stored-procedure-using-oci8-in-php

! Recognize database-specific list of full statement prefixes in view

  See @@-note in odb/relational/processor.cxx.

? Add (template) parameter which determines if lazy_ptr loads in
  operator*/->.

  Do it only after C++11 switch.

! Ability to define index on container value [dup]

  Would be needed to implement SQLite "suggested fk index".
  Also probably need to support composite value/nested member.

  Mention suggested index in SQLite limitations.

- points_to and automatic view relationships discovery

- points_to and query support like for object pointers

! Move value to by-value modifiers [c++11]

! Diagnose use of relationship smart pointer if object pointer is raw [diag]

  Diagnose if it is raw by default (i.e., not explicitly specified) and
  suggest explicitly making it raw (pointer(*)) if that's what the user
  really wants.

! 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.

  Perhaps this should be also extended to columns. E.g., column
  that is an expression.

  See email from <fasdfasdas@gmail.com>/30-Apr-2015.

  The problem with columns is that it is only a part of the
  solution. We should also ignore them in the INSERT statements,
  and that will get hairy. Also it seems we may want to have
  no_scema but insert column or no_schema/no_insert (expression).
  Or perhaps if there is no_schema then also assume we are not
  responsible for the insertion.

  What if we don't treat it as a column but as an expression
  rather? I.e., it doesn't even end up in column_counts? Maybe
  it ends up in expression_count? Will probably have problems
  with things like empty(-looking) sections.

  Coming from another side: this will be pretty trivial to
  implement with an object-loading view. Could we somehow
  have a custom load implementation (via OVL)? Would also
  be necessary for query. What about defining other
  (potentially OL) views based on it. We cannot define a
  view based on another view.

! 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.