db-jdo-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From an...@apache.org
Subject svn commit: r584516 - in /db/jdo/site: docs/glossary.html docs/object_retrieval.html xdocs/glossary.xml xdocs/object_retrieval.xml
Date Sun, 14 Oct 2007 08:56:21 GMT
Author: andyj
Date: Sun Oct 14 01:56:21 2007
New Revision: 584516

URL: http://svn.apache.org/viewvc?rev=584516&view=rev
Log:
JDO-537 Fix link in object retrieval, and add info to glossary

Modified:
    db/jdo/site/docs/glossary.html
    db/jdo/site/docs/object_retrieval.html
    db/jdo/site/xdocs/glossary.xml
    db/jdo/site/xdocs/object_retrieval.xml

Modified: db/jdo/site/docs/glossary.html
URL: http://svn.apache.org/viewvc/db/jdo/site/docs/glossary.html?rev=584516&r1=584515&r2=584516&view=diff
==============================================================================
--- db/jdo/site/docs/glossary.html (original)
+++ db/jdo/site/docs/glossary.html Sun Oct 14 01:56:21 2007
@@ -16,8 +16,10 @@
                         the object is retrieved. Some field types default to being in the
<B>default-fetch-group</B> (e.g primitives, 
                         wrappers to primtives, java.util.Date) and others (e.g java.util.Set,
java.util.List) don't.</td></tr><a name="embedded"></a><tr class="b"><td>embedded</td><td>A
field can be defined as embedded if it will be stored as a column in the table of its containing
object.</td></tr><a name="enhancer"></a><tr class="a"><td>enhancer</td><td>JDO
1.0.1 requires the use of a byte-code enhancer that takes the Java compiled classes and "enhances"
them, 
                         adding in information to permit their use in a JDO environment.</td></tr><a
name="fco"></a><tr class="b"><td>FCO</td><td>JDO defines
2 main groups of Java objects. The first is those objects that have an identity. These are
-                        termed "First Class Objects" or FCO for short.</td></tr><a
name="JDOQL"></a><tr class="a"><td>JDOQL</td><td>JDO introduces
its own Java-like query language as a datastore independent way of retrieving objects from

-                        the datastore. This is known as JDOQL (JDO Query Language).</td></tr><a
name="objectid-class"></a><tr class="b"><td>objectid class</td><td>When
an object of a class is persisted, it is assigned an object identity. When the developer has
chosen to 
+                        termed "First Class Objects" or FCO for short.</td></tr><a
name="fetchgroup"></a><tr class="a"><td>Fetch Group</td><td>JDO
allows a user to define groups of fields that should be retrieved (fetched) at the same time.
These are called a "fetch group".
+                        The principal "fetch group" is the "default fetch group", where JDO
has rules for what fields are in this group. 
+                        A user can define their own group, and make this active so that when
objects of their type are retrieved, they have control over the fetching process.</td></tr><a
name="JDOQL"></a><tr class="b"><td>JDOQL</td><td>JDO introduces
its own Java-like query language as a datastore independent way of retrieving objects from

+                        the datastore. This is known as JDOQL (JDO Query Language).</td></tr><a
name="nondurable-identity"></a><tr class="a"><td>nondurable identity</td><td>Where
the objects of a class should be unique in the JVM but not in the datastore (where an RDBMS
table doesnt have a PK for example).</td></tr><a name="objectid-class"></a><tr
class="b"><td>objectid class</td><td>When an object of a class is persisted,
it is assigned an object identity. When the developer has chosen to 
                         use <a href="#application-identity">application identity</a>
they can assign a class to represent this 
                         identity (as a primary key) - this is the object id class.</td></tr><a
name="optimistic_transaction"></a><tr class="a"><td>optimistic transaction</td><td>When
working with long duration transactions it is undesirable to have locking and so the assumption
is made 
                         that the data being updated by the transaction will not be modified
by any other transaction during the course 
@@ -26,17 +28,17 @@
                         which provides locking.</td></tr><a name="persistence-by-reachability"></a><tr
class="b"><td>persistence-by-reachability</td><td>When you call makePersistent()
on an object, the object will be persisted and, in addition, any 
                         other objects reachable from that object (via relationships) will
also be persisted. This is 
                         known as <B>persistence-by-reachability</B>. This process
