[hibernate-dev] firing proper events after HQL?

[Steve Ebersole]

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