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
