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
, 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
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
. If we simply named it as person_id
the methods would be named without the "AsManager" token (e.g. "GetProjectsArray", "CountProjects",
Also note that GetProjectsAsManagerArray
utilizes the LoadArrayByManagerPersonId
method in the Project
object. Of course, this was generated because manager_person_id
an index (as well as a Foreign Key) in the project
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
tables. Note that login
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
object which can be set, modified, etc. just like the Person
Qcodo also has full support for self-referential tables (e.g. a category
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:
(Note that even though this is being documented here, self-referential tables aren't actually
defined in the Examples Site Database