diff options
| -rw-r--r-- | feature/view/object-loading | 52 |
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. |