yes I’ve just figured this out on this end - your column is not a Float, it is a Numeric (more specifically a DECIMAL, but Numeric is good enough).
The column types that you place in Column have to match the *actual* datatype
on the server - this is how SQLAlchemy knows what kind of data to expect.
Otherwise, SQLAlchemy tries to save on performance by not unnecessarily
converting data that should already be in the right format.
To receive your numeric fields as floating point, you should be using the
Numeric datatype, not Float, and use “asdecimal=False”.
I’m still going to see if there’s an easy way to make this a little more
resilient to mis-configuration, but that’s the fix for now. Here’s a demo:
from sqlalchemy import *
e = create_engine("mssql://scott:tiger@ms_2005", echo='debug')
conn = e.connect()
trans = conn.begin()
t = Table('t', MetaData(), Column('data', Numeric(10, 5)))
t.create(conn)
conn.execute(t.insert().values(data="45.17"))
t2 = Table('t', MetaData(), Column('data', Float()))
print(conn.execute(t2.select()).fetchall())
t3 = Table('t', MetaData(), Column('data', Numeric(asdecimal=False)))
print(conn.execute(t3.select()).fetchall())
On Jan 21, 2014, at 12:21 PM, 曹忠 <joo.t...@gmail.com> wrote:
> coefficient define on server:
>
> FCoefficient decimal(20, 10) NOT NULL DEFAULT (1),
>
> Float type has parameter asdecimal=False, 0.9 user no choice? I hope not
>
> 在 2014年1月21日星期二UTC+8下午10时59分07秒，Michael Bayer写道：
>
> On Jan 21, 2014, at 4:31 AM, 曹忠 <joo....@gmail.com> wrote:
>
> > test env: sql server 2005 and pyodbc 3.0.7 and freetds 0.91, on debian 8.0
> > product env: sql server 2005 and pyodbc 3.0.7 and native client 10.0, on
> > windows 2003
> > above two env is the same behavior with 0.9.1, always return decimal
> > object for float type
> >
> > follow is part data model:
> >
> > from sqlalchemy.ext.declarative import declarative_base
> > from sqlalchemy.schema import Column,
> > from sqlalchemy.types import SmallInteger, Integer, Float
> > from sqlalchemy.types import String
> >
> > Base = declarative_base()
> >
> > class Unit(Base):
> > __tablename__ = 't_MeasureUnit'
> >
> > id = Column('FMeasureUnitID', Integer, autoincrement=False,
> > primary_key=True)
> > name = Column('FName', String(80), nullable=False)
> > number = Column('FNumber', String(30), nullable=False)
> > short_number = Column('FShortNumber', String(30))
> > conversation = Column('FConversation', Integer, server_default='(1)')
> > coefficient = Column('FCoefficient', Float, nullable=False,
> > server_default='(1)')
> > deleted = Column('FDeleted', SmallInteger, nullable=False,
> > server_default='(0)')
> >
> > with 0.8.4, conversation column return python float object, upgrade to 0.9
> > or 0.9.1 all Float column always return decimal object.
> > my project and the data model has been running for over two years, pass two
> > year with 0.7 and 0.8 no problem. my project not need to use decimal, float
> > precision is sufficient.
>
> uh, but “conversation” above is an Integer. What is the actual datatype on
> SQL Server? Are you sure you’re not referring to “coefficient” ?
>
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "sqlalchemy" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email tosqlalchemy+unsubscr...@googlegroups.com.
> To post to this group, send email to sqlalchemy@googlegroups.com.
> Visit this group at http://groups.google.com/group/sqlalchemy.
> For more options, visit https://groups.google.com/groups/opt_out.
signature.asc
Description: Message signed with OpenPGP using GPGMail
