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 <steve(a)hibernate.org>
>
Hibernate.org
>