From dbb73305b29a8cc3b160688e8977049af785ab32 Mon Sep 17 00:00:00 2001 From: xue <> Date: Sat, 13 Oct 2007 01:48:28 +0000 Subject: Active Record now supports implicitly declared related properties --- .../protected/pages/Database/ActiveRecord.page | 61 ++++++++++++++++------ 1 file changed, 44 insertions(+), 17 deletions(-) (limited to 'demos') diff --git a/demos/quickstart/protected/pages/Database/ActiveRecord.page b/demos/quickstart/protected/pages/Database/ActiveRecord.page index cb10d184..d2793fa1 100644 --- a/demos/quickstart/protected/pages/Database/ActiveRecord.page +++ b/demos/quickstart/protected/pages/Database/ActiveRecord.page @@ -624,7 +624,7 @@ class TeamRecord extends TActiveRecord public $name; public $location; - public $players=array(); + public $players=array(); // this declaration is no longer needed since v3.1.2 //define the $player member having has many relationship with PlayerRecord public static $RELATIONS=array @@ -650,6 +650,16 @@ The second element is a string 'PlayerRecord' that corresponds to the class name of the PlayerRecord class.

+
Note: +As described in the code comment above, since version 3.1.2, related properties no longer +need to be explicitly declared. By default, they will be implicitly declared according to +keys of the $RELATIONS array. A major benefit of declared related properties implicitly +is that related objects can be automatically loaded in a lazy way. For example, assume we have +a TeamRecord instance $team. We can access the players via $team->players, +even if we have never issued fetch command for players. If $players is explicitly declared, +we will have to use the with approach described in the following to fetch the player records. +
+

The foreign key constraint of the Players table is used to determine the corresponding Teams table's corresponding key names. This is done automatically handled @@ -657,9 +667,9 @@ in Active Record by inspecting the Players and Teams table def

Info: -Since version 3.1.2, Active Record supports multiple foreign key +Since version 3.1.2, Active Record supports multiple foreign key references of the same table. Ambiguity between multiple foreign key references to the same table is -resolved by providing the foreign key column name as the 3rd parameter in the relationship array. +resolved by providing the foreign key column name as the 3rd parameter in the relationship array. For example, both the following foreign keys owner_id and reporter_id references the same table defined in UserRecord. @@ -668,8 +678,8 @@ class TicketRecord extends TActiveRecord public $owner_id; public $reporter_id; - public $owner; - public $reporter; + public $owner; // this declaration is no longer needed since v3.1.2 + public $reporter; // this declaration is no longer needed since v3.1.2 public static $RELATION=array ( @@ -679,7 +689,7 @@ class TicketRecord extends TActiveRecord } This is applicable to relationships including BELONGS_TO, HAS_ONE and -HAS_MANY. See section Self Referenced Association Tables for solving ambiguity of MANY_TO_MANY +HAS_MANY. See section Self Referenced Association Tables for solving ambiguity of MANY_TO_MANY relationships.
@@ -709,6 +719,16 @@ and other join conditions are not feasible using Active Records. For queries out scope of Active Record the SqlMap Data Mapper may be considered. +
Info: +The above with approach also works with implicitly declared related properties (introduced +in version 3.1.2). So what is the difference between the with approach and the lazy loading +approach? Lazy loading means we issue an SQL query if a related object is initially accessed and not ready, +while the with approach queries for the related objects once for all, no matter the related objects +are accessed or not. The lazy loading approach is very convenient since we do not need to explictly +load the related objects, while the with approach is more efficient if multiple records are +returned, each with some related objects. +
+

Belongs To Relationship

The "has many" relationship in the above section defines a collection of foreign objects. In particular, we have that a TeamRecord has many (zero or more) @@ -726,9 +746,9 @@ class PlayerRecord extends TActiveRecord public $age; public $team_name; - public $team; - public $skills=array(); - public $profile; + public $team; // this declaration is no longer needed since v3.1.2 + public $skills=array(); // this declaration is no longer needed since v3.1.2 + public $profile; // this declaration is no longer needed since v3.1.2 public static $RELATIONS=array ( @@ -785,7 +805,7 @@ class ProfileRecord extends TActiveRecord public $player_id; public $salary; - public $player; + public $player; // this declaration is no longer needed since v3.1.2 public static $RELATIONS=array ( @@ -830,8 +850,8 @@ class Category extends TActiveRecord public $category_name; public $parent_cat_id; - public $parent_category; - public $child_categories=array(); + public $parent_category; // this declaration is no longer needed since v3.1.2 + public $child_categories=array(); // this declaration is no longer needed since v3.1.2 public static $RELATIONS=array ( @@ -870,7 +890,7 @@ in the Player_Skills association table using an inner join.

The Prado Active Record design implements the two stage approach. For the -Players-Skills M-N (many-to-many) entity relationship, we +Players-Skills M-N (many-to-many) entity relationship, we define a many-to-many relationship in the PlayerRecord class and in addition we may define a many-to-many relationship in the SkillRecord class as well. The following sample code defines the complete SkillRecord class with a @@ -885,7 +905,7 @@ class SkillRecord extends TActiveRecord public $skill_id; public $name; - public $players=array(); + public $players=array(); // this declaration is no longer needed since v3.1.2 public static $RELATIONS=array ( @@ -910,10 +930,10 @@ of the association table name.

Note: -Prior to version 3.1.2 (versions up to 3.1.1), the many-to-many relationship was +Prior to version 3.1.2 (versions up to 3.1.1), the many-to-many relationship was defined using self::HAS_MANY. For version 3.1.2 onwards, this must be changed to self::MANY_TO_MANY. This can be done by searching for the HAS_MANY in your -source code and carfully changing the appropriate definitions. +source code and carfully changing the appropriate definitions.

@@ -975,7 +995,7 @@ class Item extends TActiveRecord //additional foreign item id defined in the association table public $related_item_id; - public $related_items=array(); + public $related_items=array(); // this declaration is no longer needed since v3.1.2 public static $RELATIONS=array ( @@ -1030,6 +1050,13 @@ PlayerSkillAssocation::finder()->deleteByPk(array('fk1','fk2'));

Lazy Loading Related Objects

+ +
Note: +Implicitly declared related properties introduced in version 3.1.2 automatically have lazy +loading feature. Therefore, the lazy loading technique described in the following is no longer +needed in most of the cases, unless you want to manipulate the related objects through getter/setter. +
+

Using the with_xxx() methods will load the relationship record on demand. Retrieving the related record using lazy loading (that is, only when those related objects are accessed) can be achieved by using a feature of the TComponent that provides accessor methods. In particular, -- cgit v1.2.3