But is there a way to get the list of ids generated by an insert after it has completed? (before it would be hard to do :) ).
Adam > Well only update and delete work the way I described wrt a temporary > table. inserts are handled completely differently. > > On Tue, 2009-11-24 at 19:53 +0100, Adam Warski wrote: >> 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 <st...@hibernate.org> >>> Hibernate.org >>> >> > -- > Steve Ebersole <st...@hibernate.org> > Hibernate.org > _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
