[hibernate-dev] firing proper events after HQL?

[Emmanuel Bernard]

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