[hibernate-dev] firing proper events after HQL?

[Steve Ebersole]

How about a new event right at the moment after we have just collected
all the ids into the temp table?  

For envers, this would allow you to save off the current state prior to
the update/delete.

For search, this would allow you to "circle back" after the operation
and re-index those matching ids.

wdyt?


On Tue, 2009-11-24 at 08:20 +0100, Adam Warski wrote:
> Hello,
> 
> > a user on forums is posting about an HQL like
> > "delete from product where id = 4"
> > which - in case of Hibernate Search - is not going to remove the
> > relevant document from the index.
> > 
> > Another interesting case would be
> > "delete from product"
> > 
> > Any thoughts about this? Should we always use API when making changes?
> > (https://forum.hibernate.org/viewtopic.php?f=9&t=1001076)
> 
> In general listeners for any bulk operations aren't fired (in case of a bulk update the indexes won't be updated either). This is a problem also in Envers - where doing bulk operations doesn't cause any historical data to be written in the audit tables. What I normally advise users on the forum is to:
> 1) run a hql which updates the historical tables (bascially inserting new rows for each id affected by the hql to be executed)
> 2) run the original hql
> 
> For HSearch, I guess a solution would be to provide an API to tell HSearch that some range of ids of some entity changed. So the user would:
> 1) get the ids affected by the query (this usually means replacing delete/update by select)
> 2) run the original hql
> 3) pass the ids to hsearch so that it could update the indexes
> 
> However, I'm not sure if there would be much performance gain comparing using a bulk operation to a for-loop with entityManager.delete in that case (HSearch would have to handle each entity separately anyway; maybe not in case of a delete, but certainly in case of an update).
> 
-- 
Steve Ebersole <steve at hibernate.org>
Hibernate.org