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(a)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(a)lists.jboss.org
>>
https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
>
>
_______________________________________________
hibernate-dev mailing list
hibernate-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev