bug #9142
closedThe Agent search dialog shows duplicated entries
90%
Description
This happens in caryo_spp.
Things like this sometimes happen due multiple language representations of a term which is used in the underlying query. There is a workaround for this.
But there might be other reasons.
WGB:
Im Bulk-Editor erscheint das Team nur einmal, und die IDs deuten ja auch darauf hin, dass hier etwas faul ist.
Files
Updated by Katja Luther over 3 years ago
- Target version changed from Release 5.18 to Release 5.19
Updated by Katja Luther over 3 years ago
- Status changed from New to Resolved
- Assignee changed from Katja Luther to Andreas Müller
This should be fixed. Please review.
Updated by Katja Luther over 3 years ago
- % Done changed from 0 to 50
Applied in changeset taxeditor|359b77dda6efc328563cfd93e63aee841662b4e7.
Updated by Andreas Müller over 3 years ago
can you shortly explain what the problem was and why the commit fixes it?
Updated by Andreas Müller over 3 years ago
- Status changed from Resolved to Feedback
- Assignee changed from Andreas Müller to Katja Luther
Updated by Katja Luther over 3 years ago
- Status changed from Feedback to Resolved
- Assignee changed from Katja Luther to Andreas Müller
First I thought it was because the search method was called twice but the real cause was the wrong implementation of the getUuidAndAbbrevTitleCache method.
Updated by Andreas Müller over 3 years ago
- Status changed from Resolved to Feedback
- Assignee changed from Andreas Müller to Katja Luther
Thats what I thought. It is actually not really a wrong implementation of the method but due to the above described strange behavior of hibernate when using eager loading.
By the way can't we remove the commented line?
Also I wonder if not the more correct way to filter for classes is to use the class parameter in HQL as described here (https://docs.jboss.org/hibernate/orm/3.5/reference/de-DE/html/queryhql.html#queryhql-where) or here (https://stackoverflow.com/questions/8911894/hql-query-for-multiple-types-classes). I guess this way you can also use abstract superclasses like TeamOrPersonBase and do not have to distinguish each case. The current implementation is dangerous whenever the might be a new AgentBase subclass in future and probably does even now not work if you pass "AgenBase.class" as parameter which is a legal argument.
Updated by Katja Luther over 3 years ago
- Assignee changed from Katja Luther to Andreas Müller
Andreas Müller wrote:
Thats what I thought. It is actually not really a wrong implementation of the method but due to the above described strange behavior of hibernate when using eager loading.
By the way can't we remove the commented line?
Also I wonder if not the more correct way to filter for classes is to use the class parameter in HQL as described here (https://docs.jboss.org/hibernate/orm/3.5/reference/de-DE/html/queryhql.html#queryhql-where) or here (https://stackoverflow.com/questions/8911894/hql-query-for-multiple-types-classes). I guess this way you can also use abstract superclasses like TeamOrPersonBase and do not have to distinguish each case. The current implementation is dangerous whenever the might be a new AgentBase subclass in future and probably does even now not work if you pass "AgenBase.class" as parameter which is a legal argument.
I already thought about it, but thought that TeamOrPersonBase would not work, but it work. I changed the implementation in this way, please have a look.
Updated by Andreas Müller about 3 years ago
Katja Luther wrote:
Andreas Müller wrote:
Thats what I thought. It is actually not really a wrong implementation of the method but due to the above described strange behavior of hibernate when using eager loading.
By the way can't we remove the commented line?
Also I wonder if not the more correct way to filter for classes is to use the class parameter in HQL as described here (https://docs.jboss.org/hibernate/orm/3.5/reference/de-DE/html/queryhql.html#queryhql-where) or here (https://stackoverflow.com/questions/8911894/hql-query-for-multiple-types-classes). I guess this way you can also use abstract superclasses like TeamOrPersonBase and do not have to distinguish each case. The current implementation is dangerous whenever the might be a new AgentBase subclass in future and probably does even now not work if you pass "AgenBase.class" as parameter which is a legal argument.
I already thought about it, but thought that TeamOrPersonBase would not work, but it work. I changed the implementation in this way, please have a look.
I cleaned up the query code a bit further to make it simpler.
Updated by Andreas Müller about 3 years ago
- Assignee changed from Andreas Müller to Katja Luther
- % Done changed from 50 to 90
Andreas Müller wrote:
By the way can't we remove the commented line?
I deleted the line and also cleaned up the TaxEditor code further.
There is still the commented code for "createFilter()" starting at line 110. Can this be removed?
The ticket can be closed then.
Updated by Katja Luther about 3 years ago
- Status changed from Feedback to Closed
cleaned the code and close ticket.