<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Hi all,<br>
I have had time to work on Hibernate Lucene recently and finished the
work I wanted to do. This is a major rework and will bring both API and
index breaks, but for the good. This implements the core ideas that
were floating around for a while.<br>
<br>
<b>What's new<br>
<br>
</b>o Index querying<br>
Keeping the index uptodate is nice, but querying it is even better.<br>
A LuceneSession has been introduced (a wrapper of an Hibernate
session). You can now create a lucene query and get managed object back.<br>
luceneSession.createLuceneQuery(luceneQuery).list(); //get all matching
entities<br>
initialize all entities one by one: setting a sensitive batch-size
is critical<br>
future evolution: use of the Hibernate Core fetch profile once it is
exposed to the user<br>
luceneSession.createLuceneQuery(luceneQuery, Book.class,
Clock.class).iterate(); //get all matching entities of a given type<br>
iterate() read all the lucene index but initialize the entities on
demand<br>
luceneSession.createLuceneQuery(luceneQuery).scroll(); //use scrollable
resultset to maximize performance when a subset i needed.<br>
scroll() keep the index opened (Hits) and let you wald through it,
this methods is the most IO/memory efficient<br>
do not forget to close the Scrollable Resultset<br>
<br>
All three query methods support setFirstResult/setMaxResult. As a
matter of fact, the LuceneQuery return is an implementation of
org.hibernate.Query, so your code is unaware of Lucene<br>
<br>
o object (re)indexation. <br>
You can now index an object, even if you do
not apply any change on it. The index operation is batched to maximize
speed. (luceneSession.index()): If no tx is in progress, the indexing
is done immediately, otherwise the operations are batched and done
right after the transaction commit.<br>
<br>
o FieldBridge<br>
Like the Hibernate UserType, a FieldBridge is an interface aiming to do
the translation work between a property and it's indexed (ie String)
representation. This interface is very flexible and even allows you to
map a property into several index fields.<br>
For the simple cases: ie most cases, a StringBridge has been
introduced, it convert your property into a String to be indexed. The
API is much simpler to implement, so I expect most of the custom bridge
to use this approach<br>
<br>
o Built-in bridges<br>
There is a built-in support for Date (with resolution), Numbers (ie
java.lang.Number and its subclasses), and String.<br>
I'm willing to expand the support, please tell me what you need<br>
<br>
o New event listener / lucene interaction<br>
The Event listener has been reimplemented. It is now threadsafe (ie it
does not depends on the underlying Directory locking mechanism - in a
single VM). <br>
It fixes a flaw in the previous implementation that indexed entities
even when the transaction was rollbacked (yuk!). You should no longer
use the post-commit-* events but the post-* events, <br>
If no tx is in progress, the indexing is done immediately, otherwise
the operations are done right after the transaction commit.<br>
This reimplementation opens the doors to:<br>
- a better batching system (need some adjustments in Hibernate Core)<br>
- the ability to delegate the actual indexation to a remote machine
(through JMS or any other messaging mechanism).<br>
I say 'opens the doors' because the actual implementation is not there
yet (but is not hard I think).<br>
<br>
o New annotations<br>
First of all the project has be repackaged, the annotations are now all
under org.hibernate.lucene.annotations<br>
Second, the previous annotations have been deprecated to align with the
Lucene 2.0 APIs @DocumentId and @Field() are now to be used. The old
ones are still here but will be removed in a future release<br>
You can also annotate a property to use a custom field bridge
(@FieldBridge) and inject parameters<br>
@DateBridge allows you do define the resolution (YEAR, MONTH, ...) of a
Date to be indexed<br>
@Boost can be defined on an entity and on a property<br>
<br>
<br>
o Support for annotated fields<br>
Only annotated properties were supported, you now can annotate fields
as well<br>
<br>
o indexing<br>
As described earlier, the interaction with Lucene has been reworked to
allow better efficiency. <br>
Several entities per index, as well a class hierarchy indexing is now
supported<br>
<br>
o DirectoryProvider<br>
Still present a pluggable directory provider with 2 default
implementations (Memory and File system).<br>
<br>
<br>
<b>When do we get it and Feedbacks?</b><br>
I expect to release all this right after Hibernate Core 3.2.1 and as
soon as I update the documentation.<br>
Please have a look at the API and the feature set. Nothing is cast in
stone yet. I'll follow up with a What's next email.<br>
Can I have a preview? Yes, you can get the code from <br>
<a class="moz-txt-link-freetext" href="http://anonsvn.jboss.org/repos/hibernate/branches/Lucene_Integration/">http://anonsvn.jboss.org/repos/hibernate/branches/Lucene_Integration/</a><br>
(you need too get Hibernate Core from trunk of branch_3_2<br>
I also have uploaded a snapshot version of the javadoc
<a class="moz-txt-link-freetext" href="http://www.hibernate.org/~emmanuel/lucenesnapshot20061102/doc/api/">http://www.hibernate.org/~emmanuel/lucenesnapshot20061102/doc/api/</a>
check for the org.hibernate.lucene.* packages<br>
<br>
<br>
Question:<br>
Should it be part of the Hibernate Annotation 3.2.x series?<br>
Hibernate Lucene is considered experimental (ie still evolving). It
does break the applications using Hibernate Lucene right now, but the
migration will bring a big plus.<br>
If I release it as part of the 3.3.x series that binds me to a Core
release and will delay the adoption.<br>
Maybe it is time for a separate package (event if I don't think this
will really solve the problem)<br>
</body>
</html>