summaryrefslogtreecommitdiff
path: root/feature/view
diff options
context:
space:
mode:
authorBoris Kolpackov <boris@codesynthesis.com>2015-02-04 17:23:54 +0200
committerBoris Kolpackov <boris@codesynthesis.com>2015-02-04 17:23:54 +0200
commitd6bf93ae12d0a8cffcdb405392921583b420d8b4 (patch)
treee36a12fb61be6613d84a5a574cf0851c35d007da /feature/view
parent99cb130912baa9bf068c8b05bc99e86c542e115d (diff)
Implement object loading views
See section 10.2 in the manual for details.
Diffstat (limited to 'feature/view')
-rw-r--r--feature/view/object-loading53
1 files changed, 0 insertions, 53 deletions
diff --git a/feature/view/object-loading b/feature/view/object-loading
deleted file mode 100644
index 8ecabb2..0000000
--- a/feature/view/object-loading
+++ /dev/null
@@ -1,53 +0,0 @@
-! Object loading views [2.4.0]
-
-- 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.