If you return a "lazy structure", we could avoid the overhead unless the data is needed :)
On 24 nov. 09, at 20:52, Steve Ebersole wrote: > I think it will just pass the table name. Too much overhead to > materialize all the ids when the event may not even be used. > > On Tue, 2009-11-24 at 20:21 +0100, Emmanuel Bernard wrote: >> Good idea, >> If we could have an event listener that indeed does provide the >> information lazily, we could definitely benefit from it. But that has >> a cost so I think I would still keep it optional on the HSearch side. >> >> On 24 nov. 09, at 19:53, 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 >>>> >>> >>> >>> _______________________________________________ >>> hibernate-dev mailing list >>> hibernate-dev@lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/hibernate-dev >> > -- > Steve Ebersole <st...@hibernate.org> > Hibernate.org > _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
