Not sure of the use case y'all are talking about as not compelling. You simply do not want to support users performing bulk update/delete statements when utilizing search?!? Surely I am misunderstanding?
I do not get the JPA reference. JPA does not define events in the way Hibernate does. It certainly does not define nor discuss firing events for JPAQL/Criteria queries. On Sat, 2009-11-28 at 18:34 +0100, Sanne Grinovero wrote: > I don't need this in Search, in that context I agre with Emmanuel > about "user use case is not compelling enough." > Don't know however how important this is for Envers? > And how is the support for eventlisteners with Criteria/JPA2? Is the > spec stating that no events are fired after an HQL/whatever query? > > just wondering, > Sanne > > 2009/11/28 Steve Ebersole <st...@hibernate.org>: > > Two difficulties I just realized: > > > > First is that we actually only use the temporary table approach in the > > case of update/delete against 'multi-table structures'. In a basic or > > table-per-hierarchy entity structure the temporary table is currently > > not used. If this is something y'all agree is needed, what I can do is > > to look at making the listeners influence the decision whether or not to > > use temporary tables (currently that decision is solely based on the > > entity structure). > > > > Second is the fact that the 'id table' rows are cleaned up immediately > > afterwards. The Query#executeUpdate() process goes something like: > > 1) populate 'id table' > > 2) execute update/delete utilizing 'id table' > > (fire this new event) > > 3) clean up the 'id table' > > > > > > On Wed, 2009-11-25 at 14:46 +0100, Adam Warski wrote: > >> 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 > >> >> > >> > > >> > > -- > > 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
