[hibernate-dev] firing proper events after HQL?

[Sanne Grinovero]

I don't need this in Search, in that context I agre with Emmanuel
about "user use case is not compelling enough."
Don't know however how important this is for Envers?
And how is the support for eventlisteners with Criteria/JPA2? Is the
spec stating that no events are fired after an HQL/whatever query?

just wondering,
Sanne

2009/11/28 Steve Ebersole <steve at hibernate.org>:
> Two difficulties I just realized:
>
> First is that we actually only use the temporary table approach in the
> case of update/delete against 'multi-table structures'.  In a basic or
> table-per-hierarchy entity structure the temporary table is currently
> not used.  If this is something y'all agree is needed, what I can do is
> to look at making the listeners influence the decision whether or not to
> use temporary tables (currently that decision is solely based on the
> entity structure).
>
> Second is the fact that the 'id table' rows are cleaned up immediately
> afterwards.  The Query#executeUpdate() process goes something like:
> 1) populate 'id table'
> 2) execute update/delete utilizing 'id table'
> (fire this new event)
> 3) clean up the 'id table'
>
>
> On Wed, 2009-11-25 at 14:46 +0100, Adam Warski wrote:
>> 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
>> >>
>> >
>>
> --
> 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
>