[jira] [Updated] (PARQUET-1191) Type.hashCode() takes originalType into account but Type.equals() does not
[ https://issues.apache.org/jira/browse/PARQUET-1191?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Zoltan Ivanfi updated PARQUET-1191: --- Description: Taking originalType into account in Type.hashCode() but ignoring it in Type.equals() is inconsistent and violates hashCode-equals contract. If two Type instances that are equal according to equals() but have different logical types were ever put in a hash map, then both of the following cases are possible: * The two instances may accidentally have the same hash, which is consistent with the equals() method but is pure coincidence and has a very low probablility. * The two instances may have different hashes and end up in different buckets of a hash map, leading to a situation where we can't find a value in the hash map despite that it's equals() would return true. We should decide whether originalType is needed for an equality check or not. If it is, then it should be added to equals(). Otherwise it should be removed from hashCode(). was: Taking originalType into account in Type.hashCode() but ignoring it in Type.equals() is inconsistent and violates hashCode-equals contract. If two Type instances that are equal according to equals() but have different logical types were ever put in a hash map, then both of the following cases are possible: * The two instances may accidentally have the same hash, which is consistent with the equals() method but is pure coincidence and has a very low probablility. * The two instances may have different hashes and end up in different buckets of a hash map, leading to a situation where we can't find a value in the hash map despite that it's equals() would return true. We should decide > Type.hashCode() takes originalType into account but Type.equals() does not > -- > > Key: PARQUET-1191 > URL: https://issues.apache.org/jira/browse/PARQUET-1191 > Project: Parquet > Issue Type: Bug >Reporter: Gabor Szadovszky > > Taking originalType into account in Type.hashCode() but ignoring it in > Type.equals() is inconsistent and violates hashCode-equals contract. > If two Type instances that are equal according to equals() but have different > logical types were ever put in a hash map, then both of the following cases > are possible: > * The two instances may accidentally have the same hash, which is consistent > with the equals() method but is pure coincidence and has a very low > probablility. > * The two instances may have different hashes and end up in different buckets > of a hash map, leading to a situation where we can't find a value in the hash > map despite that it's equals() would return true. > We should decide whether originalType is needed for an equality check or not. > If it is, then it should be added to equals(). Otherwise it should be removed > from hashCode(). -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (PARQUET-1191) Type.hashCode() takes originalType into account but Type.equals() does not
[ https://issues.apache.org/jira/browse/PARQUET-1191?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Zoltan Ivanfi updated PARQUET-1191: --- Description: Taking originalType into account in Type.hashCode() but ignoring it in Type.equals() is inconsistent and violates hashCode-equals contract. If two Type instances that are equal according to equals() but have different logical types were ever put in a hash map, then both of the following cases are possible: * The two instances may accidentally have the same hash, which is consistent with the equals() method but is pure coincidence and has a very low probablility. * The two instances may have different hashes and end up in different buckets of a hash map, leading to a situation where we can't find a value in the hash map despite that it's equals() would return true. We should decide was: Taking originalType into account in Type.hashCode() but ignoring it in Type.equals() is inconsistent and violates hashCode-equals contract. If two Type instances that are equal according to equals() but have different logical types were ever put in a hash map, then both of the following cases are possible: * The two instances may accidentally have the same hash, which is consistent with the equals() method but is pure coincidence and has a very low probablility. * The two instances may have different hashes and end up in different buckets of a hash map, leading to a situation where we can't find a value in the hash map despite that it's equals() would return true. > Type.hashCode() takes originalType into account but Type.equals() does not > -- > > Key: PARQUET-1191 > URL: https://issues.apache.org/jira/browse/PARQUET-1191 > Project: Parquet > Issue Type: Bug >Reporter: Gabor Szadovszky > > Taking originalType into account in Type.hashCode() but ignoring it in > Type.equals() is inconsistent and violates hashCode-equals contract. > If two Type instances that are equal according to equals() but have different > logical types were ever put in a hash map, then both of the following cases > are possible: > * The two instances may accidentally have the same hash, which is consistent > with the equals() method but is pure coincidence and has a very low > probablility. > * The two instances may have different hashes and end up in different buckets > of a hash map, leading to a situation where we can't find a value in the hash > map despite that it's equals() would return true. > We should decide -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (PARQUET-1191) Type.hashCode() takes originalType into account but Type.equals() does not
[ https://issues.apache.org/jira/browse/PARQUET-1191?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Zoltan Ivanfi updated PARQUET-1191: --- Description: Taking originalType into account in Type.hashCode() but ignoring it in Type.equals() is inconsistent and violates hashCode-equals contract. If two Type instances that are equal according to equals() but have different logical types were ever put in a hash map, then both of the following cases are possible: * The two instances may accidentally have the same hash, which is consistent with the equals() method but is pure coincidence and has a very low probablility. * The two instances may have different hashes and end up in different buckets of a hash map, leading to a situation where we can't find a value in the hash map despite that it's equals() would return true. was: If two Type instances are equal according to equals() but have different logical types, then both of the following cases are possible: * The two instances may accidentally have the same hash, which is consistent with the equals() method but is pure coincidence and has a very low probablility. * The two instances may have different hashes and end up in different buckets of a hash map, leading to a situation where we can't find a value in the hash map despite that it's equals() would return true. > Type.hashCode() takes originalType into account but Type.equals() does not > -- > > Key: PARQUET-1191 > URL: https://issues.apache.org/jira/browse/PARQUET-1191 > Project: Parquet > Issue Type: Bug >Reporter: Gabor Szadovszky > > Taking originalType into account in Type.hashCode() but ignoring it in > Type.equals() is inconsistent and violates hashCode-equals contract. > If two Type instances that are equal according to equals() but have different > logical types were ever put in a hash map, then both of the following cases > are possible: > * The two instances may accidentally have the same hash, which is consistent > with the equals() method but is pure coincidence and has a very low > probablility. > * The two instances may have different hashes and end up in different buckets > of a hash map, leading to a situation where we can't find a value in the hash > map despite that it's equals() would return true. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (PARQUET-1191) Type.hashCode() takes originalType into account but Type.equals() does not
[ https://issues.apache.org/jira/browse/PARQUET-1191?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Zoltan Ivanfi updated PARQUET-1191: --- Description: If two Type instances are equal according to equals() but have different logical types, then both of the following cases are possible: * The two instances may accidentally have the same hash, which is consistent with the equals() method but is pure coincidence and has a very low probablility. * The two instances may have different hashes and end up in different buckets of a hash map, leading to a situation where we can't find a value in the hash map despite that it's equals() would return true. was: If two Type instances are equal according to equals() but have different logical types, then both of the following cases are possible: * The two instances may accidentally have the same hash, which is consistent with the equals() method but is pure coincidence and has a very low probablility. * The two instances may have different hashes and end up in different buckets of a hash map, leading to a situation where we can't find a value in the hash map despite that it's equals() would return true. > Type.hashCode() takes originalType into account but Type.equals() does not > -- > > Key: PARQUET-1191 > URL: https://issues.apache.org/jira/browse/PARQUET-1191 > Project: Parquet > Issue Type: Bug >Reporter: Gabor Szadovszky > > If two Type instances are equal according to equals() but have different > logical types, then both of the following cases are possible: > * The two instances may accidentally have the same hash, which is consistent > with the equals() method but is pure coincidence and has a very low > probablility. > * The two instances may have different hashes and end up in different buckets > of a hash map, leading to a situation where we can't find a value in the hash > map despite that it's equals() would return true. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (PARQUET-1191) Type.hashCode() takes originalType into account but Type.equals() does not
[ https://issues.apache.org/jira/browse/PARQUET-1191?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Zoltan Ivanfi updated PARQUET-1191: --- Reporter: Gabor Szadovszky (was: Zoltan Ivanfi) > Type.hashCode() takes originalType into account but Type.equals() does not > -- > > Key: PARQUET-1191 > URL: https://issues.apache.org/jira/browse/PARQUET-1191 > Project: Parquet > Issue Type: Bug >Reporter: Gabor Szadovszky > > If two Type instances are equal according to equals() but have different > logical types, then both of the following cases are possible: > * The two instances may accidentally have the same hash, which is consistent > with the equals() method but is pure coincidence and has a very low > probablility. > * The two instances may have different hashes and end up in different buckets > of a hash map, leading to a situation where we can't find a value in the hash > map despite that it's equals() would return true. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
