EDIT

The current solution solves the problem but contradicts the idea of UuidAndTitleCache (DTO). This idea is to not initialize any CDM objects. Already loading the rank contradicts this idea but is not so critical because the rank object is reused by different results. The name is definetly not.
We should find a solution without loading the name for performance reasons as performance is very important for searches.

Working on this code a couple of questions are coming up, since a couple of things are quire unclear:

1)

As last resort compare strategy UuidAndTitleCacheTaxonComparator falls back to return ((UUID)o1[0]).compareTo((UUID)o2[0]); is this by purpose, why not compare the taxonNode.id here?

2) UuidAndTitleCacheTaxonComparator is used by different methods which pass Object array with different content:

• TaxonNodeDaoHibernateImpl.getTaxonNodeDto(Integer limit, String pattern, UUID classificationUuid) ==> tn.uuid, tn.id, t.titleCache, t.name, rank
• TaxonNodeDaoHibernateImpl.getTaxonNodeUuidAndTitleCacheOfAcceptedTaxaByClassification(..) ==> nodes.uuid, nodes.id, taxon.titleCache, taxon.name, rank
• TaxonNodeDaoHibernateImpl.getUuidAndTitleCache(Integer limit, String pattern, UUID classificationUuid) ==> 'tn.uuid, tn.id, t.titleCache, name, name_rank'
• TaxonDaoHibernateImpl.getUuidAndTitleCache ==> tb.uuid, tb.id, tb.titleCache, tb.name.rank BUG: rank is passed instead of name here!
• IdentifiableDaoBase.getUuidAndTitleCache ==> uuid, id, titleCache SCARY: It seems as if this comparator has initially been used to compare arbitrary IndentifieableEntities. for my feeling this comparator is too much overloaded

Since UuidAndTitleCacheTaxonComparator is used a lot by methods it is quite unsave that it takes object arrays as parameters. We need a comparator for more specific dto class instead.

Question: Aren't all these UuidAndTitleCachemethods to be removed anyway?

Suggested solution:

• I will create specific comparator lioke SortableTaxonNodeQueryResultComparator implements Comparator<SortableTaxonNodeQueryResult> whereas SortableTaxonNodeQueryResult is a sortable dto which will never leave the persistence layer.

I have not checked the above but probably you are right that we should clean it up in such a way.
But I strongly recommend not to do this before the release as this is core functionality which is used at many places and therefore needs intensive testing. Also the related tickets belong to 5.14 and should be handled there.

The ticket here is only about handling null values correctly which can be done without huge changes.

Andreas Müller wrote:

The ticket here is only about handling null values correctly which can be done without huge changes.

Ok ok, I don't really agree, but will stick strictly to what is demanded in the ticket description:

1. I fixed the problem
2. Implemented a test for TaxonNodeDaoHibernateImpl.getUuidAndTitleCache(), which was not covered so far (BTW: Only few of these core functionality methods are covered by tests yet.)

The new test method obviously fails due to the problem described above http://int.e-taxonomy.eu/jenkins/job/cdmlib-INTEGRATION/11120/ :

java.lang.ClassCastException: eu.etaxonomy.cdm.model.name.TaxonName cannot be cast to eu.etaxonomy.cdm.model.name.Rank
    at eu.etaxonomy.cdm.model.taxon.UuidAndTitleCacheTaxonComparator.compare(UuidAndTitleCacheTaxonComparator.java:39)
    at eu.etaxonomy.cdm.model.taxon.UuidAndTitleCacheTaxonComparator.compare(UuidAndTitleCacheTaxonComparator.java:1)
 .....

this happens at this piece of code

        //Rank
        Rank rankTax1 = Rank.UNKNOWN_RANK();
        if (o1[3] != null){
            rankTax1 = (Rank)o1[3]; // <<<< ClassCastException !!!!
        }
        Rank rankTax2 = Rank.UNKNOWN_RANK();
        if (o2[3] != null){
            rankTax2 = (Rank)o2[3];
        }

Since this is core functionality I suggest to solve this problem instead of ignoring it.

I do not really understand this. The test failed because commit 919b6fe025ff1b9 did change the number of parameters in the SELECT statements compared to the orgiginal version (name was not a parameter in the SELECT statement before). I changed this back and everything seems to work as expected. At least the tests are running.

By the way, I saw that there is a new test data file TaxonNodeDaoHibernateImplTest.findWithoutRank.xml which seems to be a (more or less) copy of TaxonNodeDaoHibernateImplTest.xml.

I did not check the according test so there might be a reason why we need this new file and can't use the existing one. If there is a reason can we reduce it to the really necessary records to test findWithoutRank? The reason why I ask is that test datasets which are too large take time to maintain (mostly during model changes) and also the according tests are more difficult to understand if the test data is complex (and therefore the focus of the test does not become clear when you try to read it later).
Therefore we should try to create as less test data as possible and try to use as many test data as possible.
(if a new test data file is needed at all I guess all the AUD data and also data like TAXONNODE_EXCLUDEDNOTE, LANGUAGESTRING and maybe even REFERENCE is not needed. Also some fields are not needed (e.g. CREATED, UPDATED)