blob: 95014e5f5c47d76e752ead89ea3ee5a38715d8c9 (
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
|
+ Object loading views
- The joined object can be joined just to be used in the query condition or
to load the data. How to distinguish the two cases and what should be the
default?
- All the non-lazy object pointers, containers, and sections should probably
be loaded one way or another (if the user wants an "incomplete" load, then
he should use the normal view and specify the data members). This can all
be controlled via lazy pointers/sections on the user side.
So the behavior seems to be load all the non-lazy pointed-to object
either with a single SELECT, if it were joined by the view, or by
issuing a separate SELECT otherwise.
The only uncertain case is a JOIN'ed lazy pointed-to object. Here
the user will have to specify whether to load the object (within
a single SELECT) or it was JOIN'ed only for the query condition.
Since this is a performance feature, the defaul should probably
not to load. The mechanism used to specify this should probably
also be used to specify whether to SELECT FOR UPDATE joined objects.
- Support both object pointer and direct member as an object (similar
to the load() signature). Might have to rely on delay loading. E.g.,
first load all the JOIN'ed objects (and enter them in object cache).
At the same time prevent nested object load by locking the statements.
Then load all the delayed objects which will be resolved via the cache.
That's probably the only way to support a pointer to the same object
in both another object and the view itself.
- Can ask the user to use a session to help resolve the object pointers,
if, for example, the same object is used to initialize another object
member and a view member.
- Can/should this be used to implement SELECT FOR UPDATE? What about JOIN'ed
objects?
- Need to think also how this is related to containers. E.g., container
loading queries?
- Implementation-wise, we probably want to create a combined image out
of inidividual object images and to delegate to the object code as
soon as possible.
- Interraction with other features:
- Polymorphism will be tricky. Probably ok not to support this initially
since often there will be a followup SELECT to load the dynamic part
of the object.
- See also:
See email from <sean.clarke@sec-consulting.co.uk>/30-Oct-2014.
|
