[hibernate-commits] Hibernate SVN: r12721 - in core/trunk/documentation/manual: pt-BR/src/main/docbook/modules and 1 other directories.
hibernate-commits at lists.jboss.org
hibernate-commits at lists.jboss.org
Wed Jul 4 01:55:02 EDT 2007
Author: d.plentz
Date: 2007-07-04 01:55:02 -0400 (Wed, 04 Jul 2007)
New Revision: 12721
Modified:
core/trunk/documentation/manual/en-US/src/main/docbook/modules/architecture.xml
core/trunk/documentation/manual/en-US/src/main/docbook/modules/batch.xml
core/trunk/documentation/manual/en-US/src/main/docbook/modules/best_practices.xml
core/trunk/documentation/manual/en-US/src/main/docbook/modules/collection_mapping.xml
core/trunk/documentation/manual/en-US/src/main/docbook/modules/configuration.xml
core/trunk/documentation/manual/en-US/src/main/docbook/modules/example_parentchild.xml
core/trunk/documentation/manual/en-US/src/main/docbook/modules/session_api.xml
core/trunk/documentation/manual/pt-BR/src/main/docbook/modules/best_practices.xml
core/trunk/documentation/manual/pt-BR/src/main/docbook/modules/collection_mapping.xml
core/trunk/documentation/manual/pt-BR/src/main/docbook/modules/configuration.xml
core/trunk/documentation/manual/pt-BR/src/main/docbook/modules/example_parentchild.xml
core/trunk/documentation/manual/pt-BR/src/main/docbook/modules/session_api.xml
core/trunk/documentation/manual/zh-CN/src/main/docbook/modules/collection_mapping.xml
core/trunk/documentation/manual/zh-CN/src/main/docbook/modules/example_parentchild.xml
core/trunk/documentation/manual/zh-CN/src/main/docbook/modules/session_api.xml
Log:
[HHH-2520] Miscellaneous config doc spelling fixes
and some others.
Modified: core/trunk/documentation/manual/en-US/src/main/docbook/modules/architecture.xml
===================================================================
--- core/trunk/documentation/manual/en-US/src/main/docbook/modules/architecture.xml 2007-07-04 05:33:48 UTC (rev 12720)
+++ core/trunk/documentation/manual/en-US/src/main/docbook/modules/architecture.xml 2007-07-04 05:55:02 UTC (rev 12721)
@@ -225,7 +225,7 @@
<itemizedlist>
<listitem>
<para>
- <emphasis>Session Management:</emphasis> The Hibernate <literal>Session</literal>'s lifecycle
+ <emphasis>Session Management:</emphasis> The Hibernate <literal>Session</literal>'s life cycle
can be automatically bound to the scope of a JTA transaction. This means you no
longer have to manually open and close the <literal>Session</literal>, this
becomes the job of a JBoss EJB interceptor. You also don't have to worry about
Modified: core/trunk/documentation/manual/en-US/src/main/docbook/modules/batch.xml
===================================================================
--- core/trunk/documentation/manual/en-US/src/main/docbook/modules/batch.xml 2007-07-04 05:33:48 UTC (rev 12720)
+++ core/trunk/documentation/manual/en-US/src/main/docbook/modules/batch.xml 2007-07-04 05:55:02 UTC (rev 12721)
@@ -111,7 +111,7 @@
Alternatively, Hibernate provides a command-oriented API that may be used for
streaming data to and from the database in the form of detached objects. A
<literal>StatelessSession</literal> has no persistence context associated
- with it and does not provide many of the higher-level lifecycle semantics.
+ with it and does not provide many of the higher-level life cycle semantics.
In particular, a stateless session does not implement a first-level cache nor
interact with any second-level or query cache. It does not implement
transactional write-behind or automatic dirty checking. Operations performed
Modified: core/trunk/documentation/manual/en-US/src/main/docbook/modules/best_practices.xml
===================================================================
--- core/trunk/documentation/manual/en-US/src/main/docbook/modules/best_practices.xml 2007-07-04 05:33:48 UTC (rev 12720)
+++ core/trunk/documentation/manual/en-US/src/main/docbook/modules/best_practices.xml 2007-07-04 05:55:02 UTC (rev 12721)
@@ -134,7 +134,7 @@
unit-of-work from the point of view of a user. An application transaction might span several
client request/response cycles. It is common to use detached objects to implement application
transactions. An alternative, extremely appropriate in two tiered architecture, is to maintain
- a single open persistence contact (session) for the whole lifecycle of the application transaction
+ a single open persistence contact (session) for the whole life cycle of the application transaction
and simply disconnect from the JDBC connection at the end of each request and reconnect at the
beginning of the subsequent request. Never share a single session across more than one application
transaction, or you will be working with stale data.
Modified: core/trunk/documentation/manual/en-US/src/main/docbook/modules/collection_mapping.xml
===================================================================
--- core/trunk/documentation/manual/en-US/src/main/docbook/modules/collection_mapping.xml 2007-07-04 05:33:48 UTC (rev 12720)
+++ core/trunk/documentation/manual/en-US/src/main/docbook/modules/collection_mapping.xml 2007-07-04 05:55:02 UTC (rev 12721)
@@ -275,8 +275,8 @@
Collections may contain almost any other Hibernate type, including all basic types,
custom types, components, and of course, references to other entities. This is an
important distinction: an object in a collection might be handled with "value"
- semantics (its lifecycle fully depends on the collection owner) or it might be a
- reference to another entity, with its own lifecycle. In the latter case, only the
+ semantics (its life cycle fully depends on the collection owner) or it might be a
+ reference to another entity, with its own life cycle. In the latter case, only the
"link" between the two objects is considered to be state held by the collection.
</para>
Modified: core/trunk/documentation/manual/en-US/src/main/docbook/modules/configuration.xml
===================================================================
--- core/trunk/documentation/manual/en-US/src/main/docbook/modules/configuration.xml 2007-07-04 05:33:48 UTC (rev 12720)
+++ core/trunk/documentation/manual/en-US/src/main/docbook/modules/configuration.xml 2007-07-04 05:55:02 UTC (rev 12721)
@@ -167,7 +167,7 @@
<literal>hibernate.connection.driver_class</literal>
</entry>
<entry>
- <emphasis>jdbc driver class</emphasis>
+ <emphasis>JDBC driver class</emphasis>
</entry>
</row>
<row>
@@ -175,7 +175,7 @@
<literal>hibernate.connection.url</literal>
</entry>
<entry>
- <emphasis>jdbc URL</emphasis>
+ <emphasis>JDBC URL</emphasis>
</entry>
</row>
<row>
@@ -253,7 +253,7 @@
<colspec colname="c2" colwidth="1*"/>
<thead>
<row>
- <entry>Propery name</entry>
+ <entry>Property name</entry>
<entry>Purpose</entry>
</row>
</thead>
@@ -321,7 +321,7 @@
<para>
Arbitrary connection properties may be given by prepending
- "<literal>hibernate.connnection</literal>" to the property name. For example, you
+ "<literal>hibernate.connection</literal>" to the property name. For example, you
may specify a <literal>charSet</literal> using <literal>hibernate.connection.charSet</literal>.
</para>
@@ -405,7 +405,7 @@
<literal>hibernate.default_schema</literal>
</entry>
<entry>
- Qualify unqualified tablenames with the given schema/tablespace
+ Qualify unqualified table names with the given schema/tablespace
in generated SQL.
<para>
<emphasis role="strong">eg.</emphasis>
@@ -418,7 +418,7 @@
<literal>hibernate.default_catalog</literal>
</entry>
<entry>
- Qualify unqualified tablenames with the given catalog
+ Qualify unqualified table names with the given catalog
in generated SQL.
<para>
<emphasis role="strong">eg.</emphasis>
@@ -509,7 +509,7 @@
</row>
<row>
<entry>
- <literal>hibernate.use_identifer_rollback</literal>
+ <literal>hibernate.use_identifier_rollback</literal>
</entry>
<entry>
If enabled, generated identifier properties will be
@@ -634,7 +634,7 @@
Enable use of JDBC3 <literal>PreparedStatement.getGeneratedKeys()</literal>
to retrieve natively generated keys after insert. Requires JDBC3+ driver
and JRE1.4+, set to false if your driver has problems with the Hibernate
- identifier generators. By default, tries to determine the driver capabilites
+ identifier generators. By default, tries to determine the driver capabilities
using connection metadata.
<para>
<emphasis role="strong">eg.</emphasis>
@@ -1421,7 +1421,7 @@
a JTA compatible <literal>TransactionManager</literal> and a
<literal>ResourceManager</literal> take care of transaction management (CMT),
esp. distributed transaction handling across several datasources. You may
- of course also demarcate transaction boundaries programatically (BMT) or
+ of course also demarcate transaction boundaries programmatically (BMT) or
you might want to use the optional Hibernate <literal>Transaction</literal>
API for this to keep your code portable.
</para>
@@ -1625,7 +1625,7 @@
<para>
We recommend that you bind the <literal>SessionFactory</literal> to JNDI in
- a managend environment and use a <literal>static</literal> singleton otherwise.
+ a managed environment and use a <literal>static</literal> singleton otherwise.
To shield your application code from these details, we also recommend to hide the
actual lookup code for a <literal>SessionFactory</literal> in a helper class,
such as <literal>HibernateUtil.getSessionFactory()</literal>. Note that such a
@@ -1649,7 +1649,7 @@
will be set to automatically flush before the transaction completes, close
after the transaction completes, and aggressively release JDBC connections
after each statement. This allows the <literal>Session</literal>s to
- be managed by the lifecycle of the JTA transaction to which it is associated,
+ be managed by the life cycle of the JTA transaction to which it is associated,
keeping user code clean of such management concerns. Your code can either use
JTA programmatically through <literal>UserTransaction</literal>, or (recommended
for portable code) use the Hibernate <literal>Transaction</literal> API to set
Modified: core/trunk/documentation/manual/en-US/src/main/docbook/modules/example_parentchild.xml
===================================================================
--- core/trunk/documentation/manual/en-US/src/main/docbook/modules/example_parentchild.xml 2007-07-04 05:33:48 UTC (rev 12720)
+++ core/trunk/documentation/manual/en-US/src/main/docbook/modules/example_parentchild.xml 2007-07-04 05:55:02 UTC (rev 12721)
@@ -52,7 +52,7 @@
Instead, the default behaviour is that adding an entity to a collection merely creates a link between
the two entities, while removing it removes the link. This is very appropriate for all sorts of cases.
Where it is not appropriate at all is the case of a parent / child relationship, where the life of the
- child is bound to the lifecycle of the parent.
+ child is bound to the life cycle of the parent.
</para>
</sect1>
@@ -171,7 +171,7 @@
</sect1>
<sect1 id="example-parentchild-cascades">
- <title>Cascading lifecycle</title>
+ <title>Cascading life cycle</title>
<para>
The explicit call to <literal>save()</literal> is still annoying. We will address this by
Modified: core/trunk/documentation/manual/en-US/src/main/docbook/modules/session_api.xml
===================================================================
--- core/trunk/documentation/manual/en-US/src/main/docbook/modules/session_api.xml 2007-07-04 05:33:48 UTC (rev 12720)
+++ core/trunk/documentation/manual/en-US/src/main/docbook/modules/session_api.xml 2007-07-04 05:55:02 UTC (rev 12721)
@@ -1059,7 +1059,7 @@
<para>
If the children in a parent/child relationship would be value typed (e.g. a collection
- of addresses or strings), their lifecycle would depend on the parent and no
+ of addresses or strings), their life cycle would depend on the parent and no
further action would be required for convenient "cascading" of state changes.
When the parent is saved, the value-typed child objects are saved as
well, when the parent is deleted, the children will be deleted, etc. This
@@ -1071,7 +1071,7 @@
<para>
Now consider the same scenario with parent and child objects being entities,
not value-types (e.g. categories and items, or parent and child cats). Entities
- have their own lifecycle, support shared references (so removing an entity from
+ have their own life cycle, support shared references (so removing an entity from
the collection does not mean it can be deleted), and there is by default no
cascading of state from one entity to any other associated entities. Hibernate
does not implement <emphasis>persistence by reachability</emphasis> by default.
@@ -1123,7 +1123,7 @@
<listitem>
<para>
If the child object's lifespan is bounded by the lifespan of the of the parent
- object make it a <emphasis>lifecycle object</emphasis> by specifying
+ object make it a <emphasis>life cycle object</emphasis> by specifying
<literal>cascade="all,delete-orphan"</literal>.
</para>
</listitem>
Modified: core/trunk/documentation/manual/pt-BR/src/main/docbook/modules/best_practices.xml
===================================================================
--- core/trunk/documentation/manual/pt-BR/src/main/docbook/modules/best_practices.xml 2007-07-04 05:33:48 UTC (rev 12720)
+++ core/trunk/documentation/manual/pt-BR/src/main/docbook/modules/best_practices.xml 2007-07-04 05:55:02 UTC (rev 12721)
@@ -132,11 +132,11 @@
<listitem>
<para>
Database Transactions have to be as short as possible for best scalability. However, it is often
- neccessary to implement long running <emphasis>application transactions</emphasis>, a single
+ necessary to implement long running <emphasis>application transactions</emphasis>, a single
unit-of-work from the point of view of a user. An application transaction might span several
client request/response cycles. It is common to use detached objects to implement application
transactions. An alternative, extremely appropriate in two tiered architecture, is to maintain
- a single open persistence contact (session) for the whole lifecycle of the application transaction
+ a single open persistence contact (session) for the whole life cycle of the application transaction
and simply disconnect from the JDBC connection at the end of each request and reconnect at the
beginning of the subsequent request. Never share a single session across more than one application
transaction, or you will be working with stale data.
Modified: core/trunk/documentation/manual/pt-BR/src/main/docbook/modules/collection_mapping.xml
===================================================================
--- core/trunk/documentation/manual/pt-BR/src/main/docbook/modules/collection_mapping.xml 2007-07-04 05:33:48 UTC (rev 12720)
+++ core/trunk/documentation/manual/pt-BR/src/main/docbook/modules/collection_mapping.xml 2007-07-04 05:55:02 UTC (rev 12721)
@@ -275,8 +275,8 @@
Collections may contain almost any other Hibernate type, including all basic types,
custom types, components, and of course, references to other entities. This is an
important distinction: an object in a collection might be handled with "value"
- semantics (its lifecycle fully depends on the collection owner) or it might be a
- reference to another entity, with its own lifecycle. In the latter case, only the
+ semantics (its life cycle fully depends on the collection owner) or it might be a
+ reference to another entity, with its own life cycle. In the latter case, only the
"link" between the two objects is considered to be state held by the collection.
</para>
Modified: core/trunk/documentation/manual/pt-BR/src/main/docbook/modules/configuration.xml
===================================================================
--- core/trunk/documentation/manual/pt-BR/src/main/docbook/modules/configuration.xml 2007-07-04 05:33:48 UTC (rev 12720)
+++ core/trunk/documentation/manual/pt-BR/src/main/docbook/modules/configuration.xml 2007-07-04 05:55:02 UTC (rev 12721)
@@ -1700,7 +1700,7 @@
will be set to automatically flush before the transaction completes, close
after the transaction completes, and aggressively release JDBC connections
after each statement. This allows the <literal>Session</literal>s to
- be managed by the lifecycle of the JTA transaction to which it is associated,
+ be managed by the life cycle of the JTA transaction to which it is associated,
keeping user code clean of such management concerns. Your code can either use
JTA programmatically through <literal>UserTransaction</literal>, or (recommended
for portable code) use the Hibernate <literal>Transaction</literal> API to set
Modified: core/trunk/documentation/manual/pt-BR/src/main/docbook/modules/example_parentchild.xml
===================================================================
--- core/trunk/documentation/manual/pt-BR/src/main/docbook/modules/example_parentchild.xml 2007-07-04 05:33:48 UTC (rev 12720)
+++ core/trunk/documentation/manual/pt-BR/src/main/docbook/modules/example_parentchild.xml 2007-07-04 05:55:02 UTC (rev 12721)
@@ -52,7 +52,7 @@
Instead, the default behaviour is that adding an entity to a collection merely creates a link between
the two entities, while removing it removes the link. This is very appropriate for all sorts of cases.
Where it is not appropriate at all is the case of a parent / child relationship, where the life of the
- child is bound to the lifecycle of the parent.
+ child is bound to the life cycle of the parent.
</para>
</sect1>
@@ -171,7 +171,7 @@
</sect1>
<sect1 id="example-parentchild-cascades">
- <title>Cascading lifecycle</title>
+ <title>Cascading life cycle</title>
<para>
The explicit call to <literal>save()</literal> is still annoying. We will address this by
Modified: core/trunk/documentation/manual/pt-BR/src/main/docbook/modules/session_api.xml
===================================================================
--- core/trunk/documentation/manual/pt-BR/src/main/docbook/modules/session_api.xml 2007-07-04 05:33:48 UTC (rev 12720)
+++ core/trunk/documentation/manual/pt-BR/src/main/docbook/modules/session_api.xml 2007-07-04 05:55:02 UTC (rev 12721)
@@ -1067,7 +1067,7 @@
<para>
If the children in a parent/child relationship would be value typed (e.g. a collection
- of addresses or strings), their lifecycle would depend on the parent and no
+ of addresses or strings), their life cycle would depend on the parent and no
further action would be required for convenient "cascading" of state changes.
When the parent is saved, the value-typed child objects are saved as
well, when the parent is deleted, the children will be deleted, etc. This
@@ -1079,7 +1079,7 @@
<para>
Now consider the same scenario with parent and child objects being entities,
not value-types (e.g. categories and items, or parent and child cats). Entities
- have their own lifecycle, support shared references (so removing an entity from
+ have their own life cycle, support shared references (so removing an entity from
the collection does not mean it can be deleted), and there is by default no
cascading of state from one entity to any other associated entities. Hibernate
does not implement <emphasis>persistence by reachability</emphasis> by default.
@@ -1131,7 +1131,7 @@
<listitem>
<para>
If the child object's lifespan is bounded by the lifespan of the of the parent
- object make it a <emphasis>lifecycle object</emphasis> by specifying
+ object make it a <emphasis>life cycle object</emphasis> by specifying
<literal>cascade="all,delete-orphan"</literal>.
</para>
</listitem>
Modified: core/trunk/documentation/manual/zh-CN/src/main/docbook/modules/collection_mapping.xml
===================================================================
--- core/trunk/documentation/manual/zh-CN/src/main/docbook/modules/collection_mapping.xml 2007-07-04 05:33:48 UTC (rev 12720)
+++ core/trunk/documentation/manual/zh-CN/src/main/docbook/modules/collection_mapping.xml 2007-07-04 05:55:02 UTC (rev 12721)
@@ -478,7 +478,7 @@
</bag>]]></programlisting>
<para>
- 一个实体数组,在这个案例中是一个多对多的关联(注意这里的实体是自动管理生命周期的对象（lifecycle objects）,<literal>cascade="all"</literal>):
+ 一个实体数组,在这个案例中是一个多对多的关联(注意这里的实体是自动管理生命周期的对象（life cycle objects）,<literal>cascade="all"</literal>):
</para>
Modified: core/trunk/documentation/manual/zh-CN/src/main/docbook/modules/example_parentchild.xml
===================================================================
--- core/trunk/documentation/manual/zh-CN/src/main/docbook/modules/example_parentchild.xml 2007-07-04 05:33:48 UTC (rev 12720)
+++ core/trunk/documentation/manual/zh-CN/src/main/docbook/modules/example_parentchild.xml 2007-07-04 05:55:02 UTC (rev 12721)
@@ -137,7 +137,7 @@
</sect1>
<sect1 id="example-parentchild-cascades">
- <title>级联生命周期（Cascading lifecycle）</title>
+ <title>级联生命周期（Cascading life cycle）</title>
<para>
需要显式调用<literal>save()</literal>仍然很麻烦，我们可以用级联来解决这个问题。
</para>
Modified: core/trunk/documentation/manual/zh-CN/src/main/docbook/modules/session_api.xml
===================================================================
--- core/trunk/documentation/manual/zh-CN/src/main/docbook/modules/session_api.xml 2007-07-04 05:33:48 UTC (rev 12720)
+++ core/trunk/documentation/manual/zh-CN/src/main/docbook/modules/session_api.xml 2007-07-04 05:55:02 UTC (rev 12721)
@@ -1019,7 +1019,7 @@
</listitem>
<listitem>
<para>
- 如果子对象的寿命限定在父亲对象的寿命之内，可通过指定<literal>cascade="all,delete-orphan"</literal>将其变为<emphasis>自动生命周期管理的对象(lifecycle object)</emphasis>。
+ 如果子对象的寿命限定在父亲对象的寿命之内，可通过指定<literal>cascade="all,delete-orphan"</literal>将其变为<emphasis>自动生命周期管理的对象(life cycle object)</emphasis>。
</para>
</listitem>
<listitem>
More information about the hibernate-commits
mailing list