Analyzing Reverse Relationships

Although it's a bit hard to understand at first, one of the unique and more powerful features of QCubed is its ability to generate code to handle reverse relationships as well. Given our previous example with the Project and ManagerPerson, we showed how QCubed generated code in the Project class to handle the relationship. But QCubed 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 QCubed will generate the following methods in Person to deal with this reverse relationship:

• getProjectsAsManagerArray()
• countProjectsAsManager()
• associateProjectAsManager()
• unassociateProjectAsManager()
• unassociateAllProjectsAsManager()
• deleteAssociatedProjectAsManager()
• deleteAllProjectsAsManager()

And in fact, QCubed 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. This was generated because manager_person_id is already an index (as well as a foreign key) in the project table.

QCubed'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 Innodb) 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)

QCubed will generate a different set of code if it knows the reverse relationship to be a "Zero 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, QCubed recognizes this as a "Zero- or One-to-One" relationship. So for the reverse relationship, QCubed will not generate the five methods (listed above) in the Person table for the Login relationship. Instead, QCubed 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

QCubed 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 QCubed 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.)

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 Website Redesign
• ACME Payment System

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

This Person's Login Object

• Username: kwolfe
• Password: p@$$.w0rd