Implement object loading views

See section 10.2 in the manual for details.

1 files changed, 53 insertions, 0 deletions

diff --git a/reference/feature/view/object-loading b/reference/feature/view/object-loading
new file mode 100644
index 0000000..95014e5
--- /dev/null
+++ b/reference/feature/view/object-loading
@@ -0,0 +1,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.