From c1bddf3826ec570ea4c58d7a56c410ae54d26508 Mon Sep 17 00:00:00 2001 From: wei <> Date: Fri, 4 May 2007 00:22:46 +0000 Subject: Add more qs docs for ar relationships --- .../protected/pages/Database/ActiveRecord.page | 194 +++++++++++++++++++-- 1 file changed, 179 insertions(+), 15 deletions(-) (limited to 'demos/quickstart/protected/pages/Database') diff --git a/demos/quickstart/protected/pages/Database/ActiveRecord.page b/demos/quickstart/protected/pages/Database/ActiveRecord.page index 99c7acf8..adcb7783 100644 --- a/demos/quickstart/protected/pages/Database/ActiveRecord.page +++ b/demos/quickstart/protected/pages/Database/ActiveRecord.page @@ -42,7 +42,7 @@
The Active Record class has methods that do the following: -
+Support for other databases can be provided when there are sufficient demand.
@@ -101,9 +101,8 @@ class UserRecord extends TActiveRecord specify the table name that corresponds to your Active Record class. -
@@ -145,7 +144,7 @@ will raise an exception.
See Establishing Database Connection for
futher details regarding creation of database connection in general.
+
Active Record objects have a simple life-cycle illustrated in the following diagram. +
alt="Active Records Life Cycle" id="fig:cycle.png" class="figure"/> -We see that new ActiveRecord objects are created by either using one of the find*() ++We see that new TActiveRecord objects are created by either using one of the find*() methods or using creating a new instance by using PHP's new keyword. Objects created by a find*() method starts with clean state. New instance of -ActiveRecords created other than by a find*() method starts with new state. +TActiveRecord created other than by a find*() method starts with new state. When ever you -call the save() method on the ActiveRecord object, the object enters the clean +call the save() method on the TActiveRecord object, the object enters the clean state. Objects in the clean becomes dirty whenever one of more of its internal states are changed. Calling the delete() method on the object ends the object life-cycle, no futher actions can be performed on the object. @@ -419,13 +420,13 @@ catch(Exception $e) // an exception is raised if a query fails
-The Prado ActiveRecord implementation supports the foreign key mappings for database +The Prado Active Record implementation supports the foreign key mappings for database that supports foreign key contraints. For ActiveRecord relationships to function the underlying database must support foreign key constraints (e.g. MySQL with InnoDB).
-In the following sections we shall consider the following entity relationship between +In the following sections we shall consider the following table relationships between Teams, Players, Skills and Profiles.
@@ -437,11 +438,174 @@ relationships in the above figure. ++There is a mismatch between relationships with objects and table relationships. +First there's a difference in representation. Objects handle links by storing references +that are held by the runtime memory-managed environment. Relational databases handle +links by forming a key into another table. Second, objects can easily use collections +to handle multiple references from a single field, while normalization forces +all entity relation links to be single valued. This leads to reversals of the data +structure between objects and tables. The approach taken in the Prado Active Record +design is to use the table foreign key constraints to derive object relationships. This implies +that the underlying database must support foreign key constraints. +
The entity relationship between the Teams and Players table is what is known +as an 1-M relationship. That is, one Team may contain 0 or more Players. In terms of +object relationships, we say that the Team object has many Player objects. +(Notice the reversal of the reversal of the direction of relationships between tables and objects.) +
+
+We model the Team object as the following Active Record classes. +
++The static $RELATIONS property of TeamRecord defines that the +property $players has many PlayerRecords. Multiple relationships +is permitted by defining each relationship with an entry in the $RELATIONS +array where array key for the entry corresponds to the property name. +In array(self::HAS_MANY, 'PlayerRecord'), the first element defines the +relationship type, the valid types are self::HAS_MANY, +self::HAS_ONE and self::BELONGS_TO. +The second element is a string 'PlayerRecord' that corresponds to the +class name of the PlayerRecord class. +
+ ++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 +in Active Record by inspecting the Players and Teams table definitions. +
+ +The has many relationship is not fetched automatically when you use any of the Active Record finder methods. +You will need to explicitly fetch the related objects as follows. In the code below, both lines +are equivalent and the method names are case insensitive. +
++The method with_xxx() (where xxx is the relationship property +name, in this case, players) fetchs the corresponding PlayerRecords using +a second query (not by using a join). The with_xxx() accepts the same +arguments as other finder methods of TActiveRecord, e.g. with_players('age < ?', 35). +
+ +