is repeated at commit() time when 
-                        it checks whether these reachable objects are still reachable and,
if not, removes them from persistence.</td></tr><a name="persistence-capable"></a><tr
class="a"><td>persistence-capable (PC)</td><td>When an class is byte-code
enhanced, and has valid MetaData, it is referred to as "Persistence Capable". This 
-                        means that it can be persisted by a JDO implementation.</td></tr><a
name="persistence-modifier"></a><tr class="b"><td>persistence-modifier</td><td>When
defining the persistence of a class, the developer can select particular fields to be persisted,
and 
+                        it checks whether these reachable objects are still reachable and,
if not, removes them from persistence.</td></tr><a name="persistence-aware"></a><tr
class="a"><td>persistence-aware</td><td>When an class needs to access
fields of a persistence capable class directly, it should be enhanced, and is referred to
as "Persistence Aware". If a class uses field accessor methods then it doesnt need to become
"Persistence Aware".</td></tr><a name="persistence-capable"></a><tr
class="b"><td>persistence-capable (PC)</td><td>When an class is byte-code
enhanced, and has valid MetaData, it is referred to as "Persistence Capable". This 
+                        means that it can be persisted by a JDO implementation.</td></tr><a
name="persistence-modifier"></a><tr class="a"><td>persistence-modifier</td><td>When
defining the persistence of a class, the developer can select particular fields to be persisted,
and 
                         others not depending on their importance in the scope of their application.
The <B>persistence-modifier</B> 
                         defines whether a field is persistent. If this tag is not specified
JDO will assign defaults based on the 
                         field type (primitives, primitive wrappers, java.util.Data, persistence
capable fields, etc are by default 
-                        persistent).</td></tr><a name="persistent"></a><tr
class="a"><td>persistent</td><td>This is an object state where the object
is persistent in a datastore.</td></tr><a name="pessimistic_transaction"></a><tr
class="b"><td>pessimistic transaction</td><td>This is the default transaction
type in JDO, and is suitable for shortlived operations where there is no 
+                        persistent).</td></tr><a name="persistent"></a><tr
class="b"><td>persistent</td><td>This is an object state where the object
is persistent in a datastore.</td></tr><a name="pessimistic_transaction"></a><tr
class="a"><td>pessimistic transaction</td><td>This is the default transaction
type in JDO, and is suitable for shortlived operations where there is no 
                         other blocking activity during the transaction. When data is accessed
other transactions are locked out 
                         from accessing it until the transaction is complete. See also <a
href="#optimistic-transaction">optimistic 
-                        transaction</a> for the contrary type which reduces locking.</td></tr><a
name="requires-extent"></a><tr class="a"><td>Requires Extent</td><td>When
the persistent of a class is defined, the developer decides if the object will be stored with
its own 
+                        transaction</a> for the contrary type which reduces locking.</td></tr><a
name="requires-extent"></a><tr class="b"><td>Requires Extent</td><td>When
the persistent of a class is defined, the developer decides if the object will be stored with
its own 
                         identity (in its own table for example) or whether it will be stored
as part of another object. If it will 
-                        have its own identity, it will require and Extent.</td></tr><a
name="sco"></a><tr class="b"><td>SCO</td><td>JDO defines
2 main groups of Java objects. The second group is those objects that don't have an identity.

-                        These are termed "Second Class Objects" or SCO for short.</td></tr><a
name="transient"></a><tr class="a"><td>transient</td><td>This
is an object state where the object is not persistent.</td></tr></table></div></div></div><div
class="clear"><hr></hr></div><table border="0" width="100%" cellpadding="0"
cellspacing="0"><tr><td width="100%"><img height="1" border="0" width="100%"
src="./images/header_line.gif"></img></td></tr></table><div
id="footer"><div class="xleft">
+                        have its own identity, it will require and Extent.</td></tr><a
name="sco"></a><tr class="a"><td>SCO</td><td>JDO defines
2 main groups of Java objects. The second group is those objects that don't have an identity.

+                        These are termed "Second Class Objects" or SCO for short.</td></tr><a
name="SQL"></a><tr class="b"><td>SQL</td><td>JDO allows use
of multiple query languages. One of these, for use with RDBMS datastores, is SQL.</td></tr><a
name="transient"></a><tr class="a"><td>transient</td><td>This
is an object state where the object is not persistent.</td></tr></table></div></div></div><div
class="clear"><hr></hr></div><table border="0" width="100%" cellpadding="0"
cellspacing="0"><tr><td width="100%"><img height="1" border="0" width="100%"
src="./images/header_line.gif"></img></td></tr></table><div
id="footer"><div class="xleft">
                 Documentation published: 14 October 2007<br></br>
                   © 2005-2007 <a href="http://www.apache.org/">Apache Software Foundation</a></div></div></body></html>

