- changed status to resolved
maintaining float type affinity
continuing from #4017
two issues are 1. the "asdecimal"-ness of an expression being maintained, which goes beyond Float and 2. Float having it's own affinity
from sqlalchemy import Float, Integer, literal
expr = literal(5, Integer) * literal(4.5, Float)
assert expr.type.asdecimal is False
assert expr.type is Float
option are to give Float its own _type_affinity, but then that only works for Float and not Numeric with asdecimal=False type affinity and also that would be the single example of two levels of _type_affinity Numeric/Float so not sure I like that.
I think we should use something other than _type_affinity in _DateAffinity._adapt_expression that can deliver more specificity, and leave _type_affinity alone since this is not as much about Python datatypes.
also why are the logic used for numeric -> numeric type adaptations encapsulated in _DateAffinity, that just looks bad, rename that to something.
Comments (1)
-
reporter - Log in to comment
Return given type when it matches the adaptation
The rules for type coercion between :class:
.Numeric
, :class:.Integer
, and date-related types now include additional logic that will attempt to preserve the settings of the incoming type on the "resolved" type. Currently the target for this is theasdecimal
flag, so that a math operation between :class:.Numeric
or :class:.Float
and :class:.Integer
will preserve the "asdecimal" flag as well as if the type should be the :class:.Float
subclass.Change-Id: Idfaba17220d6db21ca1ca4dcb4c19834cd397817 Fixes:
#4018→ <<cset fae82dda00aa>>