1. Basic CodeGen
* Reverse Relationships (One-to-One and One-to-Many)
<< * Relationships (Foreign Keys)   |   Back to Main   |   * Many-to-Many Relationships >>

View Source
will open in a new window
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: 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: (Note that even though this is being documented here, self-referential tables aren't actually defined in the Examples Site Database.)

Person's Reverse Relationships with Project (via project.manager_person_id)
and Login (via login.person_id)

Person ID: 7
First Name: Karen
Last Name: Wolfe


Listing of the Project(s) that This Person Manages
• ACME Website1
• ACME Payments

There are 2 project(s) that this person manages.


This Person's Login Object
Username: kwolfe
Password: p@$$.w0rd