OCLOperators ExecuteQueryPlan
m ((username removed) (log details removed): Moving to Documentation namespace)
(Replacing message template with parser tag)
 
(2 intermediate revisions by the same user not shown)
Line 1: Line 1:
<message>Write the content here to display this box</message>
When you have a collection of objects you do not know the fetch status of and you are going to follow associations or derive stuff that follows associations, it is a good idea to ask MDriven to ExecuteQueryPlan.
When you have a collection of objects you do not know the fetch status of and you are going to follow associations or derive stuff that follows associations, it is a good idea to ask MDriven to ExecuteQueryPlan.


It enters "fact-finder-mode", running your expressions in the ViewModel in a harness - looking at what data WOULD be fetched - then it fetches that data and runs the fact-finder again.  This way, we can avoid 1000 single fetches and end up with 2-3 large fetches instead.
It enters "fact-finder-mode", running your expressions in the ViewModel in a harness - looking at what data WOULD be fetched - then it fetches that data and runs the fact-finder again.  This way, we can avoid 1000 single fetches and end up with 2-3 large fetches instead.
[[Category:OCLOperators]]
[[Category:OCLOperators]]
{{Edited|July|12|2024}}

Latest revision as of 07:47, 17 June 2024

When you have a collection of objects you do not know the fetch status of and you are going to follow associations or derive stuff that follows associations, it is a good idea to ask MDriven to ExecuteQueryPlan.

It enters "fact-finder-mode", running your expressions in the ViewModel in a harness - looking at what data WOULD be fetched - then it fetches that data and runs the fact-finder again. This way, we can avoid 1000 single fetches and end up with 2-3 large fetches instead.

This page was edited 95 days ago on 06/17/2024. What links here