Author: Peter Keung
Date: 2007-02-08 00:46:30 +0100 (Thu, 08 Feb 2007)
New Revision: 4636
Log:
Edited PersistentObject eZ Component tutorial
Modified:
trunk/PersistentObject/docs/tutorial.txt
Modified: trunk/PersistentObject/docs/tutorial.txt
===================================================================
--- trunk/PersistentObject/docs/tutorial.txt 2007-02-07 22:26:26 UTC (rev
4635)
+++ trunk/PersistentObject/docs/tutorial.txt 2007-02-07 23:46:30 UTC (rev
4636)
@@ -1,43 +1,41 @@
-eZ components - PersistentObject
+eZ Components - PersistentObject
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
.. contents:: Table of Contents
Introduction
============
-Persistent Object provides object persistence using a database for PHP
-5. Persistent Object uses the Database components to provide database
+The PersistentObject component provides object persistence for PHP 5 using a
+database. PersistentObject uses the Database component to provide database
abstraction. It does not rely on code generation and does not force a specific
inheritance structure to work.
-Persistent Object is built to be fast and flexible allowing you to build your
+
+PersistentObject is built to be fast and flexible, allowing you to build
persistent classes in the same way as any other class in your application.
-The PersistentObjectDatabaseSchemaTiein allows you to automatically generate
-the definition files needed by PersistentObject from a database schema or the
-structure of your database. For more information, please refer to
-ezcPersistentObjectSchemaGenerator.
+The PersistentObjectDatabaseSchemaTiein component allows you to automatically
+generate the definition files needed by PersistentObject from a database schema
+or the structure of your database. For more information, please refer to
+the API documentation on ezcPersistentObjectSchemaGenerator.
Class overview
==============
-This section gives you an overview of the main classes of Persistent Object.
+ezcPersistentSession is the main API for interacting with the persistent
+objects. Loading, saving and deleting persistent objects is done through
+this class.
-ezcPersistentSession
- ezcPersistentSession is the main API for interaction with the object
- persistence. Loading, saving and deleting persistent objects is done through
- this class.
-
-Basic Usage
+Basic usage
===========
-This chapter describes typical usage of the Persistent Object package with a
-single persistent class using MySQL as the persistence storage.
+This chapter describes the typical usage of PersistentObject with a
+single persistent class, using MySQL as the persistence storage.
The persistent class
--------------------
We want to make a simple class, representing a person, persistent using
-persistent object. It is a simple class with only a few members: ::
+a persistent object. This is a simple class with only a few members: ::
<?php
class Person
@@ -70,16 +68,16 @@
is a required unique identifier for this persistent object. It is generated by
the identifier generator and usually maps to an auto increment column in the
database.
-For simplicity we have made the name and age members of the Person class
+
+For simplicity, we have made the name and age members of the Person class
public. However, this is not required and in a real application you can use
-any access method you like e.g. access methods or properties or even having
the
-data completely private.
+any access method you like. You can even make the data completely private.
All persistent objects must implement the getState() and setState()
methods. They are used to retrieve the state of the object when saving it and
to set it when loading it. The getState() method should always return the
-complete state of the object while the setState() method should be prepared to
-only set one member at the time.
+complete state of the object while the setState() method should set
+only one member at the time.
The persistence mapping
@@ -101,10 +99,11 @@
required for the id generator that we will use. Other id generators may have
other requirements to work as expected.
-In order for Persistent Object to be able to store objects of the Person class
-into the persons table we need to tell it how the columns are mapped to class
-members. We will use the ezcPersistentCodeManager to fetch the definitions when
-required.
+In order for PersistentObject to be able to store objects of the Person class
+into the persons table, we need to tell it how the columns are mapped to class
+members. We will use ezcPersistentCodeManager to fetch the definitions when
+required.
+
ezcPersistentCodeManager requires us to define the mapping using the
ezcPersistentObjectDefinition, ezcPersistentObjectIdProperty and
ezcPersistentObjectProperty classes: ::
@@ -135,8 +134,8 @@
The first block of code creates the definition object and sets the database
table and the name of the class to map. The second block defines the mapping of
the identifier member and the algorithm that should be used to create
-identifiers for new objects. We will use the ezcPersistentSequenceGenerator
-which simply retrieves the new identifier generated by auto_increment.
+identifiers for new objects. We will use ezcPersistentSequenceGenerator,
+which simply retrieves the new id generated by auto_increment.
The next two code blocks define the mapping between the database columns and
the class members. It is possible to use the same name in the class and the
@@ -144,23 +143,23 @@
The members must be inserted into the properties member, which is an
associative array, using the name of the member as the key name.
-If you look at the API of ezcPersistentObjectDefinition
-it also has a property named 'columns' which is the same array as the
-'properties' except it is mapped on the column names instead of the property
-names. This reverse mapping is set up by the ezcPersistentCodeManager.
+If you look at the API for ezcPersistentObjectDefinition,
+it also has a property named "columns" that is the same array as the
+"properties", except that it is mapped to the column names instead of the
property
+names. This reverse mapping is set up by ezcPersistentCodeManager.
-Finally we return the complete definition. Your definition will not work unless
+Finally, we return the complete definition. Your definition will not work
unless
you return it to the manager.
-To make the definition work with the ezcPersistentCodeManager it must be put in
+To make the definition work with the ezcPersistentCodeManager, it must be put
in
a separate PHP file and given the name of the class in lowercase letters. In
-our example it should be put in a file named person.php.
+our example, the filename should be person.php.
The session object
------------------
The session object is in charge of the actual loading and saving of persistent
-objects. A session can be created simply by instantiating it: ::
+objects. A session can be created by simply instantiating it: ::
<?php
$session = new ezcPersistentSession(
@@ -170,14 +169,14 @@
?>
The session takes two arguments: a pointer to the database instance to use and
-the manager it should use to retrieve persistent object definitions. We are
-using the ezcPersistentCodeManager which loads the definitions directly from
+the manager from which to retrieve persistent object definitions. We are
+using ezcPersistentCodeManager to load the definitions directly from
file. You should point it to the location where you saved the person.php
-file. If you have several directories containing your definitions you can use
+file. If you have several directories containing definitions, you can use
the ezcPersistentMultiManager class to add as many as you like.
While it is possible to create a new session each time you want to manipulate a
-persistent object you will probably want to use the same session each
+persistent object, you will probably want to use the same session each
time. This functionality can be achieved by using the
ezcPersistentSessionInstance class: ::
@@ -192,8 +191,9 @@
Creating and updating an object
-------------------------------
-Creating a new Person object and making it persistent is straight forward: ::
+Creating a new Person object and making it persistent is straightforward: ::
+
<?php
$object = new Person();
$object->name = "Guybrush Threepwood";
@@ -204,10 +204,10 @@
This code saves our newly created object to the database and generates an id
for it. The id is set to the id property of the object. Since Guybrush is our
-first person he will get the identifier 1.
+first person, he is assigned the id of 1.
-Of course, the age of Guybrush Threepwood is the source of much debate and most
-probably he is younger than 31. To make the change simply edit the object and
+Of course, the age of Guybrush Threepwood is the source of much debate, and he
+is probably younger than 31. To change his age, simply edit the object and
tell the session to update it. ::
<?php
@@ -230,9 +230,9 @@
This code retrieves the Guybrush object created above.
-If you have stored a lot of persistent objects to the database and you want to
retrieve a
-list you can use the find method. The find method requires a query parameter
which you
-can retrieve from the session first. ::
+If you have stored a lot of persistent objects to the database and want to
retrieve a
+list, you can use the find() method. The find() method requires a query
parameter
+that can first be retrieved from the session. ::
<?php
$q = $session->createFindQuery( 'Person' );
@@ -242,8 +242,8 @@
$objects = $session->find( $q, 'Person' );
?>
-This code will fill fetch a maximum of 10 Person objects older than 15 years
-sorted by their names.
+This code will fetch a maximum of 10 Person objects where the age is
+higher than 15, sorted by name.
The find() method will fetch the complete result set and instantiate it for
you. This is not desirable if you are fetching large numbers of objects and you
@@ -264,13 +264,13 @@
?>
This code will produce the same result as the first find() example. However,
-only one object will be instantiated and the data will be transfered from the
+only one object will be instantiated and the data will be transferred from the
database only when it is needed.
Deleting objects
-----------------
-The easiest way to delete persistent objects is to use the delete method() on
+The easiest way to delete persistent objects is to use the delete() method on
the session: ::
<?php
@@ -279,7 +279,7 @@
?>
Of course, you can only delete instantiated objects this way. If you want to
-delete an object or a whole series of objects that are not instantiated you can
+delete an object or a whole series of objects that are not instantiated, you
can
use the deleteFromQuery() method: ::
<?php
@@ -288,26 +288,26 @@
$session->deleteFromQuery( $q );
?>
-When executed the above code will remove all persons older than 15 years old
-from the database.
+The above code will remove all persons from the database who are more than 15
+years old.
Identifier generation
=====================
-All persistent objects are required to have an identifier field. The identifier
-generation algorithm defines how the system will generate IDs for new
+All persistent objects must have an identifier field. The identifier
+generation algorithm defines how the system will generate ids for new
objects. This chapter describes the available generators.
ezcPersistentSequenceGenerator
------------------------------
The sequence generator relies on the PDO::lastInsertId() method to retrieve the
-IDs for newly created persistent objects.
+ids for newly created persistent objects.
-For databases supporting auto_increment (like MySQL and SQLite) the usage of
-ezcPersistentNativeGenerator. Other databases need to use a sequence. E.g
-for PostgreSQL the person table definition should look like: ::
+For databases supporting auto_increment (like MySQL and SQLite), use
+ezcPersistentNativeGenerator. Other databases must use a sequence. For example,
+the PostgreSQL person table definition should be as follows: ::
CREATE TABLE persons
(
@@ -318,8 +318,8 @@
);
CREATE SEQUENCE person_seq START 1;
-If your database requires you to use a sequence this parameter should be
-provided to the ezcPersistentSequenceGenerator in the mapping definition. ::
+If your database requires you to use a sequence, this parameter should be
+provided to ezcPersistentSequenceGenerator in the mapping definition. ::
<?php
$def->idProperty->generator = new ezcPersistentGeneratorDefinition(
@@ -331,8 +331,8 @@
ezcPersistentNativeGenerator
----------------------------
-The native generator relies on auto_increment, which is supported by e.g. MySQL
-and SQLite. A table definition for this looks like that: ::
+The native generator relies on auto_increment, which is supported by, among
+others, MySQL and SQLite. An example table definition looks like this: ::
CREATE TABLE persons
(
@@ -342,7 +342,7 @@
PRIMARY KEY (id)
);
-The according generator definition: ::
+The corresponding generator definition is below: ::
<?php
$def->idProperty->generator = new ezcPersistentGeneratorDefinition(
@@ -355,7 +355,7 @@
If you do not rely on a database mechanism to generate values for a primary
key column, you have to use the ezcPersistentManualGenerator class. You can
-then set the value of the ID property by hand and save the object afterwards.
+then set the value of the id property by hand and save the object afterwards.
For example: ::
@@ -367,8 +367,8 @@
PRIMARY KEY (login)
);
-In this table you use a string value as the primary key and therefore have to
-generate ID values manually. Use the following definition: ::
+In this table, the string value is used as the primary key. Therefore, we have
+to generate id values manually. Use the following definition: ::
<?php
$def->idProperty->generator = new ezcPersistentGeneratorDefinition(
@@ -376,12 +376,12 @@
);
?>
-And for saving a new instance the following code: ::
+For saving a new instance, use the following code: ::
<?php
$object = new Person();
- // Manually set the ID
+ // Manually set the id
$object->login = "guybrush";
$object->name = "Guybrush Threepwood";
@@ -395,13 +395,14 @@
The session object needs to be able to fetch the persistent object
definitions in order to function properly. The task of fetching the definitions
-is performed by a definition loader which is provided to the session when it is
+is performed by a definition loader, which is provided to the session when it
is
instantiated.
ezcPersistentCodeManager
-------------------------
+
This is currently the only manager available. It simply reads the definition
-from a file named the same as the class from the specified directory. It does
+from a file with the same name as the class from the specified directory. It
does
not perform any error checking on the definition and simply assumes that it is
correct.
@@ -410,8 +411,8 @@
-------------------------------
It is very easy to create your own definition loader. Simply extend the
-ezcPersistentDefinitionManager abstract class and implement the fetchDefinition
-method: ::
+ezcPersistentDefinitionManager abstract class and implement the
+fetchDefinition() method: ::
<?php
class ezcPersistentCodeManager extends ezcPersistentDefinitionManager
@@ -423,7 +424,7 @@
?>
The fetchDefinition() method should create the definition structure for the
-requested class or throw an exception
+requested class or throw an exception.
Relations
=========
@@ -436,17 +437,18 @@
The following definition classes are available to realize object relations:
ezcPersistentOneToManyRelation
- This class is used to define 1:n relations. For example 1 person can be
- related to multiple addresses, while only 1 person can live at an address.
+ This class is used to define 1:n relations. For example, one person might be
+ related to multiple addresses, but one address might only be related to
+ one person.
ezcPersistentManyToManyRelation
- Using this class you can define n:m relations, for example a person can be
- related to multiple addresses, while multiple persons can live at one
- address.
+ Using this class, you can define n:m relations. For example, a person can be
+ related to multiple addresses, while an address can be related to multiple
+ persons.
ezcPersistentOneToOneRelation
With this class you can define 1:1 relations, which might be useful for
- slight de-normalization. For example, if you want to split your users data
+ slight de-normalization. For example, you can split your user data
from the user credentials.
ezcPersistentManyToOneRelation
@@ -455,11 +457,11 @@
All of these classes extend the abstract class ezcPersistentRelation.
-Basics for the following examples
----------------------------------
+Relations basics
+----------------
-For the examples in this section, we will reuse the Person class, define in
-`The persistent class`_. In addition, we will use a class Address, which looks
+For the examples in this section, we will reuse the Person class, defined in
+`The persistent class`_. In addition, we will use an Address class, which looks
as follows::
<?php
@@ -490,7 +492,7 @@
}
?>
-The Address class will be extended later on to include the relation. The
+The Address class will be extended later on to include relations. The
following basic persistence mapping is used and extended for each example::
<?php
@@ -524,9 +526,9 @@
Defining a simple relation
--------------------------
-The following extensions are necessary to the given class and persistence
+The following extensions are necessary for the given class and persistence
mapping, to realize a simple 1:n relation. Each person will be able to have
-multiple addresses, but 1 address may only refer to 1 person.
+multiple addresses, but one address may only refer to one person.
The Address class needs to be enhanced as follows, to store the id of the
Person it is related to. ::
@@ -589,13 +591,13 @@
array. An instance of one of the classes shown in `Class overview`_ must be the
value. In this case, it is ezcPersistentOneToManyRelation. The parameter to its
constructor are the names of the tables that the relation refers to. The first
-table is the table of the current object, the second one refers to the related
+table is the table of the current object, and the second one refers to the
related
object.
To define which properties are used to realize the relation mapping, the
property ezcPersistentOneToManyRelation->columnMap is used. It contains an
array of (in this case) ezcPersistentSingleTableMap, which maps one column of
-each of the tables to one column of the other one. In the above case, the
+each of the tables to one column of another. In the above case, the
database column "id" from the table "persons" would be mapped to the column
"person_id" in the table "addresses". In general, this means, that "id" is the
primary key from the "persons" table and "person_id" is the foreign key in the
@@ -603,7 +605,7 @@
If you want to map using several columns, you can add more
ezcPersistentSingleTableMap instances to the columnMap array. For example, if
-you are using a persons first and last name as the primary key for the
+you are using a person's first and last name as the primary key for the
"persons" table, you could define the relation like this: ::
<?php
@@ -638,24 +640,24 @@
object. If no related object can be found, it will throw an exception.
ezcPersistentSession->getRelatedObjects()
- In contrast to ezcPersistentSession->getRelatedObject() this method returns
- always an array of all related objects. It will not throw an exception if no
- related object can be found, but return an empty array.
+ In contrast to ezcPersistentSession->getRelatedObject(), this method always
+ returns an array of all related objects. It will not throw an exception if no
+ related object can be found, but will instead return an empty array.
ezcPersistentSession->addRelatedObject()
- Using this method you can build a relation between 2 persistent objects. It
- will set the defined properties on the objects, but does not store those to
- the database automatically. (A little exception are
- ezcPersistentManyToManyRelation objects. Further details below.)
+ Using this method, you can build a relation between two persistent objects.
It
+ will set the defined properties on the objects, but does not store them to
+ the database automatically. (Exceptions are
+ ezcPersistentManyToManyRelation objects. Further details are below.)
ezcPersistentSession->removeRelatedObject()
As the counterpart to ezcPersistentSession->addRelatedObject(), this method
- is used to remove the relation between 2 objects. It won't store the given
- objects for you, but only remove the necessary properties. (Again a little
- exception are ezcPersistentManyToManyRelation objects. Further details
+ is used to remove the relation between two objects. It will not store the
given
+ objects for you, but only remove the necessary properties. (Again, exceptions
+ are ezcPersistentManyToManyRelation objects. Further details are
below.)
-Using these methods, we can now retrieve all addresses which are related to one
+Using these methods, we can now retrieve all addresses that are related to one
person::
<?php
@@ -664,8 +666,8 @@
?>
The variable $addresses will then contain an array of all Address objects found
-for the Person object with ID 1. To relate these addresses to another Person
-object, we can do the following::
+for the Person object with an id of 1. To relate these addresses to another
+Person object, we can do the following::
<?php
@@ -684,13 +686,13 @@
Defining n:m relations
----------------------
-The eczPersistentManyToManyRelation class works slightly different compared to
+The eczPersistentManyToManyRelation class works slightly different than
the other ezcPersistentRelation classes. For this kind of relation, you need an
-extra table in your database, to store the relation records. The next example
-shows the definition of an ezcPersistentManyToManyRelation relation on basis of
-the Person and Address example classes allowing each person to have several
-addresses and each address to be used by several persons. You need to use the
-original example classes for this, hence we do not need to extend those here.
+extra table in your database to store the relation records. The next example
+shows the definition of an ezcPersistentManyToManyRelation relation, based on
+the Person and Address example classes. Each person can have several
+addresses and each address can be used by several persons. You need to use the
+original example classes for this, thus we do not need to extend them here.
The definition of the relational mapping for the Person class must be extended
as follows::
@@ -710,28 +712,28 @@
?>
In contrast to all other implementations of ezcPersistentRelation, the
-ezcPersistentManyToManyRelation constructor expects 3 table names:
+ezcPersistentManyToManyRelation constructor expects three table names:
-- The name of the current objects table.
-- The name of the related objects table.
-- The table name to store the relation records into.
+- the name of the current objects table
+- the name of the related objects table
+- the table name to store the relation records
-A similar exception applies to the columnMap of this relation definition: It
-consists of ezcPersistentDoubleTableMap instances, which carry 4 column names
+A similar exception applies to columnMap of this relation definition. It
+consists of ezcPersistentDoubleTableMap instances, which carry four column
names
each. The first column is the column to choose from the source table (usually
-its primary key). The second column defines the column in your relation table,
-which maps to the first column. In our example, the column "id" from the
+its primary key). The second column defines the column in your relation table
+that maps to the first column. In our example, the column "id" from the
"persons" table maps to the column "person_id" from the relation table
-"persons_addresses". The same applies to the 3rd and 4th column. The third
-column defines the column of the relation table, which maps to the 4th column
-given. The latter one defines the column of your destination table to use for
-mapping. So in our example, the relation table "persons_addresses" has a column
-"address_id", which is a foreign key, referring to the column "id" in the table
+"persons_addresses". The same applies to the third and fourth columns. The
third
+column defines the column of the relation table that maps to the fourth column
+given. The fourth column specifies the column of your destination table to use
for
+mapping. In our example, the relation table "persons_addresses" has a column
+"address_id", which is a foreign key referring to the column "id" in the table
"addresses".
As with ezcPersistentSingleTableMap instances, you can use multiple
-mappings in one ezcPersistentManyToManyRelation->columnMap array. Again the
-example, of using a persons first and last name for the mapping: ::
+mappings in one ezcPersistentManyToManyRelation->columnMap array. Here, we use
+a person's first and last name for the mapping: ::
<?php
// ...
@@ -752,25 +754,25 @@
Using n:m relations
-------------------
-As stated earlier, the usage methods behave slightly different when dealing
-with n:m relations. If you use ezcPersistentSession->addRelatedObject() the
-desired relation record is inserted into the relation table. Same applies to
the
+As stated earlier, the usage methods behave slightly differently when dealing
+with n:m relations. If you use ezcPersistentSession->addRelatedObject(), the
+desired relation record is inserted into the relation table. The same applies
to the
removeRelatedObject() method of ezcPersistentSession, which deletes the
specific
-record. This also means, that you do not need to store the affected objects
+record. This also means that you do not need to store the affected objects
explicitly after altering the relations between them. If you have made other
-changes to the objects they must be stored to save the changes.
+changes to the objects, they must be stored to save the changes.
-Beside that, the ezcPersistentSession->delete() method keeps track of the
-relation records. If you delete a record, all it's relation records are deleted
-automatically.
+Aside from that, the ezcPersistentSession->delete() method keeps track of the
+relation records. If you delete a record, all of its relation records are
+automatically deleted.
Special 1:1 relations
---------------------
-If you desire to use 1:1 relations, where two tables share a common primary
key,
-you need to define 1 table to generate the key and the other table to use the
+If you want to use 1:1 relations, where two tables share a common primary key,
+you need to define a table to generate the key and the other table to use
ezcPersistentManualGenerator. For our example, if one person may only have one
-address, this could look like that: ::
+address, the definition would be as follows: ::
<?php
$def = new ezcPersistentObjectDefinition();
@@ -785,7 +787,7 @@
return $def;
?>
-And for the relation (defined in the definition file of the Person): ::
+This is the relation (defined in the definition file of the Person): ::
<?php
// ...
@@ -804,31 +806,32 @@
return $def;
?>
-If you let both tables use an ezcPersistentSequenceGenerator for the same key,
-ezcPersistentSession will fail to save a related object, since the ID will
+If you let both tables use ezcPersistentSequenceGenerator for the same key,
+ezcPersistentSession will fail to save a related object, since the id will
already be set by the ezcPersistentSession::addRelatedObject() method.
-Another way to make this working is, to not use the same primary key for both
-tables, but to make the Address object have its own ID and only use the Persons
-ID as a foreign key.
+Another way to make this work is to not use the same primary key for both
+tables, but to make the Address object have its own id and only use the Person
+id as a foreign key.
Reverse relations
-----------------
Since you can always look at a relation from two sides, ezcPersistentRelation
implementations can be configured to be "reverse". A reverse relation
-indicates, that the relation is already defined in the opposite direction and
-that the original direction is the main used one. This implied, that the one
-marked as "reverse" is a secondary one, for consistency reasons. For a
relation that is marked as
-reverse, it is not possible to use ezcPersistentSession->addRelatedObject() and
-ezcPersistentSession->removeRelatedObject(). You can still you
+indicates that the relation is already defined in the opposite direction and
+that the original direction is the main used one. The one
+marked as "reverse" is a secondary one, for consistency reasons. For a relation
+that is marked as reverse, it is not possible to use
+ezcPersistentSession->addRelatedObject() and
+ezcPersistentSession->removeRelatedObject(). You can still use
ezcPersistentSession->getRelatedObjects() for relations that are flagged
"reverse".
-For most relation types the reverse attribute of the relation definition object
-is per default set to false. You can manually set it. An exception are
+For most relation types, the reverse attribute of the relation definition
object
+is set to false by default. You can manually set it. Exceptions are
ezcPersistentManyToOneRelation relations. This relation type only makes sense
-as a reverse relation for a ezcPersistentOneToManyRelation. Therefore the
+as a reverse relation for ezcPersistentOneToManyRelation. Therefore, the
reverse attribute is set to false for ezcPersistentManyToOneRelation and is not
publicly accessible for writing.
@@ -851,8 +854,8 @@
return $def;
?>
-With the relation definition shown above, you would still be able to get the
-Person objects related to an Address object, but not to add or remove related
+With the relation definition shown above, you would still be able to relate the
+Persons object to an Address object, but not to add or remove related
Person objects to/from an Address. In other words, the following code still
works: ::
@@ -862,7 +865,7 @@
// ...
?>
-While the following won't work: ::
+While the following would not work: ::
<?php
// ...
@@ -886,14 +889,14 @@
Cascading deletes
-----------------
-Cascading relations is done through the flag "cascade" of a
-ezcPersistentRelation implementation. All implementations, except the
-ezcPersistentManyToManyRelation class support this flag. It allows you to get
-all related objects for a source object automatically deleted, if the source
+Cascading relations are done through the flag "cascade" of a
+ezcPersistentRelation implementation. All implementations except the
+ezcPersistentManyToManyRelation class support this flag. It allows you to
+automatically delete all related objects for a source object when the source
object is deleted.
-The following example shows how to add cascading to a relation definition,
-based on the example from `Defining a simple relation`_::
+The following example shows how to add a cascading relation to a relation
+definition, based on the example from `Defining a simple relation`_::
<?php
// ...
@@ -913,16 +916,16 @@
return $def;
?>
-If you now use ::
+If you now use the following, the Person object and all related Address objects
+are deleted: ::
<?php
$person = $session->load( "Person", 1 );
$session->delete( $person );
?>
-The Person object and all related Address objects are deleted. Beware, that
-this does not work with ezcPersistentManyToManyRelation instances, because it
-could cause serious inconsistency of your data.
+Beware that this does not work with ezcPersistentManyToManyRelation instances,
+because it could cause serious inconsistencies in your data.
--
svn-components mailing list
svn-components@lists.ez.no
http://lists.ez.no/mailman/listinfo/svn-components
