Hi,
Note: I am no core developer of Hibernate Search, but I am currently working on something
that looks quite similar to what you are doing :). One part of it is an updating mechanism
based on triggers
that uses the database as a event-storage as well. It's not the exact same thing, but
related.
https://github.com/Hotware/Hibernate-Search-JPA
The idea is quite nice, but after looking at the sourcecode I am wondering
how the different nodes are able to work together, because in
AbstractDatabaseHibernateSearchController you remove the entity
from the persistence context and I wasn't able to find code that would
make up for that.
Doesn't that mean that the other workers will not be able to read that entity?
Or will users of this need to implement their own synchronization mechanism between
the different nodes?
Martin Braun
martinbraun123(a)aol.com
www.github.com/s4ke
-----Original Message-----
From: Flemming Harms <flemming.harms(a)gmail.com>
To:
Hibernate.org <hibernate-dev(a)lists.jboss.org>
Sent: Tue, Aug 4, 2015 6:40 pm
Subject: [hibernate-dev] [Hibernate Search] Database back end worker
Hey guys
I want to introduce myself and a new database back-end worker, me
and
another guy have build for hibernate search. I already had some initial
talk
with Sanne regarding if this could be interested to the hibernate
search
project.
I have been working with Hibernate Search from some time and actually
done
various small custom modification to search since 3.x, especial
around
running in a cluster and indexing. To make a long story short when
we
upgraded Hibernate search we thought it would be ideal to use a SQL
database
as storage for lucene workers for 3 main reasons.
- The database was shared
between the nodes
- The workers was persistent in case of a node crash.
- No
master/slave
*In some way it’s very similar to the JMS back-end worker, where
the user
also have to implement a MDB that process the workers. In our case
they
will have to implement a job using something like quartz or a
timer
service. *
*We are using JPA as persistence layer for the database, even
it’s a fairly
simple entity we persistent, but it make sense for supporting
various
databases and schema update out of the box. We have tried to make it’s
as
easy as possible to set-up by minimizing the number of properties, and
it’s
all configurable from the persistence.xml*
*The actually work can* be
*find
here
https://github.com/umbrew/org.umbrew.hibernate.database.worker.backend
<
https://github.com/umbrew/org.umbrew.hibernate.database.worker.backend>*
*So
based on this introduction and the code, is this something you could
use? (of
course with the modification it requires to follow the design,
style, docs etc
for the search)*--
Kind regards
Flemming
Harms
_______________________________________________
hibernate-dev mailing
list
hibernate-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev