[hibernate-dev] firing proper events after HQL?

[Emmanuel Bernard]

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
>