lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Grant Ingersoll <gsing...@apache.org>
Subject Re: [jira] Updated: (LUCENE-2945) Surround Query doesn't properly handle equals/hashcode
Date Sat, 05 Mar 2011 18:42:50 GMT

On Mar 5, 2011, at 9:40 AM, Paul Elschot wrote:

> Grant,
> 
> I'm having a file system and/or hardware problem here, so I can only
> comment by mail at the moment.
> 
> The toString() implementations in (subclasses of) SrndQuery are supposed
> to provide a mostly reparsable string, so it should be possible to use
> that instead of passing in the original syntax string as in your patch.
> I would run the existing tests with an extra println at a strategic point
> to compare the parsed input to the toString() result, but I cannot do that
> now...
> 
> About the existing toString() implementations in the inner classes: as I
> understand java's "qualified this" these should not need to be redirected
> to the enclosing object for this issue. These existing toString()s were
> only used for development, so I expect no problem in reimplementing them
> in case this turns out to be necessary.

Right, I used the outer one, although I suspect it isn't correct yet, so will keep working
on it.  It's probably safest to look at the underlying structures that are used to create
the query.


> 
> Class objects should be unique, so I would expect the hashCode() and
> equals() in my patch to work with them, but I could not yet find a
> definite conclusion on inner classes in the java documentation. It could
> be that the explicit "inner" classes in your patch work around that.

What happens is that you actually end up comparing two different objects, one which is the
DistanceQuery and one which is the inner class, so it doesn't work.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org


Mime
View raw message