blob: c47f926619d851045f4b07fa74e789b3f03a72c0 (
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
|
* Documentation: doc/
* Composite value: composite/
* Container: container/
* Query: query/
* View: view/
- 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?
|
