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 martinbraun...@aol.com www.github.com/s4ke -----Original Message----- From: Flemming Harms <flemming.ha...@gmail.com> To: Hibernate.org <hibernate-dev@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@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
