Closed tangobravo62 closed 1 year ago
Extended to cover hashCode
, which needs reviewing, too, for two reasons:
equals
and hashCode
should be aligned semantically,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!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.
For persistent objects the
equals
method may not work as expected. Most of the classes (with the notable exception of the recently correctedProduct
andProcessingFacility
) contain the code:Probably this should read:
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.