Well only update and delete work the way I described wrt a temporary
table.  inserts are handled completely  differently.

On Tue, 2009-11-24 at 19:53 +0100, 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
> > 
> 
-- 
Steve Ebersole <st...@hibernate.org>
Hibernate.org

_______________________________________________
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Reply via email to