cayenne-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Andrus Adamchik (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (CAY-1987) Widen types before performing in-memory evaluation of qualifiers using j.l.Number subclasses
Date Tue, 10 Feb 2015 06:25:35 GMT

    [ https://issues.apache.org/jira/browse/CAY-1987?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14313667#comment-14313667
] 

Andrus Adamchik commented on CAY-1987:
--------------------------------------

Yeah, this has been a problem that we had to deal with in various parts of Cayenne. E.g. see
ObjectId.valueEquals(..) [1] where we'd widen to "long" (based on an assumption that there
are no fractions in numeric IDs). Certainly lets fix it for qualifiers (including support
for real numbers). Just need to make sure we cover it with unit tests, e.g. to ensure that
we correctly compare doubles with ints, etc.

[1] https://github.com/apache/cayenne/blob/master/cayenne-server/src/main/java/org/apache/cayenne/ObjectId.java

> Widen types before performing in-memory evaluation of qualifiers using j.l.Number subclasses
> --------------------------------------------------------------------------------------------
>
>                 Key: CAY-1987
>                 URL: https://issues.apache.org/jira/browse/CAY-1987
>             Project: Cayenne
>          Issue Type: Improvement
>          Components: Core Library
>    Affects Versions: 4.0.M2
>         Environment: trunk
>            Reporter: John Huss
>            Priority: Minor
>
> There is a difference in the behavior of Expressions evaluated in memory versus by the
database when comparing attributes with a type like java.lang.Short with a literal of type
java.lang.Integer.  In memory Short(1) != Integer(1), but they are equal in the database.
 Using a less strict comparison in memory would be preferable. 
> I figured there would be an open source implementation of this somewhere that calculates
the widest type and compares the two values, but I couldn't find one.  I imagine you could
just call number.doubleValue() and compare that, but that seems sketchy.  
> If you think this is worth doing I could try writing an implementation.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Mime
View raw message