Data Model: Review `equals` and `hashCode` methods for persistent objects

[tangobravo62]

For persistent objects the equals method may not work as expected. Most of the classes (with the notable exception of the recently corrected Product and ProcessingFacility) contain the code:

        if (!super.equals(obj))
            return false;

Probably this should read:

        // Same database object
        if (super.equals(obj))
            return true;

The first variant effectively makes comparing loaded objects and transient objects impossible (because the database IDs differ), and if the IDs match, the subsequent attribute-based check is more or less redundant. Presumably a logic like the general if (this == obj) return true; (as in the second variant) is more appropriate.

Since the code worked up to now, a careful review and test is required before performing a general change of the equals methods.

[tangobravo62]

Extended to cover hashCode, which needs reviewing, too, for two reasons:

• equals and hashCode should be aligned semantically,
• The current hashCode implementations seem to be inefficient for the handling of sets, i. e. they do not guarantee a good distribution of objects over hash buckets in the set. This may be a cause for the performance problems in ProductQueryService::executeQuery(), where towards the end of the method a ProductQuery is added to a set of ProductQueries in a product. Some auxiliary products are needed for each and every job step resulting in large sets of ProductQueries, and adding to these sets may take minutes!

[tangobravo62]

Fixed with commits 263e292, e28079f, 5776763, aa41d31, all included in prosEO 0.9.3.

Has been run successfully since the deployment of prosEO 0.9.3 in November 2022.