CO Query Returns Same Values for Taxon and Preferred Taxon Fields

[emd0083]

I’m seeing what appears to be unexpected behavior from the Query Builder when returning both Taxon and Preferred Taxon values in the same query.

For example, Villosa iris is a synonym of Cambarunio iris as defined in my taxon tree.

[!example]+ Query 1: ‘Taxon’ fields first

When I add Taxon fields before Preferred Taxon fields, the query returns “Villosa” for both columns.

Expected Result:

Catalog Number	Determinations - Current	Taxon - Genus	Taxon - Species	Preferred Taxon - Genus	Preferred Taxon - Species
9884	Yes	Villosa	iris	Cambarunio	iris

Instead, both values are returned as “Villosa”.

[!example]+ Query 2: ‘Preferred Taxon’ fields first
If I reverse the order and put Preferred Taxon - Genus before Taxon - Genus, both columns return “Cambarunio”.

Again, Taxon and Preferred Taxon values should differ for Genus, but instead both columns are taking the value of whichever field was first in the query.

[!example]+ Query 3: Forcing the relationship through ‘Taxon’
I also tried going through Taxon and then to Preferred Taxon, e.g.,
Taxon (any rank) Preferred Taxon

The result is still “Villosa” for both fields.

[!example]+ Query 4: With ‘Is Preferred’
I added Is Preferred for both (straight from Determination relationship)…

The Is Preferred values are correct, which suggests the query running on the backend can recognize both levels at the same time, but it conflagrates the return of Taxon and Preferred Taxon values and thus truncating the column header in the results to just Genus or Species.

The ‘Preferred Taxon’ shows correctly when rendered alongside ‘Taxon’ on the CO form, so I’m thinking it must be an issue with the query builder itself.

Is there something I am doing wrong with my query or is it a bug?

---

Specify 7 Version: v7.12.1.2

[lexiclevenger6]

Hi Emmy!

You are correct in that the issue is related to the Query Builder rather than your data. This is a bug related to issue #8560 on GitHub. I left a comment on the issue to let the developers know you encountered it! The bug leads to unexpected behaviors, like what you’ve described, when a query includes tree rank mappings through multiple relationships such as Taxon and Preferred Taxon. It was fixed in 7.12.1.1, but the resolution introduced more critical issues involving the query builder, so it was reversed in 7.12.1.2. I will explain a potential workaround for your query, but it may or may not be valuable for your use case since it changes how the results are organized.

The inclusion of a tree rank is what causes the problem, so it will not occur if you exclude ranks from the query. You can try using the (any rank), Parent, and Child relationships instead. Rather than searching for related records in a certain rank, the Parent and Child relationships search directly for the parent or child of the Taxon record used in the determination. Then, you can search for the parent of the parent, and so on, to search as far up the taxon tree as you want.

Import this query:
Show preferred and synonym.json (4.8 KB)

Keep in mind that since the Parent/Child relationships depend on the rank directly above/below the Taxon used in the determination rather than the rank defined in the query, the values in those columns will not always belong to the same rank. In the image below, record 000043577 is determined to a record at the Genus level. Record 000043578 is determined to a record at the Subspecies level. You can use the treeDefItem relationship to show you the rank name if needed, as shown in the image below.

Import this query:
Show preferred and synonym with rank name.json (8.6 KB)
Note: I turned off localized field labels for this query so you can see the schema names of the fields and relationships. Due to a bug, the treeDefItem column name appears as $-any in the query results.

I hope this helps! Please let me know if anything needs clarification.

Best,
Lexi