Modified: db/jdo/site/docs/object_retrieval.html
URL: http://svn.apache.org/viewvc/db/jdo/site/docs/object_retrieval.html?rev=584516&r1=584515&r2=584516&view=diff
==============================================================================
--- db/jdo/site/docs/object_retrieval.html (original)
+++ db/jdo/site/docs/object_retrieval.html Sun Oct 14 01:56:21 2007
@@ -12,8 +12,7 @@
                 </pre></div>
   <p>
                     If the object is in the JDO cache then it is retrieved from there, otherwise
the JDO implementation
-                    goes to the datastore. When the object is retrieved its fields are populated
according to its
-                    <a href="../1_1/fetchgroup.html">Fetch Group</a>.
+                    goes to the datastore. When the object is retrieved its fields are populated
according to its Fetch Group.
                 </p></div><div class="subsection"><a name="Retrieve_an_object_based_on_its_Extent"></a><h3>Retrieve
an object based on its Extent</h3><p>
                     A persistable class can be persisted with an <b>Extent</b>
of all instances of that type.
                     You can use this to retrieve objects of the required type, like this

Modified: db/jdo/site/xdocs/glossary.xml
URL: http://svn.apache.org/viewvc/db/jdo/site/xdocs/glossary.xml?rev=584516&r1=584515&r2=584516&view=diff
==============================================================================
--- db/jdo/site/xdocs/glossary.xml (original)
+++ db/jdo/site/xdocs/glossary.xml Sun Oct 14 01:56:21 2007
@@ -62,12 +62,24 @@
                     <td>JDO defines 2 main groups of Java objects. The first is those
objects that have an identity. These are
                         termed "First Class Objects" or FCO for short.</td>
                 </tr>
+                <a name="fetchgroup"/>
+                <tr>
+                    <td>Fetch Group</td>
+                    <td>JDO allows a user to define groups of fields that should be
retrieved (fetched) at the same time. These are called a "fetch group".
+                        The principal "fetch group" is the "default fetch group", where JDO
has rules for what fields are in this group. 
+                        A user can define their own group, and make this active so that when
objects of their type are retrieved, they have control over the fetching process.</td>
+                </tr>
                 <a name="JDOQL"/>
                 <tr>
                     <td>JDOQL</td>
                     <td>JDO introduces its own Java-like query language as a datastore
independent way of retrieving objects from 
                         the datastore. This is known as JDOQL (JDO Query Language).</td>
                 </tr>
+                <a name="nondurable-identity"/>
+                <tr>
+                    <td>nondurable identity</td>
+                    <td>Where the objects of a class should be unique in the JVM but
not in the datastore (where an RDBMS table doesnt have a PK for example).</td>
+                </tr>
                 <a name="objectid-class"/>
                 <tr>
                     <td>objectid class</td>
@@ -92,6 +104,11 @@
                         known as <B>persistence-by-reachability</B>. This process
is repeated at commit() time when 
                         it checks whether these reachable objects are still reachable and,
if not, removes them from persistence.</td>
                 </tr>
+                <a name="persistence-aware"/>
+                <tr>
+                    <td>persistence-aware</td>
+                    <td>When an class needs to access fields of a persistence capable
class directly, it should be enhanced, and is referred to as "Persistence Aware". If a class
uses field accessor methods then it doesnt need to become "Persistence Aware".</td>
+                </tr>
                 <a name="persistence-capable"/>
                 <tr>
                     <td>persistence-capable (PC)</td>
@@ -132,6 +149,11 @@
                     <td>SCO</td>
                     <td>JDO defines 2 main groups of Java objects. The second group
is those objects that don't have an identity. 
                         These are termed "Second Class Objects" or SCO for short.</td>
+                </tr>
+                <a name="SQL"/>
+                <tr>
+                    <td>SQL</td>
+                    <td>JDO allows use of multiple query languages. One of these, for
use with RDBMS datastores, is SQL.</td>
                 </tr>
                 <a name="transient"/>
                 <tr>

Modified: db/jdo/site/xdocs/object_retrieval.xml
URL: http://svn.apache.org/viewvc/db/jdo/site/xdocs/object_retrieval.xml?rev=584516&r1=584515&r2=584516&view=diff
==============================================================================
--- db/jdo/site/xdocs/object_retrieval.xml (original)
+++ db/jdo/site/xdocs/object_retrieval.xml Sun Oct 14 01:56:21 2007
@@ -20,8 +20,7 @@
                 </source>
                 <p>
                     If the object is in the JDO cache then it is retrieved from there, otherwise
the JDO implementation
-                    goes to the datastore. When the object is retrieved its fields are populated
according to its
-                    <a href="../1_1/fetchgroup.html">Fetch Group</a>.
+                    goes to the datastore. When the object is retrieved its fields are populated
according to its Fetch Group.
                 </p>
             </subsection>
 



Mime
View raw message