---------- Forwarded message ----------
From: Rick Morrison < [EMAIL PROTECTED]>
Date: Jun 6, 2006 4:54 AM
Subject: Re: [Sqlalchemy-users] decimal type support in sqlalchemy
To: "William K. Volkman" <[EMAIL PROTECTED] >
Cc: Michael Bayer <[EMAIL PROTECTED]>, sqlalchemy-users@lists.sourceforge.net, Yuan HOng < [EMAIL PROTECTED]>
Just a few clarifying points on this:
I don't see what overhead isn't being already spent -- the data type conversion has to take place anyway, especially for type-agnostic engines like SQlite. For type-rich databases like PG, if the DBAPI type is already correct, then no conversion is needed or performed. This thing is simply a repository that holds a map of the *desired* types that the existing conversion code can consult to have an idea of what it should return. That's already done, only it's being done by convention instead of explicitly.
The "best" return type is the exact issue at hand. What the MySQL DBAPI module thinks of as "best" for a numeric field may be different than that of PG. That makes it impossible to write programs that behave correctly when used with various databases, which is one of the reasons for the existence of SA in the first place.
and some responses:
Right, that's a different issue though, one more for the DBAPI modules themselves. They will be no doubt be updated over time with Decimal support, and SA should be ready to handle the change without breaking programs. This is the mechanism needed to do that.
Then the user-defined type should be put in place in the TypePolicy map for that application -- it's just another type, and would be supported in the exact same way.
This doesn't take that away, individual columns can still be overridden, and individual types can still be overridden. This just provides a framework for standard behavior where overrides are not given. In fact, it gives a single place to override for all databases, instead of having to override every database engine.
I believe that SA should support both use-cases that we're talking about here: 1) the user using one database with heavy custom type support and the 2) a user using only standard data types, but lots of different databases and wants more-or-less standard behavior among them. I don't see anything in this mechanism that hurt case #1, and it's rather vital for case #2.
Rick
I don't see what overhead isn't being already spent -- the data type conversion has to take place anyway, especially for type-agnostic engines like SQlite. For type-rich databases like PG, if the DBAPI type is already correct, then no conversion is needed or performed. This thing is simply a repository that holds a map of the *desired* types that the existing conversion code can consult to have an idea of what it should return. That's already done, only it's being done by convention instead of explicitly.
The "best" return type is the exact issue at hand. What the MySQL DBAPI module thinks of as "best" for a numeric field may be different than that of PG. That makes it impossible to write programs that behave correctly when used with various databases, which is one of the reasons for the existence of SA in the first place.
and some responses:
The problem of course it that float is
a "lossy" type, sometime try round tripping 0.1 through a Decimal
data type (the _expression_ "dbvalue == 0.1" returns False).
Right, that's a different issue though, one more for the DBAPI modules themselves. They will be no doubt be updated over time with Decimal support, and SA should be ready to handle the change without breaking programs. This is the mechanism needed to do that.
Consider the fact that psycopg2 implements user defined data
types. Now how should a "TypePolicy" react to that?
Then the user-defined type should be put in place in the TypePolicy map for that application -- it's just another type, and would be supported in the exact same way.
is that if someone has specialized needs for data type mapping
let them override to get the expected behavior. Please keep it
out of the common code.
This doesn't take that away, individual columns can still be overridden, and individual types can still be overridden. This just provides a framework for standard behavior where overrides are not given. In fact, it gives a single place to override for all databases, instead of having to override every database engine.
I believe that SA should support both use-cases that we're talking about here: 1) the user using one database with heavy custom type support and the 2) a user using only standard data types, but lots of different databases and wants more-or-less standard behavior among them. I don't see anything in this mechanism that hurt case #1, and it's rather vital for case #2.
Rick
_______________________________________________ Sqlalchemy-users mailing list Sqlalchemy-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sqlalchemy-users
