[hibernate-dev] firing proper events after HQL?

[Adam Warski]

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
>> 
>