HigherClassificationMap contains nulls

10440
Reporter: mdoering
Assignee: mdoering
Type: Bug
Summary: HigherClassificationMap contains nulls
Priority: Major
Resolution: Fixed
Status: Closed
Created: 2011-11-18 12:36:10.523
Updated: 2013-12-09 14:01:17.143
Resolved: 2011-11-21 10:55:39.652
        
Description: If you search for "Puma lentivirus" in the portal you get a "??? instead of the genus name in the results classification:
http://staging.gbif.org:8080/portal-web-dynamic/species/search?q=Puma+lentivirus

This seems to be because the web service already responds like this:
http://staging.gbif.org:8080/checklistbank-search-ws/search?q=Puma+lentivirus&facet=CHECKLIST&ff.CHECKLIST=GBIF%20Taxonomic%20Backbone

The solr search itself does not have that map, but only the real genus and its key, both present correctly:
http://jawa.gbif.org:8080/solr/select/?&fl=*,score&version=2.2&start=0&rows=10&indent=on&q=%28checklist_title%3A%22GBIF+Taxonomic+Backbone%22+AND+%28canonical_name%3A%22Puma+lentivirus%22%5E100.0+OR+scientific_name_ft%3A%22Puma+lentivirus%22%29%29

It might be a ws-client issue, but the json map should really not be used at all in the deserialisation, but the underlying individual kingdom,genus, etc values]]>
    

Author: mdoering@gbif.org
Created: 2011-11-21 10:36:42.892
Updated: 2011-11-21 10:36:42.892
        
Also the species page has the genus correctly shown via the same map but generated by mybatis in the Taxonomy section:
http://staging.gbif.org:8080/portal-web-dynamic/species/5923700
    

Author: mdoering@gbif.org
Created: 2011-11-21 10:48:38.642
Updated: 2011-11-21 10:48:38.642
        
The parent is null in this case and its the same as the genus.
So the NameUsage.getHigherClassificaitonMap inserts the parentKey/parent after the genus into the map, thereby overwriting the correct genus with the null parent value.

The underlying sql view was fixed already and uses now the full scientific name in case no canonical exists:
coalesce(parcn.scientific_name, parn.scientific_name) as parent,

For a quick fix without rebuilding the index the getMap method will not overwrite existing keys.