summaryrefslogtreecommitdiff
path: root/feature
diff options
context:
space:
mode:
authorBoris Kolpackov <boris@codesynthesis.com>2014-11-01 09:34:39 +0200
committerBoris Kolpackov <boris@codesynthesis.com>2014-11-01 09:34:39 +0200
commitd3b0bf0ca6899e72d6553027c9220fa6e6e70932 (patch)
tree97281d00f62996f829d6a7070662bef4abe679d6 /feature
parenta3cf15ba206f5571342c829c06f6de1653928364 (diff)
Add thoughts on object loading views
Diffstat (limited to 'feature')
-rw-r--r--feature/view/object-loading52
1 files changed, 50 insertions, 2 deletions
diff --git a/feature/view/object-loading b/feature/view/object-loading
index 80a6dda..478d098 100644
--- a/feature/view/object-loading
+++ b/feature/view/object-loading
@@ -1,3 +1,51 @@
-See email from <sean.clarke@sec-consulting.co.uk>/30-Oct-2014.
+- 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?
-Need to think also how this is related to containers.
+- 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.