Re: [hibernate-dev] firing proper events after HQL?

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 <steve(a)hibernate.org&gt;: >> 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 <steve(a)hibernate.org&gt; >>>>>>>> Hibernate.org >>>>>>>> >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> hibernate-dev mailing list >>>>>>> hibernate-dev(a)lists.jboss.org >>>>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev >>>>>> >>>>> -- >>>>> Steve Ebersole <steve(a)hibernate.org&gt; >>>>> Hibernate.org >>>>> >>>> >>> >> -- >> Steve Ebersole <steve(a)hibernate.org&gt; >> Hibernate.org >> >> _______________________________________________ >> hibernate-dev mailing list >> hibernate-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/hibernate-dev >> -- Steve Ebersole <steve(a)hibernate.org&gt; Hibernate.org _______________________________________________ hibernate-dev mailing list hibernate-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev