mfp Tue Jul 26 10:02:09 2005 EDT
Modified files:
/phpdoc/en/reference/sdodasrel reference.xml
Log:
Several edits for spelling, punctuation, making the existing text read more
clearly. No changes to the meaning, no new material.
http://cvs.php.net/diff.php/phpdoc/en/reference/sdodasrel/reference.xml?r1=1.6&r2=1.7&ty=u
Index: phpdoc/en/reference/sdodasrel/reference.xml
diff -u phpdoc/en/reference/sdodasrel/reference.xml:1.6
phpdoc/en/reference/sdodasrel/reference.xml:1.7
--- phpdoc/en/reference/sdodasrel/reference.xml:1.6 Sat Jul 23 07:08:36 2005
+++ phpdoc/en/reference/sdodasrel/reference.xml Tue Jul 26 10:02:08 2005
@@ -1,5 +1,5 @@
<?xml version='1.0' encoding='iso-8859-1'?>
-<!-- $Revision: 1.6 $ -->
+<!-- $Revision: 1.7 $ -->
<!-- Generated by xml_proto.php v2.1. Found in /scripts directory of phpdoc.
-->
<reference id="ref.sdo.das.rel">
<title>SDO Relational Data Access Service Functions</title>
@@ -13,7 +13,7 @@
&warn.experimental;
</para>
<para>
- In order to use the Relational Data Acces Service for
+ In order to use the Relational Data Access Service for
Service Data Objects,
you will need to understand some of the concepts behind SDO:
the data graph, the data object, the disconnected way of working,
@@ -67,15 +67,15 @@
is a normalised data graph containing all the data from the result set.
For a query that returns data obtained from a number of tables,
this graph will contain a number of data objects,
- linked by containment references.
- There may also be non-containment references within the data.
+ linked by SDO containment references.
+ There may also be SDO non-containment references within the data.
</para>
<para>
Once the query has been executed and the data graph constructed,
- there is no need for either the Relational DAS or the
- database connection. There are no locks held on the database.
- Both the Relational Das and the PDO database connection can be
+ there is no need for either that instance of the the Relational DAS or
+ the database connection. There are no locks held on the database.
+ Both the Relational DAS and the PDO database connection can be
garbage collected.
</para>
</step>
@@ -86,7 +86,7 @@
into the PHP session and so may have a lifetime beyond just
one client-server interaction. Data objects can be created
and added to the graph, the data objects already in the graph
- can be deleted, and they can be modified.
+ can be deleted, and data objects in the graph can be modified.
</para>
</step>
<step>
@@ -97,11 +97,11 @@
method of the Relational DAS. For this, another instance
of the Relational DAS must be constructed, using the
same metadata, and another connection to the database obtained.
- These, plus the data graph itself, are passed to
+ The connection and the data graph are passed to
<function>applyChanges</function>.
At this point the Relational DAS examines the change summary
and generates the necessary INSERT, UPDATE and DELETE SQL statements
- to apply the changes. The UPDATE and DELETE statements are qualified
+ to apply the changes. Any UPDATE and DELETE statements are qualified
with the original values of the data so that should the data have
changed in the database in the meantime this will be detected.
Assuming no such collisions have occurred the changes will be
@@ -240,7 +240,7 @@
<para>
The Relational DAS is constructed with metadata that defines the
relational database and how it should be mapped to SDO.
- The first long section describes this metadata and how to
+ The long section that follows describes this metadata and how to
construct the Relational DAS. The examples that follow it all assume that
this metadata is in an included php file.
</para>
@@ -326,7 +326,7 @@
<entry>FK</entry>
<entry>An array with two entries, 'from' and 'to', which define
a column containing a foreign key, and a table to which the foreign
- key points to. If there are no foreign keys in the table then the
+ key points. If there are no foreign keys in the table then the
'FK' entry does not need to be specified. Only one foreign key
can be specified. Only a foreign key pointing to the primary key
of a table can be specified.
@@ -437,16 +437,17 @@
<para>
There are a few simple rules to be followed when constructing the
- database metadata
+ database metadata:
</para>
<itemizedlist>
<listitem>
<para>
- All tables must have primary keys and they must be specified in
- the metadata. Without primary keys it is not possible to keep track
- of object identities. As you see from the SQL statements, primary
- keys can be auto-generated, that is assigned by the database when
+ All tables must have primary keys, and the primary keys must be
+ specified in the metadata. Without primary keys it is not possible
+ to keep track of object identities. As you can see from the SQL
+ statements that create the tables, primary keys can be
+ auto-generated, that is, generated and assigned by the database when
a record is inserted. In this case the auto-generated primary key
is obtained from the database and inserted into the data object
immediately after the row is inserted into the database.
@@ -461,7 +462,7 @@
application did not want to access with SDO, this need not be
specified in the metadata. On the other hand it would have done
no harm to specify it: if specified in the metadata but never
- retrieved, or set by the application, then the unused column
+ retrieved, or assigned to by the application, then the unused column
will not affect anything.
</para>
</listitem>
@@ -491,7 +492,7 @@
The Relational DAS uses the database metadata to form most of the
SDO model. For each table in the database metadata, an SDO type
is defined. Each column which can represent a primitive value
- (this is columns which are not defined as foreign keys) are added
+ (columns which are not defined as foreign keys) are added
as properties to the SDO type.
</para>
<para>
@@ -568,13 +569,12 @@
<varname>dept_id</varname>
column in the employee table) are interpreted as supporting the
SDO containment references.
- Each containment reference mentioned in the SDO containment references
- metadata must have a corresponding foreign key in the database and
- defined in the database metadata. The values of the foreign key
- columns for containment references do not appear in the data objects,
- instead they are represented by the containment reference from the
- parent to the child.
- So the
+ Each containment reference mentioned in the SDO containment references
+ metadata must have a corresponding foreign key present in the
+ database and defined in the database metadata. The values of the
+ foreign key columns for containment references do not appear in the
+ data objects, instead they are represented by the containment reference
+ from the parent to the child. So the
<varname>co_id</varname>
column in the department row in the database, for example, does not
appear as a property on the department type, but instead as a
@@ -590,15 +590,17 @@
<para>
The third foreign key in this example, the
<varname>employee_of_the_month</varname>
+ ,
is handled differently.
This is not mentioned in the SDO containment references metadata.
As a consequence this is interpreted in the second way: it becomes
- a single-valued non-containment reference on the company object
- which can be assigned SDO data object references of the employee type.
- It does appear as a property on the company type. The way to assign a
- value to it in the SDO data graph is to have a graph that contains
- an employee object through the containment references, and to assign
- the object to it. This is illustrated in the later examples below.
+ a single-valued non-containment reference on the company object, to
+ which can be assigned references to SDO data objects of the employee
+ type. It does appear as a property on the company type. The way to
+ assign a value to it in the SDO data graph is to have a graph that
+ contains an employee object through the containment references, and to
+ assign the object to it. This is illustrated in the later examples
+ below.
</para>
</section>
</section> <!--specifying the metadata -->
@@ -1039,7 +1041,8 @@
<para>
Note the way that the company object is actually deleted using the
PHP unset call. The unset has to be performed on the containing
- reference which in this case the company reference on the special
+ reference which in this case is
+ the company reference on the special
root object. You must use:
<programlisting role="php"
id="sdo.das.rel.examples.1cd-CRUD.good-delete">
<