summaryrefslogtreecommitdiff
path: root/feature/view/object-loading
blob: 478d0984bf2b5b4fd07e6ccd2338010ff130b26a (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
- 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 objacts.

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