Either a "lazy structure" or the table name + utility method to read content of the table, as that's the operation all users of such listeners would need.
Adam On Nov 24, 2009, at 9:09 PM, Emmanuel Bernard wrote: > 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
