Re: [hibernate-dev] firing proper events after HQL?

Hello, I don't exactly know how bulk operations work, and I didn't know that there's a temporary table with the affected ids available. But if so, then yes, such an event would solve the problem, in the way Steve described. (And I got asked about bulk operations quite a lot of times, always answered that it isn't possible :) ). I think that both Envers and Search would need the ids affected + the entity type + the type of the operation (delete, insert, update). If it's possible, it would be great to have that :) Adam On Nov 24, 2009, at 3:11 PM, Steve Ebersole wrote: > 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(a)hibernate.org&gt; > Hibernate.org > _______________________________________________ hibernate-dev mailing list hibernate-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev