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.
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.Alternatively, Query.toString() could be required to return thesingle-string representation of the query, or some dedicated method wasadded to provide it.
This would make it easier to e.g. implement some custom cache for queryresults, 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:[email protected] P.S. A good JDO? O, Gasp!
smime.p7s
Description: S/MIME cryptographic signature
