Analyzing Reverse Relationships
Although it's a bit hard to undrestand at first, one of the unique and more powerful features of Qcodo
is its ability to generate code to handle reverse relationships as well.
Given our previous example with the
Project and
ManagerPerson, we showed how
Qcodo generated code in the
Project class to handle the relationship. But Qcodo will also geneate
code in the
Person class to handle the reverse aspects of this relationship.
In this case,
Person is on the "to Many" side of a "One to Many" relationship with
Project.
So Qcodo will generate the following methods in
Person to deal with this reverse
relationship:
- GetProjectsAsManagerArray
- CountProjectsAsManager
- AssociateProjectAsManager
- UnassociateProjectAsManager
- UnassociateAllProjectsAsManager
- DeleteAssociatedProjectAsManager
- DeleteAllProjectsAsManager
And in fact, Qcodo will generate the same seven methods for any "One to Many" reverse relationship
(get, count all, associate, unassociate, and unassociate all, delete associated, and delete all associated).
Note that the "AsManager" token in all these methods are there because we named the column in the
project table
manager_person_id. If we simply named it as
person_id,
the methods would be named without the "AsManager" token (e.g. "GetProjectsArray", "CountProjects",
etc.)
Also note that
GetProjectsAsManagerArray utilizes the
LoadArrayByManagerPersonId
method in the
Project object. Of course, this was generated because
manager_person_id is already
an index (as well as a Foreign Key) in the
project table.
Qcodo's Reverse Relationships functionality
is dependent on the data model having indexes defined on all columns that are foreign keys. For many
database platforms (e.g. MySQL) this should not be a problem b/c the index is created implicitly by the engine.
But for some (e.g. SQL Server) platforms, make sure that you have indexes defined on your Foreign Key columns,
or else you forgo being able to use the Reverse Relationship functionality.
Unique Reverse Relationships (e.g. "One to One" Relationships)
Qcodo will generate a different set of code if it knows the reverse relationship to be a "Zero
to One" or "One to One" type of relationship. This occurs in the relationship between
our
login and
person tables. Note that
login.
person_id is a unique
column. Therefore, Qcodo recognizes this as a "Zero- or One-to-One" relationship. So for the
reverse relationship, Qcodo will not generate the five methods (listed above) in the
Person
table for the
Login relationship. Instead, Qcodo generates a
Login property in
Person object which can be set, modified, etc. just like the
Person property in
the
Login object.
Self-Referential Tables
Qcodo also has full support for self-referential tables (e.g. a
category table that
contains a
parent_category_id column which would foreign key back to itself).
In this case, the qcodo will generated the following seven methods to assist with the reverse
relationship for this self-reference:
- GetChildCategoryArray
- CountChildCategories
- AssociateChildCategory
- UnassocaiteChildCategory
- UnassociateAllChildCategories
- DeleteChildCategory
- DeleteAllChildCategories
(Note that even though this is being documented here, self-referential tables aren't actually
defined in the
Examples Site Database.)