+ 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.