Hi, Hibernate Search will know if it needs to update an index document or insert a new one depending on the event type it recives from Hibernate Core.
So a first requirement is to make sure Hibernate Core knows if is updating an existing database record rather than inserting a new one - I guess this is already the case as otherwise you would have conflicts on primary keys, so I'm assuming this first step is resolved.
The second step is to make sure that Hibernate Search understands an existing document is logically "the same" as one it's creating, so that it will remove the old version rather than only inserting the new version. For this to work you have to make sure the existing Document in the index contains the two fields Hibernate Search uses to identify a document: the field _hibernate_class needs to contain the class name (this is a constant field name), and the field you mapped as @Id or @DocumentId must contain the identifier of the entity in it's string form: this field name is configurable in your mapping (so it must match the name you have given it), and the value string should also match the format being used by Hibernate Search.
I guess the simplest way to look at this format is to check with Luke which values you have in the index, then make sure that LuSQL includes the fields as Hibernate Search expects them, and/or define a StringBridge in Hibernate Search to customize the format of the ID to make sure it matches the format used by LuSQL.
Alternatively, you could use the MassIndexer provided by Hibernate Search to build the initial index instead of LuSQL. I'm new to LuSQL, is there some benefit of using it over the MassIndexer we provided?
_________________ Sanne http://in.relation.to/
|