[hibernate-dev] Some minor improvements to Hibernate Search

[Emmanuel Bernard]

On 23 oct. 09, at 23:00, Amin Mohammed-Coleman wrote:

> Hi All
> Thank you for your valuable feedback.
>
> I agree that the Spring integration should actually be done on the  
> Spring
> side.  To be honest I have been somewhat annoyed with Spring and  
> agree that
> putting Spring into the Hibernate Search isn't probably a good  
> idea.  It
> makes sense for Spring to be doing the work to integrate with  
> Hibernate
> Search.  I have created a Spring Integration Lucene indexing project  
> on
> Google code which basically does aysnc indexing, this application  
> takes in a
> directory and indexes files (extracts text using apache tika).
>
> 2) The reason for this came about when I was developing something  
> for our
> application.  Basically we have 2 products, one of the products has
> knowledge of the other so basically A knows certain things about B  
> however B
> doesn't know about A (our crazy codebase).   In B some entities are
> hibernate search indexed and some of the data is required in A.  So  
> instead
> of returning the entity to A, B publishes an event with some data  
> and then A
> gets the lucene document from the B's index (hope people are still  
> following
> me at this point), and populates an entity which is subsequently  
> indexed in
> A.  I created this method in A's codebase and thought that it would  
> be handy
> to get the raw lucene document without creating a FullTextQuery and  
> the do a
> search.  The aim is to read a document using a convenient method to  
> do this
> on the FullTextSession.

So basically, you:
  - load and change an entity E1 in B (2 I/O)
  - send a message with the change diff to A (1 I/O)
  - load B's index (1 I/O)
  - create an entity out of the document you've loaded from B's index  
(1 I/O for the doc load meaning you are storing data in the index  
making it bigger)
  - store the new entity and index it (2 I/O)

Why don't you do:
  - load and change an entity E1 in B (2 I/O)
  - send a message with the entity (1 I/O)
  - create an entity out of the entity passed as a message
  - store the new entity and index it (2 I/O)

>
> In relation to GigaSpaces, i started on this and created a openspaces
> project but there really hasnt been much momentum on it and as you  
> guys have
> done work around JGroups, JMS I thought it might be a nice addition.

It could certainly be a nice addition, I don't know GigaSpaces in  
detail but if you are thinking about putting indexes onto the data  
grid as opposed to the  it probably looks similar to what we have done  
with Infinispan. We have the infinispan prototype at ... [1] Sanne,  
can you point to the svn link

>  What I
> would like to do help as much as I can and I'm happy to do what you  
> guys
> need doing (writing documentation, writing tests, etc).

There are many areas where you can help.
On of them is the programmatic mapping API that I have started a while  
back. The concept is there I think but there are still many mappings  
missing and the doc is non existent.
http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-352
If you are interested, let me know and we could chat on IRC or  
something like that this week.

>  To be honest I'm
> hoping for some guidance from you guys.   As I mentioned before  
> Hibernate
> Search is a really great library and I would like to help whatever  
> way I
> can.
>
> P.S Hadoop and Hibernate Search?

I haven't thought about that yet as I barely know Hadoop. What would  
be the use case?


>
> Cheers
> Amin
>
>
>
> On Fri, Oct 23, 2009 at 7:24 PM, Emmanuel Bernard <emmanuel at hibernate.org 
> >wrote:
>
>> Hello,
>>
>> On 23 oct. 09, at 16:47, Amin Mohammed-Coleman wrote:
>>
>> Hi All
>>>
>>> I have been looking at the Hibernate Search codebase and I am very  
>>> keen to
>>> help out.  I have noticed some small changes I would like to  
>>> purpose (very
>>> small) and I hope I don't offend anyone by mentioning these.
>>>
>>> 1) Remove cyclic reference in JmsBackEndQueueProcessor and
>>> JmsBackEndQueueProcessorFactory.  It seems as though the factory  
>>> creates a
>>> processor and the processor depends on the factory.  The processor  
>>> only
>>> needs the queueConnection factory and jms queue which I think  
>>> should be
>>> passed to the processor instead of passing the factory.  The  
>>> object being
>>> created should not know about the factory.
>>>
>>
>> Whatever ;)
>>
>>
>>> 2) Create a convienence method (not sure where) that enables a  
>>> user to get
>>> the lucene document using either the fulltextsession.  So for  
>>> example the
>>> method would loook something like:
>>> fullTextSession.getDocument(Class<?> clazz, Serializable id);
>>> Under the hood it would delegate the work to the directory  
>>> providers and
>>> close the index readers.
>>>
>>
>> What's your use case exactly? I've never had such a need.
>>
>>
>>> 3) Provide integration with GigaSpaces which I had started but not
>>> completed.
>>>
>>
>> cool. It maybe time to cut Hibernate Search into a few subprojects.  
>> Hardy,
>> do you want to give it a thought?
>>
>>
>>> 4) Integration with Spring and maybe Spring Integration.
>>>
>>>
>> cool, maybe it could be another module, I don't want any unneeded
>> dependency on the core.
>>
>>
>>> Sorry if my mail is brief however I would be happy to discuss any  
>>> of the
>>> points further.
>>>
>>>
>>> Kind Regards
>>>
>>> Amin (amin-mc on the forums)
>>> _______________________________________________
>>> hibernate-dev mailing list
>>> hibernate-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>
>>
>>
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev