From d6bf93ae12d0a8cffcdb405392921583b420d8b4 Mon Sep 17 00:00:00 2001 From: Boris Kolpackov <boris@codesynthesis.com> Date: Wed, 4 Feb 2015 17:23:54 +0200 Subject: Implement object loading views See section 10.2 in the manual for details. --- feature/view/object-loading | 53 --------------------------------------------- 1 file changed, 53 deletions(-) delete mode 100644 feature/view/object-loading (limited to 'feature/view') 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. -- cgit v1.1