+1 for the idea of the database-based backend. Seems very useful.
One idea for improvement may be to group on (entity-type,id) and only
select the latest LuceneDatabaseWork per id. That way you'd avoid
propagation of potentially outdated index updates.
2015-08-09 17:51 GMT+02:00 Sanne Grinovero :
Hi,
yes creating issues on JIRA is what we normally do, feel free to create them!
They don't have to be sub-stasks; we use subtasks when there are
several "blocker" steps which need to be accomplished to get a feature
and it's so large that it needs to be split.
In this case I'd make a single JIRA
2015-08-05 23:38 GMT+02:00 Sanne Grinovero :
> Hi Flemming,
> welcome on this list!
>
> I waited a bit to reply myself, as you already know I like the
> proposal. Unfortunately many others are on holidays, so other feedback
> might be slow.
>
> Still I wouldn't let that slow you down and start the
Hi Flemming,
welcome on this list!
I waited a bit to reply myself, as you already know I like the
proposal. Unfortunately many others are on holidays, so other feedback
might be slow.
Still I wouldn't let that slow you down and start the works for
merging it; I already anticipated over chat that
Hi Martin
For this version the AbstractDatabaseHibernateSearchController is not able
to process Lucene workers simultaneously. When we build it our initial
requirement was only one node should process the workers at a time, but the
“master” was floating. We use Quartz to get this type of functiona
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 relat
