[jboss-cvs] JBossAS SVN: r85760 - in projects/docs/enterprise: 4.2.6/Hibernate/Annotations_Reference_Guide/en-US and 8 other directories.
jboss-cvs-commits at lists.jboss.org
jboss-cvs-commits at lists.jboss.org
Thu Mar 12 00:42:44 EDT 2009
Author: irooskov at redhat.com
Date: 2009-03-12 00:42:44 -0400 (Thu, 12 Mar 2009)
New Revision: 85760
Modified:
projects/docs/enterprise/4.2.6/Getting_Started/en-US/Book_Info.xml
projects/docs/enterprise/4.2.6/Getting_Started/en-US/Revision_History.xml
projects/docs/enterprise/4.2.6/Hibernate/Annotations_Reference_Guide/en-US/Revision_History.xml
projects/docs/enterprise/4.2.6/Hibernate/Entity_Manager_User_Guide/en-US/Revision_History.xml
projects/docs/enterprise/4.2.6/Hibernate/Reference_Guide/en-US/Revision_History.xml
projects/docs/enterprise/4.2.6/Installation_Guide/en-US/Revision_History.xml
projects/docs/enterprise/4.2.6/Seam/Reference_Guide/en-US/Revision_History.xml
projects/docs/enterprise/4.2.6/Server_Configuration_Guide/en-US/Revision_History.xml
projects/docs/enterprise/4.2.6/readme/en-US/Revision_History.xml
projects/docs/enterprise/4.2.7/Hibernate/Annotations_Reference_Guide/en-US/Entity.xml
projects/docs/enterprise/4.2.7/Hibernate/Annotations_Reference_Guide/en-US/Lucene.xml
projects/docs/enterprise/4.2.7/Hibernate/Annotations_Reference_Guide/en-US/Xml-Overriding.xml
projects/docs/enterprise/4.3.5/Hibernate/Annotations_Reference_Guide/en-US/Entity.xml
projects/docs/enterprise/4.3.5/Hibernate/Annotations_Reference_Guide/en-US/Lucene.xml
projects/docs/enterprise/4.3.5/Hibernate/Annotations_Reference_Guide/en-US/Xml-Overriding.xml
Log:
updated books with JBPAPP-1723 fixes and other updates
Modified: projects/docs/enterprise/4.2.6/Getting_Started/en-US/Book_Info.xml
===================================================================
--- projects/docs/enterprise/4.2.6/Getting_Started/en-US/Book_Info.xml 2009-03-12 03:29:56 UTC (rev 85759)
+++ projects/docs/enterprise/4.2.6/Getting_Started/en-US/Book_Info.xml 2009-03-12 04:42:44 UTC (rev 85760)
@@ -9,7 +9,7 @@
<pubsnumber>7</pubsnumber>
<productname>JBoss Application Server</productname>
<productnumber>4.2</productnumber>
- <pubdate>Sep, 2007</pubdate>
+ <pubdate>February, 2009</pubdate>
<isbn>N/A</isbn>
<abstract><para>This book provides post-installation information about &JBEAP;. Use this guide to familiarise yourself with the platform and the sample applications that demonstrate application development and deployment.</para>
</abstract>
Modified: projects/docs/enterprise/4.2.6/Getting_Started/en-US/Revision_History.xml
===================================================================
--- projects/docs/enterprise/4.2.6/Getting_Started/en-US/Revision_History.xml 2009-03-12 03:29:56 UTC (rev 85759)
+++ projects/docs/enterprise/4.2.6/Getting_Started/en-US/Revision_History.xml 2009-03-12 04:42:44 UTC (rev 85760)
@@ -8,7 +8,7 @@
<revhistory>
<revision>
<revnumber>1.0</revnumber>
- <date></date>
+ <date>Fri Feb 27 2009</date>
<author>
<firstname></firstname>
<surname></surname>
Modified: projects/docs/enterprise/4.2.6/Hibernate/Annotations_Reference_Guide/en-US/Revision_History.xml
===================================================================
--- projects/docs/enterprise/4.2.6/Hibernate/Annotations_Reference_Guide/en-US/Revision_History.xml 2009-03-12 03:29:56 UTC (rev 85759)
+++ projects/docs/enterprise/4.2.6/Hibernate/Annotations_Reference_Guide/en-US/Revision_History.xml 2009-03-12 04:42:44 UTC (rev 85760)
@@ -8,7 +8,7 @@
<revhistory>
<revision>
<revnumber>1.0</revnumber>
- <date></date>
+ <date>Fri Feb 27 2009</date>
<author>
<firstname></firstname>
<surname></surname>
Modified: projects/docs/enterprise/4.2.6/Hibernate/Entity_Manager_User_Guide/en-US/Revision_History.xml
===================================================================
--- projects/docs/enterprise/4.2.6/Hibernate/Entity_Manager_User_Guide/en-US/Revision_History.xml 2009-03-12 03:29:56 UTC (rev 85759)
+++ projects/docs/enterprise/4.2.6/Hibernate/Entity_Manager_User_Guide/en-US/Revision_History.xml 2009-03-12 04:42:44 UTC (rev 85760)
@@ -8,7 +8,7 @@
<revhistory>
<revision>
<revnumber>1.0</revnumber>
- <date></date>
+ <date>Fri Feb 27 2009</date>
<author>
<firstname></firstname>
<surname></surname>
Modified: projects/docs/enterprise/4.2.6/Hibernate/Reference_Guide/en-US/Revision_History.xml
===================================================================
--- projects/docs/enterprise/4.2.6/Hibernate/Reference_Guide/en-US/Revision_History.xml 2009-03-12 03:29:56 UTC (rev 85759)
+++ projects/docs/enterprise/4.2.6/Hibernate/Reference_Guide/en-US/Revision_History.xml 2009-03-12 04:42:44 UTC (rev 85760)
@@ -8,7 +8,7 @@
<revhistory>
<revision>
<revnumber>1.0</revnumber>
- <date></date>
+ <date>Fri Feb 27 2009</date>
<author>
<firstname></firstname>
<surname></surname>
Modified: projects/docs/enterprise/4.2.6/Installation_Guide/en-US/Revision_History.xml
===================================================================
--- projects/docs/enterprise/4.2.6/Installation_Guide/en-US/Revision_History.xml 2009-03-12 03:29:56 UTC (rev 85759)
+++ projects/docs/enterprise/4.2.6/Installation_Guide/en-US/Revision_History.xml 2009-03-12 04:42:44 UTC (rev 85760)
@@ -8,7 +8,7 @@
<revhistory>
<revision>
<revnumber>1.0</revnumber>
- <date></date>
+ <date>Fri Feb 27 2009</date>
<author>
<firstname></firstname>
<surname></surname>
Modified: projects/docs/enterprise/4.2.6/Seam/Reference_Guide/en-US/Revision_History.xml
===================================================================
--- projects/docs/enterprise/4.2.6/Seam/Reference_Guide/en-US/Revision_History.xml 2009-03-12 03:29:56 UTC (rev 85759)
+++ projects/docs/enterprise/4.2.6/Seam/Reference_Guide/en-US/Revision_History.xml 2009-03-12 04:42:44 UTC (rev 85760)
@@ -8,7 +8,7 @@
<revhistory>
<revision>
<revnumber>1.0</revnumber>
- <date></date>
+ <date>Fri Feb 27 2009</date>
<author>
<firstname></firstname>
<surname></surname>
Modified: projects/docs/enterprise/4.2.6/Server_Configuration_Guide/en-US/Revision_History.xml
===================================================================
--- projects/docs/enterprise/4.2.6/Server_Configuration_Guide/en-US/Revision_History.xml 2009-03-12 03:29:56 UTC (rev 85759)
+++ projects/docs/enterprise/4.2.6/Server_Configuration_Guide/en-US/Revision_History.xml 2009-03-12 04:42:44 UTC (rev 85760)
@@ -8,7 +8,7 @@
<revhistory>
<revision>
<revnumber>1.0</revnumber>
- <date></date>
+ <date>Fri Feb 27 2009</date>
<author>
<firstname></firstname>
<surname></surname>
Modified: projects/docs/enterprise/4.2.6/readme/en-US/Revision_History.xml
===================================================================
--- projects/docs/enterprise/4.2.6/readme/en-US/Revision_History.xml 2009-03-12 03:29:56 UTC (rev 85759)
+++ projects/docs/enterprise/4.2.6/readme/en-US/Revision_History.xml 2009-03-12 04:42:44 UTC (rev 85760)
@@ -8,7 +8,7 @@
<revhistory>
<revision>
<revnumber>1.0</revnumber>
- <date></date>
+ <date>Fri Feb 27 2009</date>
<author>
<firstname></firstname>
<surname></surname>
Modified: projects/docs/enterprise/4.2.7/Hibernate/Annotations_Reference_Guide/en-US/Entity.xml
===================================================================
--- projects/docs/enterprise/4.2.7/Hibernate/Annotations_Reference_Guide/en-US/Entity.xml 2009-03-12 03:29:56 UTC (rev 85759)
+++ projects/docs/enterprise/4.2.7/Hibernate/Annotations_Reference_Guide/en-US/Entity.xml 2009-03-12 04:42:44 UTC (rev 85760)
@@ -366,7 +366,7 @@
</para>
</listitem>
</itemizedlist>
- </sect3></sect2><sect2 id="Mapping_with_EJB3JPA_Annotations-Mapping_identifier_properties" label=""><title>Mapping identifier properties</title>
+</sect3></sect2><sect2 id="Mapping_with_EJB3JPA_Annotations-Mapping_identifier_properties" label="Mapping identifier properties"><title>Mapping identifier properties</title>
<para>
The <literal>@Id</literal> annotation lets you define which property is the identifier of your entity bean. This property can be set by the application itself or be generated by Hibernate (preferred). You can define the identifier generation strategy thanks to the <literal>@GeneratedValue</literal> annotation:
</para>
@@ -813,8 +813,8 @@
@Entity
public class Customer implements Serializable {
@OneToOne(cascade = CascadeType.ALL)
- <emphasis role="bold">@JoinTable(name = "CustomerPassports" joinColumns = @JoinColumn(name="customer_fk"),</emphasis>
- <emphasis role="bold">inverseJoinColumns = @JoinColumns(name="passport_fk")
+ <emphasis role="bold">@JoinTable(name = "CustomerPassports", joinColumns = @JoinColumn(name="customer_fk"),</emphasis>
+ <emphasis role="bold">inverseJoinColumns = @JoinColumn(name="passport_fk")
)</emphasis>
public Passport getPassport() {
...
@@ -873,7 +873,7 @@
</programlisting>
<para>
- You can alse map a many to one association through an association table. This association table described by the <literal>@JoinTable</literal> annotation will contains a foreign key referencing back the entity table (through <literal>@JoinTable.joinColumns</literal>) and a a foreign key referencing the target entity table (through <literal>@JoinTable.inverseJoinColumns</literal>).
+ You can also map a many to one association through an association table. This association table described by the <literal>@JoinTable</literal> annotation will contains a foreign key referencing back the entity table (through <literal>@JoinTable.joinColumns</literal>) and a foreign key referencing the target entity table (through <literal>@JoinTable.inverseJoinColumns</literal>).
</para>
<programlisting>
@Entity()
@@ -929,7 +929,7 @@
</row>
<row>
<entry>
- Bag semantic with primary key (withtout the limitations of Bag semantic)
+ Bag semantic with primary key (without the limitations of Bag semantic)
</entry>
<entry>
java.util.List, java.util.Collection
@@ -1169,7 +1169,7 @@
public class Employee implements Serializable {
@ManyToMany(
cascade={CascadeType.PERSIST, CascadeType.MERGE},
- mappedBy="employees"
+ mappedBy="employees",
targetEntity=Employer.class
)
public Collection getEmployers() {
@@ -1182,7 +1182,7 @@
We've already shown the many declarations and the detailed attributes for associations. We'll go deeper in the <literal>@JoinTable</literal> description, it defines a <literal>name</literal>, an array of join columns (an array in annotation is defined using { A, B, C }), and an array of inverse join columns. The latter ones are the columns of the association table which refer to the <classname>Employee</classname> primary key (the "other side").
</para>
<para>
- As seen previously, the other side don't have to (must not) describe the physical mapping: a simple <literal>mappedBy</literal> argument containing the owner side property name bind the two.
+ As seen previously, the other side must not describe the physical mapping: a simple <literal>mappedBy</literal> argument containing the owner side property name bind the two.
</para>
</sect5><sect5 id="Many_to_many-Default_values"><title>Default values</title>
<para>
@@ -1450,7 +1450,7 @@
org.hibernate.cacheable
</entry>
<entry>
- Whether the query should interact with the second level cache (defualt to false)
+ Whether the query should interact with the second level cache (default to false)
</entry>
</row>
<row>
@@ -1514,7 +1514,7 @@
</table>
</sect2><sect2 id="Mapping_Queries-Mapping_native_queries" revision="2"><title>Mapping native queries</title>
<para>
- You can also map a native query (ie a plain SQL query). To achieve that, you need to describe the SQL resultset structure using <literal>@SqlResultSetMapping</literal> (or <literal>@SqlResultSetMappings</literal> if you plan to define several resulset mappings). Like <literal>@NamedQuery</literal>, a <literal>@SqlResultSetMapping</literal> can be defined at class level or in a JPA XML file. However its scope is global to the application.
+ You can also map a native query (ie a plain SQL query). To achieve that, you need to describe the SQL resultset structure using <literal>@SqlResultSetMapping</literal> (or <literal>@SqlResultSetMappings</literal> if you plan to define several resultset mappings). Like <literal>@NamedQuery</literal>, a <literal>@SqlResultSetMapping</literal> can be defined at class level or in a JPA XML file. However its scope is global to the application.
</para>
<para>
As we will see, a <literal>resultSetMapping</literal> parameter is defined in <literal>@NamedNativeQuery</literal>, it represents the name of a defined <literal>@SqlResultSetMapping</literal>. The resultset mapping declares the entities retrieved by this native query. Each field of the entity is bound to an SQL alias (or column name). All fields of the entity including the ones of subclasses and the foreign key columns of related entities have to be present in the SQL query. Field definitions are optional provided that they map to the same column name as the one declared on the class property.
@@ -1543,7 +1543,7 @@
<para>
In the above example, the <literal>night&area</literal> named query use the <literal>joinMapping</literal> result set mapping. This mapping returns 2 entities, <literal>Night</literal> and <literal>Area</literal>, each property is declared and associated to a column name, actually the column name retrieved by the query. Let's now see an implicit declaration of the property / column.
</para>
-<programlisting>@Entity<emphasis role="bold">@SqlResultSetMapping(name="implicit",</emphasis>
+<programlisting>@Entity<emphasis role="bold"> @SqlResultSetMapping(name="implicit",</emphasis>
<emphasis role="bold">entities=@EntityResult(entityClass=org.hibernate.test.annotations.query.SpaceShip.class))</emphasis>
<emphasis role="bold">@NamedNativeQuery(name="implicitSample", query="select * from SpaceShip",</emphasis>
<emphasis role="bold">resultSetMapping="implicit")</emphasis>
@@ -1601,7 +1601,7 @@
query="select name, model, speed, lname as lastn, fname as firstn, length, width,
length * width as surface from SpaceShip",
resultSetMapping="compositekey")
-} )
+
public class SpaceShip {
private String name;
private String model;
@@ -1794,8 +1794,8 @@
optimisticLock = OptimisticLockType.ALL,
polymorphism = PolymorphismType.EXPLICIT)
@Where(clause="1=1")
- at org.hibernate.annotations.Table(name="Forest", indexes = { @Index(name="idx",
-columnNames = { "name", "length" } ) } )
+ at org.hibernate.annotations.Table(appliesTo="Forest", indexes = { @Index(name="idx",
+columnNames = { "appliesTo", "length" } ) } )
public class Forest { ... }
</programlisting>
<programlisting>@Entity
@@ -1943,7 +1943,7 @@
public long getObjectVolume()
</programlisting>
<para>
- The SQL fragment can be as complex as you want avec even include subselects.
+ The SQL fragment can be as complex as you want, and can even include subselects.
</para>
</sect3><sect3 id="Property-Type"><title>Type</title>
<para>
@@ -2043,7 +2043,7 @@
</para>
</sect3><sect3 id="Property-Target"><title>@Target</title>
<para>
- Sometimes, the type guessed by reflection is not the one you want Hibernate to use. This is especially true on components when an interface is used. You can use <literal>@Target</literal> to by pass the reflection guessing mechanism (very much like the <literal>targetEntity</literal> attribute available on associations.
+ Sometimes, the type guessed by reflection is not the one you want Hibernate to use. This is especially true on components when an interface is used. You can use <literal>@Target</literal> to bypass the reflection guessing mechanism (very much like the <literal>targetEntity</literal> attribute available on associations.
</para>
<programlisting> @Embedded
<emphasis role="bold">@Target(OwnerImpl.class)</emphasis>
@@ -2376,7 +2376,7 @@
return nickNames;
}
- <emphasis role="bold">@CollectionOfElements @JoinTable( table=@Table(name="BoyFavoriteNumbers"), </emphasis>
+ <emphasis role="bold">@CollectionOfElements @JoinTable( name="BoyFavoriteNumbers",</emphasis>
<emphasis role="bold">joinColumns = @JoinColumn(name="BoyId") ) @Column(name="favoriteNumber",</emphasis>
<emphasis role="bold">nullable=false)</emphasis>
@IndexColumn(name="nbr_index")
@@ -2466,7 +2466,7 @@
</note>
</sect4></sect3></sect2><sect2 id="Hibernate_Annotation_Extensions-Cache"><title>Cache</title>
<para>
- In order to optimize your database accesses, you can activave the so called second level cache of Hibernate. This cache is configurable on a per entity and per collection basis.
+ In order to optimize your database accesses, you can activate the so called second level cache of Hibernate. This cache is configurable on a per entity and per collection basis.
</para>
<para>
<literal>@org.hibernate.annotations.Cache</literal> defines the caching strategy and region of a given second level cache. This annotation can be applied on the root entity (not the sub entities), and on the collections.
@@ -2534,7 +2534,7 @@
</programlisting>
</para>
<para>
- When the collection use an association table as a relational representation, you might want to apply the filter condition to the association table itself or to the target entity table. To apply the constraint on the target entity, use the regular <literal>@Filter</literal> annotation. However, if you wan to target the association table, use the <literal>@FilterJoinTable</literal> annotation.
+ When the collection use an association table as a relational representation, you might want to apply the filter condition to the association table itself or to the target entity table. To apply the constraint on the target entity, use the regular <literal>@Filter</literal> annotation. However, if you want to target the association table, use the <literal>@FilterJoinTable</literal> annotation.
</para>
<programlisting> @OneToMany
@JoinTable
@@ -2600,7 +2600,7 @@
</para>
</sect2><sect2 id="Hibernate_Annotation_Extensions-Custom_SQL_for_CRUD_operations"><title>Custom SQL for CRUD operations</title>
<para>
- Hibernate gives you the avility to override every single SQL statement generated. We have seen native SQL query usage already, but you can also override the SQL statement used to load or change the state of entities.
+ Hibernate gives you the ability to override every single SQL statement generated. We have seen native SQL query usage already, but you can also override the SQL statement used to load or change the state of entities.
</para>
<programlisting>@Entity
@Table(name="CHAOS")
@@ -2619,7 +2619,10 @@
private String nickname;
</programlisting>
<para>
- <literal>@SQLInsert</literal>, <literal>@SQLUpdate</literal>, <literal>@SQLDelete</literal>, <literal>@SQLDeleteAll</literal> respectively override the INSERT statement, UPDATE statement, DELETE statement, DELETE statement to remove all entities.
+ <literal>@SQLInsert</literal>,
+ <literal>@SQLUpdate</literal>,
+ <literal>@SQLDelete</literal>,
+ <literal>@SQLDeleteAll</literal> respectively override the INSERT statement, UPDATE statement, DELETE statement, DELETE statement to remove all entities.
</para>
<para>
If you expect to call a store procedure, be sure to set the <literal>callable</literal> attribute to true (<literal>@SQLInsert(callable=true, ...)</literal>).
Modified: projects/docs/enterprise/4.2.7/Hibernate/Annotations_Reference_Guide/en-US/Lucene.xml
===================================================================
--- projects/docs/enterprise/4.2.7/Hibernate/Annotations_Reference_Guide/en-US/Lucene.xml 2009-03-12 03:29:56 UTC (rev 85759)
+++ projects/docs/enterprise/4.2.7/Hibernate/Annotations_Reference_Guide/en-US/Lucene.xml 2009-03-12 04:42:44 UTC (rev 85760)
@@ -15,13 +15,13 @@
Hibernate Search is made of an indexing engine and an index search engine. Both are backed by Apache Lucene.
</para>
<para>
- When an entity is inserted, updated or removed to/from the database, <productname>Hibernate Search</productname> will keep track of this event (through the Hibernate event system) and schedule an index update. When out of transaction, the update is executed right after the actual database operation. It is however recommended, for both your database and Hibernate Search, to execute your operation in a transaction (whether JDBC or JTA). When in a transaction, the index update is schedule for the transaction commit (and discarded in case of transaction rollback). You can think of this as the regular (infamous) autocommit vs transactional behavior. From a performance perspective, the <emphasis>in transaction</emphasis> mode is recommended. All the index updates are handled for you without you having to use the Apache Lucene APIs.
+ When an entity is inserted, updated or removed to/from the database, Hibernate Search will keep track of this event (through the Hibernate event system) and schedule an index update. When out of transaction, the update is executed right after the actual database operation. It is however recommended, for both your database and Hibernate Search, to execute your operation in a transaction (whether JDBC or JTA). When in a transaction, the index update is schedule for the transaction commit (and discarded in case of transaction rollback). You can think of this as the regular (infamous) autocommit vs transactional behavior. From a performance perspective, the <emphasis>in transaction</emphasis> mode is recommended. All the index updates are handled for you without you having to use the Apache Lucene APIs.
</para>
<para>
To interact with Apache Lucene indexes, Hibernate Search has the notion of <classname>DirectoryProvider</classname>. A directory provider will manage a given Lucene <classname>Directory</classname> type. You can configure directory providers to adjust the directory target.
</para>
<para>
- <productname>Hibernate Search</productname> can also use a Lucene index to search an entity and return a (list of) managed entity saving you from the tedious Object / Lucene Document mapping and low level Lucene APIs. The application code use the unified <classname>org.hibernate.Query</classname> API exactly the way a HQL or native query would be done.
+ Hibernate Search can also use a Lucene index to search an entity and return a (list of) managed entity saving you from the tedious Object / Lucene Document mapping and low level Lucene APIs. The application code use the unified <classname>org.hibernate.Query</classname> API exactly the way a HQL or native query would be done.
</para>
</section>
@@ -30,7 +30,7 @@
<section id="Configuration-Directory_configuration">
<title>Directory configuration</title>
<para>
- Apache Lucene has a notion of Directory where the index is stored. The Directory implementation can be customized but Lucene comes bundled with a file system and a full memory implementation. <productname>Hibernate Search</productname> has the notion of <literal>DirectoryProvider</literal> that handle the configuration and the initialization of the Lucene Directory.
+ Apache Lucene has a notion of Directory where the index is stored. The Directory implementation can be customized but Lucene comes bundled with a file system and a full memory implementation. Hibernate Search has the notion of <literal>DirectoryProvider</literal> that handle the configuration and the initialization of the Lucene Directory.
</para>
<table id="Directory_configuration-List_of_built_in_Directory_Providers">
<title>List of built-in Directory Providers</title>
@@ -138,7 +138,8 @@
<para>
First, we must declare a persistent class as indexable. This is done by annotating the class with <literal>@Indexed</literal> (all entities not annotated with <literal>@Indexed</literal> will be ignored by the indexing process):
</para>
-<programlisting>@Entity<emphasis role="bold">@Indexed(index="indexes/essays")</emphasis>
+<programlisting>@Entity<emphasis role="bold">
+ @Indexed(index="indexes/essays")</emphasis>
public class Essay {
...
}
@@ -170,10 +171,10 @@
These attributes are part of the <literal>@Field</literal> annotation.
</para>
<para>
- Whether or not you want to store the data depends on how you wish to use the index query result. As of today, for a pure <productname>Hibernate Search</productname> usage, storing is not necessary. Whether or not you want to tokenize a property or not depends on whether you wish to search the element as is, or only normalized part of it. It make sense to tokenize a text field, but it does not to do it for a date field (or an id field).
+ Whether or not you want to store the data depends on how you wish to use the index query result. As of today, for a pure Hibernate Search usage, storing is not necessary. Whether or not you want to tokenize a property or not depends on whether you wish to search the element as is, or only normalized part of it. It make sense to tokenize a text field, but it does not to do it for a date field (or an id field).
</para>
<para>
- Finally, the id property of an entity is a special property used by <productname>Hibernate Search</productname> to ensure index unicity of a given entity. By design, an id has to be stored and must not be tokenized. To mark a property as index id, use the <literal>@DocumentId</literal> annotation.
+ Finally, the id property of an entity is a special property used by Hibernate Search to ensure index unicity of a given entity. By design, an id has to be stored and must not be tokenized. To mark a property as index id, use the <literal>@DocumentId</literal> annotation.
</para>
<programlisting>@Entity
@Indexed(index="indexes/essays")
@@ -203,7 +204,8 @@
Lucene has the notion of <emphasis>boost factor</emphasis>. It's a way to give more weigth to a field or to an indexed element over an other during the indexation process. You can use <literal>@Boost</literal> at the field or the class level.
</para>
<programlisting>@Entity
- at Indexed(index="indexes/essays")<emphasis role="bold">@Boost(2)</emphasis>
+ at Indexed(index="indexes/essays")
+<emphasis role="bold">@Boost(2)</emphasis>
public class Essay {
...
@@ -232,7 +234,7 @@
<section id="Hibernate_Search_Apache_Lucene_Integration-PropertyField_Bridge">
<title>Property/Field Bridge</title>
<para>
- All field of a full text index in Lucene have to be represented as Strings. Ones Java properties have to be indexed in a String form. For most of your properties, <productname>Hibernate Search</productname> does the translation job for you thanks to a built-in set of bridges. In some cases, though you need a fine grain control over the translation process.
+ All field of a full text index in Lucene have to be represented as Strings. For most of your properties, Hibernate Search does the translation job for you thanks to a built-in set of bridges. In some cases, though you need a fine grain control over the translation process.
</para>
<section id="PropertyField_Bridge-Built_in_bridges">
<title>Built-in bridges</title>
@@ -247,7 +249,7 @@
<term>null</term>
<listitem>
<para>
- null elements are not indexed. Lucene does not support null elements and this does not make much sense either.
+ elements are not indexed. Lucene does not support null elements and this does not make much sense either.
</para>
</listitem>
</varlistentry>
@@ -267,7 +269,7 @@
Using a Range query is debattable and has drawbacks, an alternative approach is to use a Filter query which will filter the result query to the appropriate range.
</para>
<para>
- <productname>Hibernate Search</productname> will support a padding mechanism
+ Hibernate Search will support a padding mechanism
</para>
</footnote>
</para>
@@ -277,7 +279,7 @@
<term>java.util.Date</term>
<listitem>
<para>
- Dates are stored as yyyyMMddHHmmssSSS in GMT time (200611072203012 for Nov 7th of 2006 4:03PM and 12ms EST). You shouldn't really bother with the internal format. What is important is that when using a DateRange Query, you should know that the dates have to be expressed in GMT time.
+ Dates are stored as yyyyMMddHHmmssSSS in GMT time (20061107220304012 for Nov 7th of 2006 4:03PM 4seconds and 12ms EST). You shouldn't really bother with the internal format. What is important is that when using a DateRange Query, you should know that the dates have to be expressed in GMT time.
</para>
<para>
Usually, storing the date up to the milisecond is not necessary. <literal>@DateBridge</literal> defines the appropriate resolution you are willing to store in the index (<literal><literal>@DateBridge(resolution=Resolution.DAY)</literal></literal>). The date pattern will then be truncated accordingly.
@@ -308,7 +310,7 @@
<section id="Custom_Bridge-StringBridge">
<title>StringBridge</title>
<para>
- The simpliest custom solution is to give <productname>Hibernate Search</productname> an implementation of your expected <emphasis>object to String</emphasis> bridge. To do so you need to implements the <literal>org.hibernate.search.bridge.StringBridge</literal> interface
+ The simpliest custom solution is to give Hibernate Search an implementation of your expected <emphasis>object to String</emphasis> bridge. To do so you need to implements the <literal>org.hibernate.search.bridge.StringBridge</literal> interface
</para>
<programlisting>/**
* Padding Integer bridge.
@@ -416,7 +418,7 @@
<section id="Custom_Bridge-FieldBridge">
<title>FieldBridge</title>
<para>
- Some usecase requires more than a simple object to string translation when mapping a property to a Lucene index. To give you most of the flexibility you can also implement a bridge as a <classname>FieldBridge</classname>. This interface give you a property value and let you map it the way you want in your Lucene <classname>Document</classname>.This interface is very similar in its concept to the <productname>Hibernate</productname><classname>UserType</classname>.
+ Some usecase requires more than a simple object to string translation when mapping a property to a Lucene index. To give you most of the flexibility you can also implement a bridge as a <classname>FieldBridge</classname>. This interface give you a property value and let you map it the way you want in your Lucene <classname>Document</classname>.This interface is very similar in its concept to the Hibernate<classname>UserType</classname>.
</para>
<para>
You can for example store a given property in two different document fields
@@ -469,10 +471,10 @@
<section id="Hibernate_Search_Apache_Lucene_Integration-Querying">
<title>Querying</title>
<para>
- The second most important capability of <productname>Hibernate Search</productname> is the ability to execute a Lucene query and retrieve entities managed by an Hibernate session, providing the power of Lucene without living the Hibernate paradygm, and giving another dimension to the Hibernate classic search mechanisms (HQL, Criteria query, native SQL query).
+ The second most important capability of Hibernate Search is the ability to execute a Lucene query and retrieve entities managed by an Hibernate session, providing the power of Lucene without living the Hibernate paradygm, and giving another dimension to the Hibernate classic search mechanisms (HQL, Criteria query, native SQL query).
</para>
<para>
- To access the <productname>Hibernate Search</productname> querying facilities, you have to use an Hibernate <classname>FullTextSession</classname>. A SearchSession wrap an regular <classname>org.hibernate.Session</classname> to provide query and indexing capabilities.
+ To access the Hibernate Search querying facilities, you have to use an Hibernate <classname>FullTextSession</classname>. A SearchSession wrap an regular <classname>org.hibernate.Session</classname> to provide query and indexing capabilities.
</para>
<programlisting>Session session = sessionFactory.openSession();
...
@@ -489,10 +491,10 @@
List result = fullTextQuery.list(); //return a list of managed objects
</programlisting>
<para>
- The Hibernate query built on top of the Lucene query is a regular <literal>org.hibernate.Query</literal>, you are is the same paradygm as the other Hibernate query facilities (HQL, Native or Criteria). The regular <literal>list()</literal>, <literal>uniqueResult()</literal>, <literal>iterate()</literal> and <literal>scroll()</literal> can be used.
+ The Hibernate query built on top of the Lucene query is a regular <literal>org.hibernate.Query</literal>, which is the same as other Hibernate query facilities (HQL, Native or Criteria). The regular <literal>list()</literal>, <literal>uniqueResult()</literal>, <literal>iterate()</literal> and <literal>scroll()</literal> can be used.
</para>
<para>
- If you expect a reasonnable result number and expect to work on all of them, <methodname>list()</methodname> or <methodname>uniqueResult()</methodname> are recommanded. <methodname>list()</methodname> work best if the entity <literal>batch-size</literal> is set up properly. Note that Hibernate Seach has to process all Lucene Hits elements when using <methodname>list()</methodname>, <methodname>uniqueResult()</methodname> and <methodname>iterate()</methodname>. If you wish to minimize Lucene document loading, <methodname>scroll()</methodname> is more appropriate, Don't forget to close the <classname>ScrollableResults</classname> object when you're done, since it keeps Lucene resources.
+ If you expect a reasonable result number and expect to work on all of them, <methodname>list()</methodname> or <methodname>uniqueResult()</methodname> are recommanded. <methodname>list()</methodname> work best if the entity <literal>batch-size</literal> is set up properly. Note that Hibernate Seach has to process all Lucene Hits elements when using <methodname>list()</methodname>, <methodname>uniqueResult()</methodname> and <methodname>iterate()</methodname>. If you wish to minimize Lucene document loading, <methodname>scroll()</methodname> is more appropriate, Don't forget to close the <classname>ScrollableResults</classname> object when you're done, since it keeps Lucene resources.
</para>
<para>
An efficient way to work with queries is to use pagination. The pagination API is exactly the one available in <classname>org.hibernate.Query</classname>:
Modified: projects/docs/enterprise/4.2.7/Hibernate/Annotations_Reference_Guide/en-US/Xml-Overriding.xml
===================================================================
--- projects/docs/enterprise/4.2.7/Hibernate/Annotations_Reference_Guide/en-US/Xml-Overriding.xml 2009-03-12 03:29:56 UTC (rev 85759)
+++ projects/docs/enterprise/4.2.7/Hibernate/Annotations_Reference_Guide/en-US/Xml-Overriding.xml 2009-03-12 04:42:44 UTC (rev 85760)
@@ -260,7 +260,7 @@
<section id="Principles-Property_level_metadata">
<title>Property level metadata</title>
<para>
- You can of course defines XML overriding for properties. If metadata complete is defined, then additional properties (ie at the Java level) will be ignored. Otherwise, once you start overriding a property, all annotations on the given property are ignored. All property level metadata behave in <literal>entity/attributes</literal>, <literal>mapped-superclass/attributes</literal> or <literal>embeddable/attributes</literal>.
+ You can of course define XML overriding for properties. If metadata complete is defined, then additional properties (ie at the Java level) will be ignored. Otherwise, once you start overriding a property, all annotations on the given property are ignored. All property level metadata resides in <literal>entity/attributes</literal>, <literal>mapped-superclass/attributes</literal> or <literal>embeddable/attributes</literal>.
</para>
<programlisting> <attributes>
<id name="id">
@@ -295,7 +295,7 @@
<section id="Principles-Association_level_metadata">
<title>Association level metadata</title>
<para>
- You can define XML overriding for associations. All association level metadata behave in <literal>entity/attributes</literal>, <literal>mapped-superclass/attributes</literal> or <literal>embeddable/attributes</literal>.
+ You can define XML overriding for associations. All association level metadata resides in <literal>entity/attributes</literal>, <literal>mapped-superclass/attributes</literal> or <literal>embeddable/attributes</literal>.
</para>
<programlisting> <attributes>
<one-to-many name="players" fetch="EAGER">
Modified: projects/docs/enterprise/4.3.5/Hibernate/Annotations_Reference_Guide/en-US/Entity.xml
===================================================================
--- projects/docs/enterprise/4.3.5/Hibernate/Annotations_Reference_Guide/en-US/Entity.xml 2009-03-12 03:29:56 UTC (rev 85759)
+++ projects/docs/enterprise/4.3.5/Hibernate/Annotations_Reference_Guide/en-US/Entity.xml 2009-03-12 04:42:44 UTC (rev 85760)
@@ -813,8 +813,8 @@
@Entity
public class Customer implements Serializable {
@OneToOne(cascade = CascadeType.ALL)
- <emphasis role="bold">@JoinTable(name = "CustomerPassports" joinColumns = @JoinColumn(name="customer_fk"),</emphasis>
- <emphasis role="bold">inverseJoinColumns = @JoinColumns(name="passport_fk")
+ <emphasis role="bold">@JoinTable(name = "CustomerPassports", joinColumns = @JoinColumn(name="customer_fk"),</emphasis>
+ <emphasis role="bold">inverseJoinColumns = @JoinColumn(name="passport_fk")
)</emphasis>
public Passport getPassport() {
...
@@ -873,7 +873,7 @@
</programlisting>
<para>
- You can alse map a many to one association through an association table. This association table described by the <literal>@JoinTable</literal> annotation will contains a foreign key referencing back the entity table (through <literal>@JoinTable.joinColumns</literal>) and a a foreign key referencing the target entity table (through <literal>@JoinTable.inverseJoinColumns</literal>).
+ You can also map a many to one association through an association table. This association table described by the <literal>@JoinTable</literal> annotation will contains a foreign key referencing back the entity table (through <literal>@JoinTable.joinColumns</literal>) and a foreign key referencing the target entity table (through <literal>@JoinTable.inverseJoinColumns</literal>).
</para>
<programlisting>
@Entity()
@@ -929,7 +929,7 @@
</row>
<row>
<entry>
- Bag semantic with primary key (withtout the limitations of Bag semantic)
+ Bag semantic with primary key (without the limitations of Bag semantic)
</entry>
<entry>
java.util.List, java.util.Collection
@@ -1169,7 +1169,7 @@
public class Employee implements Serializable {
@ManyToMany(
cascade={CascadeType.PERSIST, CascadeType.MERGE},
- mappedBy="employees"
+ mappedBy="employees",
targetEntity=Employer.class
)
public Collection getEmployers() {
@@ -1182,7 +1182,7 @@
We've already shown the many declarations and the detailed attributes for associations. We'll go deeper in the <literal>@JoinTable</literal> description, it defines a <literal>name</literal>, an array of join columns (an array in annotation is defined using { A, B, C }), and an array of inverse join columns. The latter ones are the columns of the association table which refer to the <classname>Employee</classname> primary key (the "other side").
</para>
<para>
- As seen previously, the other side don't have to (must not) describe the physical mapping: a simple <literal>mappedBy</literal> argument containing the owner side property name bind the two.
+ As seen previously, the other side must not describe the physical mapping: a simple <literal>mappedBy</literal> argument containing the owner side property name bind the two.
</para>
</sect5><sect5 id="Many_to_many-Default_values"><title>Default values</title>
<para>
@@ -1450,7 +1450,7 @@
org.hibernate.cacheable
</entry>
<entry>
- Whether the query should interact with the second level cache (defualt to false)
+ Whether the query should interact with the second level cache (default to false)
</entry>
</row>
<row>
@@ -1514,7 +1514,7 @@
</table>
</sect2><sect2 id="Mapping_Queries-Mapping_native_queries" revision="2"><title>Mapping native queries</title>
<para>
- You can also map a native query (ie a plain SQL query). To achieve that, you need to describe the SQL resultset structure using <literal>@SqlResultSetMapping</literal> (or <literal>@SqlResultSetMappings</literal> if you plan to define several resulset mappings). Like <literal>@NamedQuery</literal>, a <literal>@SqlResultSetMapping</literal> can be defined at class level or in a JPA XML file. However its scope is global to the application.
+ You can also map a native query (ie a plain SQL query). To achieve that, you need to describe the SQL resultset structure using <literal>@SqlResultSetMapping</literal> (or <literal>@SqlResultSetMappings</literal> if you plan to define several resultset mappings). Like <literal>@NamedQuery</literal>, a <literal>@SqlResultSetMapping</literal> can be defined at class level or in a JPA XML file. However its scope is global to the application.
</para>
<para>
As we will see, a <literal>resultSetMapping</literal> parameter is defined in <literal>@NamedNativeQuery</literal>, it represents the name of a defined <literal>@SqlResultSetMapping</literal>. The resultset mapping declares the entities retrieved by this native query. Each field of the entity is bound to an SQL alias (or column name). All fields of the entity including the ones of subclasses and the foreign key columns of related entities have to be present in the SQL query. Field definitions are optional provided that they map to the same column name as the one declared on the class property.
@@ -1543,7 +1543,7 @@
<para>
In the above example, the <literal>night&area</literal> named query use the <literal>joinMapping</literal> result set mapping. This mapping returns 2 entities, <literal>Night</literal> and <literal>Area</literal>, each property is declared and associated to a column name, actually the column name retrieved by the query. Let's now see an implicit declaration of the property / column.
</para>
-<programlisting>@Entity<emphasis role="bold">@SqlResultSetMapping(name="implicit",</emphasis>
+<programlisting>@Entity<emphasis role="bold"> @SqlResultSetMapping(name="implicit",</emphasis>
<emphasis role="bold">entities=@EntityResult(entityClass=org.hibernate.test.annotations.query.SpaceShip.class))</emphasis>
<emphasis role="bold">@NamedNativeQuery(name="implicitSample", query="select * from SpaceShip",</emphasis>
<emphasis role="bold">resultSetMapping="implicit")</emphasis>
@@ -1601,7 +1601,7 @@
query="select name, model, speed, lname as lastn, fname as firstn, length, width,
length * width as surface from SpaceShip",
resultSetMapping="compositekey")
-} )
+
public class SpaceShip {
private String name;
private String model;
@@ -1794,8 +1794,8 @@
optimisticLock = OptimisticLockType.ALL,
polymorphism = PolymorphismType.EXPLICIT)
@Where(clause="1=1")
- at org.hibernate.annotations.Table(name="Forest", indexes = { @Index(name="idx",
-columnNames = { "name", "length" } ) } )
+ at org.hibernate.annotations.Table(appliesTo="Forest", indexes = { @Index(name="idx",
+columnNames = { "appliesTo", "length" } ) } )
public class Forest { ... }
</programlisting>
<programlisting>@Entity
@@ -1943,7 +1943,7 @@
public long getObjectVolume()
</programlisting>
<para>
- The SQL fragment can be as complex as you want avec even include subselects.
+ The SQL fragment can be as complex as you want, and can even include subselects.
</para>
</sect3><sect3 id="Property-Type"><title>Type</title>
<para>
@@ -2043,7 +2043,7 @@
</para>
</sect3><sect3 id="Property-Target"><title>@Target</title>
<para>
- Sometimes, the type guessed by reflection is not the one you want Hibernate to use. This is especially true on components when an interface is used. You can use <literal>@Target</literal> to by pass the reflection guessing mechanism (very much like the <literal>targetEntity</literal> attribute available on associations.
+ Sometimes, the type guessed by reflection is not the one you want Hibernate to use. This is especially true on components when an interface is used. You can use <literal>@Target</literal> to bypass the reflection guessing mechanism (very much like the <literal>targetEntity</literal> attribute available on associations.
</para>
<programlisting> @Embedded
<emphasis role="bold">@Target(OwnerImpl.class)</emphasis>
@@ -2376,7 +2376,7 @@
return nickNames;
}
- <emphasis role="bold">@CollectionOfElements @JoinTable( table=@Table(name="BoyFavoriteNumbers"), </emphasis>
+ <emphasis role="bold">@CollectionOfElements @JoinTable( name="BoyFavoriteNumbers",</emphasis>
<emphasis role="bold">joinColumns = @JoinColumn(name="BoyId") ) @Column(name="favoriteNumber",</emphasis>
<emphasis role="bold">nullable=false)</emphasis>
@IndexColumn(name="nbr_index")
@@ -2466,7 +2466,7 @@
</note>
</sect4></sect3></sect2><sect2 id="Hibernate_Annotation_Extensions-Cache"><title>Cache</title>
<para>
- In order to optimize your database accesses, you can activave the so called second level cache of Hibernate. This cache is configurable on a per entity and per collection basis.
+ In order to optimize your database accesses, you can activate the so called second level cache of Hibernate. This cache is configurable on a per entity and per collection basis.
</para>
<para>
<literal>@org.hibernate.annotations.Cache</literal> defines the caching strategy and region of a given second level cache. This annotation can be applied on the root entity (not the sub entities), and on the collections.
@@ -2534,7 +2534,7 @@
</programlisting>
</para>
<para>
- When the collection use an association table as a relational representation, you might want to apply the filter condition to the association table itself or to the target entity table. To apply the constraint on the target entity, use the regular <literal>@Filter</literal> annotation. However, if you wan to target the association table, use the <literal>@FilterJoinTable</literal> annotation.
+ When the collection use an association table as a relational representation, you might want to apply the filter condition to the association table itself or to the target entity table. To apply the constraint on the target entity, use the regular <literal>@Filter</literal> annotation. However, if you want to target the association table, use the <literal>@FilterJoinTable</literal> annotation.
</para>
<programlisting> @OneToMany
@JoinTable
@@ -2600,7 +2600,7 @@
</para>
</sect2><sect2 id="Hibernate_Annotation_Extensions-Custom_SQL_for_CRUD_operations"><title>Custom SQL for CRUD operations</title>
<para>
- Hibernate gives you the avility to override every single SQL statement generated. We have seen native SQL query usage already, but you can also override the SQL statement used to load or change the state of entities.
+ Hibernate gives you the ability to override every single SQL statement generated. We have seen native SQL query usage already, but you can also override the SQL statement used to load or change the state of entities.
</para>
<programlisting>@Entity
@Table(name="CHAOS")
@@ -2619,7 +2619,10 @@
private String nickname;
</programlisting>
<para>
- <literal>@SQLInsert</literal>, <literal>@SQLUpdate</literal>, <literal>@SQLDelete</literal>, <literal>@SQLDeleteAll</literal> respectively override the INSERT statement, UPDATE statement, DELETE statement, DELETE statement to remove all entities.
+ <literal>@SQLInsert</literal>,
+ <literal>@SQLUpdate</literal>,
+ <literal>@SQLDelete</literal>,
+ <literal>@SQLDeleteAll</literal> respectively override the INSERT statement, UPDATE statement, DELETE statement, DELETE statement to remove all entities.
</para>
<para>
If you expect to call a store procedure, be sure to set the <literal>callable</literal> attribute to true (<literal>@SQLInsert(callable=true, ...)</literal>).
Modified: projects/docs/enterprise/4.3.5/Hibernate/Annotations_Reference_Guide/en-US/Lucene.xml
===================================================================
--- projects/docs/enterprise/4.3.5/Hibernate/Annotations_Reference_Guide/en-US/Lucene.xml 2009-03-12 03:29:56 UTC (rev 85759)
+++ projects/docs/enterprise/4.3.5/Hibernate/Annotations_Reference_Guide/en-US/Lucene.xml 2009-03-12 04:42:44 UTC (rev 85760)
@@ -15,13 +15,13 @@
Hibernate Search is made of an indexing engine and an index search engine. Both are backed by Apache Lucene.
</para>
<para>
- When an entity is inserted, updated or removed to/from the database, <productname>Hibernate Search</productname> will keep track of this event (through the Hibernate event system) and schedule an index update. When out of transaction, the update is executed right after the actual database operation. It is however recommended, for both your database and Hibernate Search, to execute your operation in a transaction (whether JDBC or JTA). When in a transaction, the index update is schedule for the transaction commit (and discarded in case of transaction rollback). You can think of this as the regular (infamous) autocommit vs transactional behavior. From a performance perspective, the <emphasis>in transaction</emphasis> mode is recommended. All the index updates are handled for you without you having to use the Apache Lucene APIs.
+ When an entity is inserted, updated or removed to/from the database, Hibernate Search will keep track of this event (through the Hibernate event system) and schedule an index update. When out of transaction, the update is executed right after the actual database operation. It is however recommended, for both your database and Hibernate Search, to execute your operation in a transaction (whether JDBC or JTA). When in a transaction, the index update is schedule for the transaction commit (and discarded in case of transaction rollback). You can think of this as the regular (infamous) autocommit vs transactional behavior. From a performance perspective, the <emphasis>in transaction</emphasis> mode is recommended. All the index updates are handled for you without you having to use the Apache Lucene APIs.
</para>
<para>
To interact with Apache Lucene indexes, Hibernate Search has the notion of <classname>DirectoryProvider</classname>. A directory provider will manage a given Lucene <classname>Directory</classname> type. You can configure directory providers to adjust the directory target.
</para>
<para>
- <productname>Hibernate Search</productname> can also use a Lucene index to search an entity and return a (list of) managed entity saving you from the tedious Object / Lucene Document mapping and low level Lucene APIs. The application code use the unified <classname>org.hibernate.Query</classname> API exactly the way a HQL or native query would be done.
+ Hibernate Search can also use a Lucene index to search an entity and return a (list of) managed entity saving you from the tedious Object / Lucene Document mapping and low level Lucene APIs. The application code use the unified <classname>org.hibernate.Query</classname> API exactly the way a HQL or native query would be done.
</para>
</section>
@@ -30,7 +30,7 @@
<section id="Configuration-Directory_configuration">
<title>Directory configuration</title>
<para>
- Apache Lucene has a notion of Directory where the index is stored. The Directory implementation can be customized but Lucene comes bundled with a file system and a full memory implementation. <productname>Hibernate Search</productname> has the notion of <literal>DirectoryProvider</literal> that handle the configuration and the initialization of the Lucene Directory.
+ Apache Lucene has a notion of Directory where the index is stored. The Directory implementation can be customized but Lucene comes bundled with a file system and a full memory implementation. Hibernate Search has the notion of <literal>DirectoryProvider</literal> that handle the configuration and the initialization of the Lucene Directory.
</para>
<table id="Directory_configuration-List_of_built_in_Directory_Providers">
<title>List of built-in Directory Providers</title>
@@ -138,7 +138,8 @@
<para>
First, we must declare a persistent class as indexable. This is done by annotating the class with <literal>@Indexed</literal> (all entities not annotated with <literal>@Indexed</literal> will be ignored by the indexing process):
</para>
-<programlisting>@Entity<emphasis role="bold">@Indexed(index="indexes/essays")</emphasis>
+<programlisting>@Entity<emphasis role="bold">
+ @Indexed(index="indexes/essays")</emphasis>
public class Essay {
...
}
@@ -170,10 +171,10 @@
These attributes are part of the <literal>@Field</literal> annotation.
</para>
<para>
- Whether or not you want to store the data depends on how you wish to use the index query result. As of today, for a pure <productname>Hibernate Search</productname> usage, storing is not necessary. Whether or not you want to tokenize a property or not depends on whether you wish to search the element as is, or only normalized part of it. It make sense to tokenize a text field, but it does not to do it for a date field (or an id field).
+ Whether or not you want to store the data depends on how you wish to use the index query result. As of today, for a pure Hibernate Search usage, storing is not necessary. Whether or not you want to tokenize a property or not depends on whether you wish to search the element as is, or only normalized part of it. It make sense to tokenize a text field, but it does not to do it for a date field (or an id field).
</para>
<para>
- Finally, the id property of an entity is a special property used by <productname>Hibernate Search</productname> to ensure index unicity of a given entity. By design, an id has to be stored and must not be tokenized. To mark a property as index id, use the <literal>@DocumentId</literal> annotation.
+ Finally, the id property of an entity is a special property used by Hibernate Search to ensure index unicity of a given entity. By design, an id has to be stored and must not be tokenized. To mark a property as index id, use the <literal>@DocumentId</literal> annotation.
</para>
<programlisting>@Entity
@Indexed(index="indexes/essays")
@@ -203,7 +204,8 @@
Lucene has the notion of <emphasis>boost factor</emphasis>. It's a way to give more weigth to a field or to an indexed element over an other during the indexation process. You can use <literal>@Boost</literal> at the field or the class level.
</para>
<programlisting>@Entity
- at Indexed(index="indexes/essays")<emphasis role="bold">@Boost(2)</emphasis>
+ at Indexed(index="indexes/essays")
+<emphasis role="bold">@Boost(2)</emphasis>
public class Essay {
...
@@ -232,7 +234,7 @@
<section id="Hibernate_Search_Apache_Lucene_Integration-PropertyField_Bridge">
<title>Property/Field Bridge</title>
<para>
- All field of a full text index in Lucene have to be represented as Strings. Ones Java properties have to be indexed in a String form. For most of your properties, <productname>Hibernate Search</productname> does the translation job for you thanks to a built-in set of bridges. In some cases, though you need a fine grain control over the translation process.
+ All field of a full text index in Lucene have to be represented as Strings. For most of your properties, Hibernate Search does the translation job for you thanks to a built-in set of bridges. In some cases, though you need a fine grain control over the translation process.
</para>
<section id="PropertyField_Bridge-Built_in_bridges">
<title>Built-in bridges</title>
@@ -247,7 +249,7 @@
<term>null</term>
<listitem>
<para>
- null elements are not indexed. Lucene does not support null elements and this does not make much sense either.
+ elements are not indexed. Lucene does not support null elements and this does not make much sense either.
</para>
</listitem>
</varlistentry>
@@ -267,7 +269,7 @@
Using a Range query is debattable and has drawbacks, an alternative approach is to use a Filter query which will filter the result query to the appropriate range.
</para>
<para>
- <productname>Hibernate Search</productname> will support a padding mechanism
+ Hibernate Search will support a padding mechanism
</para>
</footnote>
</para>
@@ -277,7 +279,7 @@
<term>java.util.Date</term>
<listitem>
<para>
- Dates are stored as yyyyMMddHHmmssSSS in GMT time (200611072203012 for Nov 7th of 2006 4:03PM and 12ms EST). You shouldn't really bother with the internal format. What is important is that when using a DateRange Query, you should know that the dates have to be expressed in GMT time.
+ Dates are stored as yyyyMMddHHmmssSSS in GMT time (20061107220304012 for Nov 7th of 2006 4:03PM 4seconds and 12ms EST). You shouldn't really bother with the internal format. What is important is that when using a DateRange Query, you should know that the dates have to be expressed in GMT time.
</para>
<para>
Usually, storing the date up to the milisecond is not necessary. <literal>@DateBridge</literal> defines the appropriate resolution you are willing to store in the index (<literal><literal>@DateBridge(resolution=Resolution.DAY)</literal></literal>). The date pattern will then be truncated accordingly.
@@ -308,7 +310,7 @@
<section id="Custom_Bridge-StringBridge">
<title>StringBridge</title>
<para>
- The simpliest custom solution is to give <productname>Hibernate Search</productname> an implementation of your expected <emphasis>object to String</emphasis> bridge. To do so you need to implements the <literal>org.hibernate.search.bridge.StringBridge</literal> interface
+ The simpliest custom solution is to give Hibernate Search an implementation of your expected <emphasis>object to String</emphasis> bridge. To do so you need to implements the <literal>org.hibernate.search.bridge.StringBridge</literal> interface
</para>
<programlisting>/**
* Padding Integer bridge.
@@ -416,7 +418,7 @@
<section id="Custom_Bridge-FieldBridge">
<title>FieldBridge</title>
<para>
- Some usecase requires more than a simple object to string translation when mapping a property to a Lucene index. To give you most of the flexibility you can also implement a bridge as a <classname>FieldBridge</classname>. This interface give you a property value and let you map it the way you want in your Lucene <classname>Document</classname>.This interface is very similar in its concept to the <productname>Hibernate</productname><classname>UserType</classname>.
+ Some usecase requires more than a simple object to string translation when mapping a property to a Lucene index. To give you most of the flexibility you can also implement a bridge as a <classname>FieldBridge</classname>. This interface give you a property value and let you map it the way you want in your Lucene <classname>Document</classname>.This interface is very similar in its concept to the Hibernate<classname>UserType</classname>.
</para>
<para>
You can for example store a given property in two different document fields
@@ -469,10 +471,10 @@
<section id="Hibernate_Search_Apache_Lucene_Integration-Querying">
<title>Querying</title>
<para>
- The second most important capability of <productname>Hibernate Search</productname> is the ability to execute a Lucene query and retrieve entities managed by an Hibernate session, providing the power of Lucene without living the Hibernate paradygm, and giving another dimension to the Hibernate classic search mechanisms (HQL, Criteria query, native SQL query).
+ The second most important capability of Hibernate Search is the ability to execute a Lucene query and retrieve entities managed by an Hibernate session, providing the power of Lucene without living the Hibernate paradygm, and giving another dimension to the Hibernate classic search mechanisms (HQL, Criteria query, native SQL query).
</para>
<para>
- To access the <productname>Hibernate Search</productname> querying facilities, you have to use an Hibernate <classname>FullTextSession</classname>. A SearchSession wrap an regular <classname>org.hibernate.Session</classname> to provide query and indexing capabilities.
+ To access the Hibernate Search querying facilities, you have to use an Hibernate <classname>FullTextSession</classname>. A SearchSession wrap an regular <classname>org.hibernate.Session</classname> to provide query and indexing capabilities.
</para>
<programlisting>Session session = sessionFactory.openSession();
...
@@ -489,10 +491,10 @@
List result = fullTextQuery.list(); //return a list of managed objects
</programlisting>
<para>
- The Hibernate query built on top of the Lucene query is a regular <literal>org.hibernate.Query</literal>, you are is the same paradygm as the other Hibernate query facilities (HQL, Native or Criteria). The regular <literal>list()</literal>, <literal>uniqueResult()</literal>, <literal>iterate()</literal> and <literal>scroll()</literal> can be used.
+ The Hibernate query built on top of the Lucene query is a regular <literal>org.hibernate.Query</literal>, which is the same as other Hibernate query facilities (HQL, Native or Criteria). The regular <literal>list()</literal>, <literal>uniqueResult()</literal>, <literal>iterate()</literal> and <literal>scroll()</literal> can be used.
</para>
<para>
- If you expect a reasonnable result number and expect to work on all of them, <methodname>list()</methodname> or <methodname>uniqueResult()</methodname> are recommanded. <methodname>list()</methodname> work best if the entity <literal>batch-size</literal> is set up properly. Note that Hibernate Seach has to process all Lucene Hits elements when using <methodname>list()</methodname>, <methodname>uniqueResult()</methodname> and <methodname>iterate()</methodname>. If you wish to minimize Lucene document loading, <methodname>scroll()</methodname> is more appropriate, Don't forget to close the <classname>ScrollableResults</classname> object when you're done, since it keeps Lucene resources.
+ If you expect a reasonable result number and expect to work on all of them, <methodname>list()</methodname> or <methodname>uniqueResult()</methodname> are recommanded. <methodname>list()</methodname> work best if the entity <literal>batch-size</literal> is set up properly. Note that Hibernate Seach has to process all Lucene Hits elements when using <methodname>list()</methodname>, <methodname>uniqueResult()</methodname> and <methodname>iterate()</methodname>. If you wish to minimize Lucene document loading, <methodname>scroll()</methodname> is more appropriate, Don't forget to close the <classname>ScrollableResults</classname> object when you're done, since it keeps Lucene resources.
</para>
<para>
An efficient way to work with queries is to use pagination. The pagination API is exactly the one available in <classname>org.hibernate.Query</classname>:
Modified: projects/docs/enterprise/4.3.5/Hibernate/Annotations_Reference_Guide/en-US/Xml-Overriding.xml
===================================================================
--- projects/docs/enterprise/4.3.5/Hibernate/Annotations_Reference_Guide/en-US/Xml-Overriding.xml 2009-03-12 03:29:56 UTC (rev 85759)
+++ projects/docs/enterprise/4.3.5/Hibernate/Annotations_Reference_Guide/en-US/Xml-Overriding.xml 2009-03-12 04:42:44 UTC (rev 85760)
@@ -260,7 +260,7 @@
<section id="Principles-Property_level_metadata">
<title>Property level metadata</title>
<para>
- You can of course defines XML overriding for properties. If metadata complete is defined, then additional properties (ie at the Java level) will be ignored. Otherwise, once you start overriding a property, all annotations on the given property are ignored. All property level metadata behave in <literal>entity/attributes</literal>, <literal>mapped-superclass/attributes</literal> or <literal>embeddable/attributes</literal>.
+ You can of course define XML overriding for properties. If metadata complete is defined, then additional properties (ie at the Java level) will be ignored. Otherwise, once you start overriding a property, all annotations on the given property are ignored. All property level metadata resides in <literal>entity/attributes</literal>, <literal>mapped-superclass/attributes</literal> or <literal>embeddable/attributes</literal>.
</para>
<programlisting> <attributes>
<id name="id">
@@ -295,7 +295,7 @@
<section id="Principles-Association_level_metadata">
<title>Association level metadata</title>
<para>
- You can define XML overriding for associations. All association level metadata behave in <literal>entity/attributes</literal>, <literal>mapped-superclass/attributes</literal> or <literal>embeddable/attributes</literal>.
+ You can define XML overriding for associations. All association level metadata resides in <literal>entity/attributes</literal>, <literal>mapped-superclass/attributes</literal> or <literal>embeddable/attributes</literal>.
</para>
<programlisting> <attributes>
<one-to-many name="players" fetch="EAGER">
More information about the jboss-cvs-commits
mailing list