db-jdo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joerg von Frantzius <joerg.von.frantz...@artnology.com>
Subject Re: Query objects and hashCode() + equals()
Date Mon, 16 Nov 2009 16:32:49 GMT
Hi Craig,

you are absolutely right about the Query object being mutable, and this
conflicting with its use as a key in a HashMap. But telling from the
general contracts of Map, equals() and hashCode(), I don't think that
there exists a requirement for Map keys to be immutable. There may also
be other purposes for comparing Query objects using equals(), or Map
implementations that don't require immutability of keys.

I wouldn't ask if datanucleus wasn't already there halfway: datanucleus'
JDO query object delegates to org.datanucleus.store.query.Query, which
already correctly implements equals(), hashCode() and toString(). The
only thing missing is the wrapper query object to also delegate these
methods (I guess that was simply forgotten when that additional layer
was introduced with JPOX implementing JPA).

Just a small thing, I hope I'll find the time to fix it in datanucleus
myself. When that has happened, it could still be worth putting in the spec?

Regards,
Jörg

On 10/23/2009 06:57 PM, Craig L Russell wrote:
> Hi Jörg,
>
> On Oct 16, 2009, at 9:50 AM, Joerg von Frantzius wrote:
>
>> Hi,
>>
>> it would be nice if the spec would mandate that implementations of
>> javax.jdo.Query do correctly implement hashCode() and equals().
>
> As users execute mutator methods on queries, the string representation
> would change. And for proper use in sets or map keys, hashCode and
> equals should be  immutable after construction. So I don't see how we
> can mandate that hashCode and equals rely in any internal state.
>
>> Alternatively, Query.toString() could be required to return the
>> single-string representation of the query, or some dedicated method was
>> added to provide it.
>>
> Having the single-string version of a query is useful but adds
> implementation complexity. While there is a requirement for an
> implementation to parse a single string query into executable form,
> there's no current requirement to create the single string form from
> the internal form.
>
>> This would make it easier to e.g. implement some custom cache for query
>> results, or, more generally, it would make it easier to put Query
>> objects as keys into Maps.
>
> It seems to me that if you want this functionality at the application
> framework layer, then the framework can mandate that the single string
> form be used and at the time the query is created, the single string
> form be used as the key into a framework map.
>
> Regards,
>
> Craig
>> ____________________________________________________________________
>> artnology GmbH - Milastraße 4 - 10437 Berlin - Germany
>> Geschäftsführer: Ekkehard Blome (CEO), Felix Kuschnick (CCO)
>> Registergericht: Amtsgericht Berlin Charlottenburg HRB 76376
>> UST-Id. DE 217652550
>>
>
> Craig L Russell
> Architect, Sun Java Enterprise System http://db.apache.org/jdo
> 408 276-5638 mailto:Craig.Russell@sun.com
> P.S. A good JDO? O, Gasp!
>


-- 
____________________________________________________________________
artnology GmbH - Milastraße 4 - 10437 Berlin - Germany
Geschäftsführer: Ekkehard Blome (CEO), Felix Kuschnick (CCO)
Registergericht: Amtsgericht Berlin Charlottenburg HRB 76376 
UST-Id. DE 217652550


Mime
  • Unnamed multipart/mixed (inline, None, 0 bytes)
View raw message