2. More About the Object Relational Model
* Early Binding of Related Objects
<< * Late Binding of Related Objects   |   Back to Main   |   * Virtual Attributes >>

View Source
will open in a new window
Early Binding: Using Object Expansion
(Note: for more information about "QQ::"-related classes (a.k.a. Qcodo Query), please refer to section 3 of the Examples Site.)

When you need to perform LoadAll or LoadArray calls, and would like to include related objects in order to limit round tripping, you can use Qcodo's Object Expansion functionality to specify which Foreign Key columns that you want to expand immediately.

The Object Expansion function, which is generated into each object in the ORM, will bind these related objects when the objects are initially created, thus the term "early binding".

In our example here, we will perform the exact same task as the previous example, pulling all the Project objects and displaying each object's ManagerPerson. Note that the only difference in our code is that we've added a QQ::Expand() clause. There is no other difference with the way we access the restored objects and their related objects.

The end result is that instead of displaying the data using 5 queries, we have now cut this down to just 1 query. This is accomplished because of the LEFT JOIN which is executed by the code generated ORM and the passed in QQ::Expand() clause.

But more importantly, because the way we access the objects is the exact same, this kind of round trip optimization can be done after the page is functional and complete. This follows the general philosophy of Qcodo, which is to first focus on making your application functional, then focus on making your application more optimized. The value of doing this is because often engineers can get bogged down on making an application as optimized as possible, and in doing so they can unnecessarily overengineer some pieces of functionality. If the focus is on getting the application functional, first, then after the application is in a usable state, you can profile the functionality that tends to get used more often and simply focus on optimizing this smaller subset of heavily-used functionality.

For information about Expanding through Association Tables, please refer to the "Handling Association Tables" example in Section 3.

List All the Projects and View Its Manager

ACME Website Redesign is managed by Karen Wolfe
State College HR System is managed by Mike Ho
Blueman Industrial Site Architecture is managed by John Doe
ACME Payment System is managed by Karen Wolfe

PROFILING INFORMATION FOR DATABASE CONNECTION #1: 2 queries performed. Please click here to view profiling detail