Re: [jira] Updated: (LUCENE-2945) Surround Query doesn't properly handle equals/hashcode

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: [jira] Updated: (LUCENE-2945) Surround Query doesn't properly handle equals/hashcode

Paul Elschot
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.

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.

Regards,
Paul Elschot



---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [jira] Updated: (LUCENE-2945) Surround Query doesn't properly handle equals/hashcode

Grant Ingersoll-2

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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [jira] Updated: (LUCENE-2945) Surround Query doesn't properly handle equals/hashcode

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

>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.

Iirc the one with the inner class is a (Lucene) Query, so why compare
it to a (Surround) DistanceQuery from which it may have been generated?
Never mind, I don't have the source code here...

Regards,
Paul Elschot



---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]






---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [jira] Updated: (LUCENE-2945) Surround Query doesn't properly handle equals/hashcode

Grant Ingersoll-2

On Mar 5, 2011, at 3:25 PM, Paul Elschot wrote:

> On Mar 5, 2011, at 9:40 AM, Paul Elschot wrote:
>
>> 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.
>
> Iirc the one with the inner class is a (Lucene) Query, so why compare
> it to a (Surround) DistanceQuery from which it may have been generated?

I wasn't, that's what your patch did ;-)

It's the Lucene Query that matters.  I'm just not sure what the best way to generate the equals/hash from.

> Never mind, I don't have the source code here...



---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]