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

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&gt; > Hibernate.org > _______________________________________________ hibernate-dev mailing list hibernate-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev

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(a)hibernate.org&gt; >>> Hibernate.org >>> >> >> >> _______________________________________________ >> hibernate-dev mailing list >> hibernate-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/hibernate-dev > -- Steve Ebersole <steve(a)hibernate.org&gt; Hibernate.org

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(a)hibernate.org&gt; >>>>> Hibernate.org >>>>> >>>> >>>> >>>> _______________________________________________ >>>> hibernate-dev mailing list >>>> hibernate-dev(a)lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev >>> >> -- >> Steve Ebersole <steve(a)hibernate.org&gt; >> Hibernate.org >> >

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(a)hibernate.org&gt;: > 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(a)hibernate.org&gt; >> >>>>> Hibernate.org >> >>>>> >> >>>> >> >>>> >> >>>> _______________________________________________ >> >>>> hibernate-dev mailing list >> >>>> hibernate-dev(a)lists.jboss.org >> >>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev >> >>> >> >> -- >> >> Steve Ebersole <steve(a)hibernate.org&gt; >> >> Hibernate.org >> >> >> > >> > -- > Steve Ebersole <steve(a)hibernate.org&gt; > Hibernate.org > > _______________________________________________ > hibernate-dev mailing list > hibernate-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev >

In case of full-text search, we really need to reread the object graph to reindex (on insert and updates and sometimes even on delete when the object is contained in other object graphs). That would negate the whole bulk operation optimization in the first place. So having this event would be good for reports. (We don't yet have a decent error report structure but we are planning it). On 29 nov. 09, at 01:16, Steve Ebersole wrote: > Not sure of the use case y'all are talking about as not compelling. > You > simply do not want to support users performing bulk update/delete > statements when utilizing search?!? Surely I am misunderstanding? > > I do not get the JPA reference. JPA does not define events in the way > Hibernate does. It certainly does not define nor discuss firing > events > for JPAQL/Criteria queries. > > On Sat, 2009-11-28 at 18:34 +0100, Sanne Grinovero wrote: >> 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(a)hibernate.org&gt;: >>> 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(a)hibernate.org&gt; >>>>>>>>> Hibernate.org >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> hibernate-dev mailing list >>>>>>>> hibernate-dev(a)lists.jboss.org >>>>>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev >>>>>>> >>>>>> -- >>>>>> Steve Ebersole <steve(a)hibernate.org&gt; >>>>>> Hibernate.org >>>>>> >>>>> >>>> >>> -- >>> Steve Ebersole <steve(a)hibernate.org&gt; >>> Hibernate.org >>> >>> _______________________________________________ >>> hibernate-dev mailing list >>> hibernate-dev(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/hibernate-dev >>> > -- > Steve Ebersole <steve(a)hibernate.org&gt; > Hibernate.org > > _______________________________________________ > hibernate-dev mailing list > hibernate-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev

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&gt; > Hibernate.org >

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) Sanne _______________________________________________ hibernate-dev mailing list hibernate-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev