Project

General

Profile

Actions

bug #9142

closed

The Agent search dialog shows duplicated entries

Added by Andreas Müller over 3 years ago. Updated about 3 years ago.

Status:
Closed
Priority:
New
Assignee:
Category:
taxeditor
Target version:
Start date:
Due date:
% Done:

90%

Estimated time:
Severity:
normal
Found in Version:

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

picture893-1.png (7.99 KB) picture893-1.png Andreas Müller, 07/10/2020 04:43 PM
Actions #1

Updated by Andreas Müller over 3 years ago

  • Description updated (diff)
Actions #2

Updated by Katja Luther over 3 years ago

  • Target version changed from Release 5.18 to Release 5.19
Actions #3

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.

Actions #4

Updated by Katja Luther over 3 years ago

  • % Done changed from 0 to 50
Actions #5

Updated by Andreas Müller over 3 years ago

can you shortly explain what the problem was and why the commit fixes it?

Actions #6

Updated by Andreas Müller over 3 years ago

  • Status changed from Resolved to Feedback
  • Assignee changed from Andreas Müller to Katja Luther
Actions #7

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.

Actions #8

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.

Actions #9

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.

Actions #10

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.

Actions #11

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.

Actions #12

Updated by Katja Luther about 3 years ago

  • Status changed from Feedback to Closed

cleaned the code and close ticket.

Actions

Also available in: Atom PDF