You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lucene.apache.org by Shai Erera <se...@gmail.com> on 2010/04/28 14:21:51 UTC
IndexCommit violates the contract of hashCode and equals?
Hi
According to Java's hashCode jdoc, if two objects answer true to
o1.equals(o2), then o1.hashCode() == o2.hashCode(). However, IC uses Dir +
segmentFileName in hashCode() and Dir + version in equals(). More so, the
jdoc of equals specifies that two IC equals if their Dirs are equals and the
have the same version.
I think this should be fixed?
But what is the right criteria: Dir + version || Dir + segFileName || Dir +
version + segFileName?
Shai
Re: IndexCommit violates the contract of hashCode and equals?
Posted by Shai Erera <se...@gmail.com>.
ok, since both of you say Dir + version, I'll go with your proposal :).
I can make all its methods abstract - have a hard time believing IndexCommit
is extended outside Lucene. Also, if someone extended it and didn't override
one of these methods, UOE would have hit him already?
Shai
On Wed, Apr 28, 2010 at 3:40 PM, Michael McCandless <
lucene@mikemccandless.com> wrote:
> Good catch! We should make both hashCode & equals consistent.
>
> I think Dir + version is best?
>
> In theory Dir + segFileName should be equally good, since segFileName
> <-> version is one-to-one/onto, but I think conceptually version is
> the better "identifier" of change.
>
> We really should make getVersion abstract w/ 3.0 -- all core ICs impl it.
>
> Mike
>
> On Wed, Apr 28, 2010 at 8:21 AM, Shai Erera <se...@gmail.com> wrote:
> > Hi
> >
> > According to Java's hashCode jdoc, if two objects answer true to
> > o1.equals(o2), then o1.hashCode() == o2.hashCode(). However, IC uses Dir
> +
> > segmentFileName in hashCode() and Dir + version in equals(). More so, the
> > jdoc of equals specifies that two IC equals if their Dirs are equals and
> the
> > have the same version.
> >
> > I think this should be fixed?
> >
> > But what is the right criteria: Dir + version || Dir + segFileName ||
> Dir +
> > version + segFileName?
> >
> > Shai
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: dev-help@lucene.apache.org
>
>
Re: IndexCommit violates the contract of hashCode and equals?
Posted by Michael McCandless <lu...@mikemccandless.com>.
Good catch! We should make both hashCode & equals consistent.
I think Dir + version is best?
In theory Dir + segFileName should be equally good, since segFileName
<-> version is one-to-one/onto, but I think conceptually version is
the better "identifier" of change.
We really should make getVersion abstract w/ 3.0 -- all core ICs impl it.
Mike
On Wed, Apr 28, 2010 at 8:21 AM, Shai Erera <se...@gmail.com> wrote:
> Hi
>
> According to Java's hashCode jdoc, if two objects answer true to
> o1.equals(o2), then o1.hashCode() == o2.hashCode(). However, IC uses Dir +
> segmentFileName in hashCode() and Dir + version in equals(). More so, the
> jdoc of equals specifies that two IC equals if their Dirs are equals and the
> have the same version.
>
> I think this should be fixed?
>
> But what is the right criteria: Dir + version || Dir + segFileName || Dir +
> version + segFileName?
>
> Shai
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: IndexCommit violates the contract of hashCode and equals?
Posted by Shai Erera <se...@gmail.com>.
ok so you mean make sure both hashCode and equals work on Dir + version?
I think segFileName is better too, at least it makes it more clear. But I
assumed version is used for a reason in equals() and there's a specific jdoc
about it ...
But if Dir + segFileName is safe (seems like it), I think we should make
both of them use it?
Shai
On Wed, Apr 28, 2010 at 3:34 PM, Mark Miller <ma...@gmail.com> wrote:
> On 4/28/10 8:21 AM, Shai Erera wrote:
>
>> Hi
>>
>> According to Java's hashCode jdoc, if two objects answer true to
>> o1.equals(o2), then o1.hashCode() == o2.hashCode(). However, IC uses Dir
>> + segmentFileName in hashCode() and Dir + version in equals(). More so,
>> the jdoc of equals specifies that two IC equals if their Dirs are equals
>> and the have the same version.
>>
>> I think this should be fixed?
>>
>> But what is the right criteria: Dir + version || Dir + segFileName ||
>> Dir + version + segFileName?
>>
>> Shai
>>
>
>
> Looks like Dir + version is enough? But perhaps Dir + segFileName is better
> - its odd to rely on getVersion for this in the abstract base class - it can
> throw UnsupportedOperationException unless a subclass chooses to implement
> it.
>
> --
> - Mark
>
> http://www.lucidimagination.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: dev-help@lucene.apache.org
>
>
Re: IndexCommit violates the contract of hashCode and equals?
Posted by Mark Miller <ma...@gmail.com>.
On 4/28/10 8:21 AM, Shai Erera wrote:
> Hi
>
> According to Java's hashCode jdoc, if two objects answer true to
> o1.equals(o2), then o1.hashCode() == o2.hashCode(). However, IC uses Dir
> + segmentFileName in hashCode() and Dir + version in equals(). More so,
> the jdoc of equals specifies that two IC equals if their Dirs are equals
> and the have the same version.
>
> I think this should be fixed?
>
> But what is the right criteria: Dir + version || Dir + segFileName ||
> Dir + version + segFileName?
>
> Shai
Looks like Dir + version is enough? But perhaps Dir + segFileName is
better - its odd to rely on getVersion for this in the abstract base
class - it can throw UnsupportedOperationException unless a subclass
chooses to implement it.
--
- Mark
http://www.lucidimagination.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org