[hibernate-dev] firing proper events after HQL?

[Steve Ebersole]

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 at 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 <steve at hibernate.org>
> >> >>>>> Hibernate.org
> >> >>>>>
> >> >>>>
> >> >>>>
> >> >>>> _______________________________________________
> >> >>>> hibernate-dev mailing list
> >> >>>> hibernate-dev at lists.jboss.org
> >> >>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >> >>>
> >> >> --
> >> >> Steve Ebersole <steve at hibernate.org>
> >> >> Hibernate.org
> >> >>
> >> >
> >>
> > --
> > Steve Ebersole <steve at hibernate.org>
> > Hibernate.org
> >
> > _______________________________________________
> > hibernate-dev mailing list
> > hibernate-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >
-- 
Steve Ebersole <steve at hibernate.org>
Hibernate.org