Re: [Sqlalchemy-users] decimal type support in sqlalchemy
I was thinking about a global TypePolicy, but this is better: it
certainly makes sense to be able to have multiple engine/Dialects, each
with a potentially different policy installed.
I would think that a TypePolicy object would be one of the possible
options you give to Dialect/create_engine(), and have it use a
system-wide default if not given. That way it's possible to roll up the
obvious type-oriented options like the Numeric and Unicode options into
TypePolicy, and to still defer the issue of what to do (if anything)
with other non-type options like [echo, strategy, pool, etc.] until
it's been given more thought.
Rick
On 6/5/06, Michael Bayer [EMAIL PROTECTED] wrote:
so. does that just mean instead of sending a
dictionary to Dialect/create_engine(), we send a TypePolicy object
?(fyi the list is crapped out again, SF typically gets it going again in a day or so)On Jun 5, 2006, at 9:55 AM, Rick Morrison wrote:
Right,
this would be a global type policy object that the Dialects would
consult to determine the appropriate conversion to make. Right now
that's done by convention, this would make things more explicit and
allow global overrides of type conversion policy. It makes
sense to leave the actual conversion to the Dialects themselves,
because there may be some db-specific hacks needed, or it may be
possible for some DBAPI modules to be programmed to automatically
convert according to the policy (I think that's possible for psycopg's
adaption, for instance). Maybe the policy object could expose a library
of standard conversion routines to keep things more or less
standardized between the Dialects. As to would go in the
Dialect and what would go in the global Policy object, I guess that's
going to determined. I would suggest a good rule of thumb is to keep
the really DB-specific stuff in the Dialect, and reserve the global
object for these across the board type of things. Rick
Right, I would say the data conversion itself should stay in the
Dialect, what the Dialects need is a way to consult a global object
containing a map of theOn 6/4/06, Michael Bayer
[EMAIL PROTECTED] wrote: you can override types at the column level, even if you use reflection:
table = Table('sometable', meta, Column('somecolumn', MyType), autoload = True)
which will reflect every column except somecolumn. so we have that right now. I
usually see the Dialect as the thing between the python and database
worlds. its where you determine the exact language youre going
to speak with the database, and it has options on its behavior.
and for this typing thing, i think we need a way to specify behaviors
across the board in addition to per-column, since otherwise people
have to have expicit types all over the place and it dilutes the
usefulness of reflection.in reality,
type-based decisions are always ultimately at the metadata level
since its determined by TypeEngine objects attached to Column
objects. but they just need some place to get global information
about what desired behavior they should have.that
global info could be in an actual MetaData object but then how do we
decide what options go at the MetaData level and which ones go in the
Dialect (i.e. create_engine) ? users would have to know
which options go where, which might seem kind of arbitrary. also
i would worry MetaData is just going to become another Engine again and
have database behavior undesrieably bound to a schema description.On Jun 3, 2006, at 11:15 PM, Rick Morrison wrote: I'm feeling it more on the MetaData level.
You're looking at two interfaces that any SA user is going to be concerned with:the
first is at the database level...those types will be necessarily fixed,
by either an existing schema or by the type support or restrictions of
the database itself. the second is at the resultset / mapped
object level. This is where the user is going to want some control over
data type, to fit into their idea of how to work with the data.What's
between these two worlds is the MetaData. Right now, the conversion is
implicit and controlled by the DB engine (or maybe more exactly, by the
DBAPI interface). But during that conversion, the metadata for that
column is available, right? If instead of the implicit conversion, what
if there were some sort of pluggable / adaption mechanism that used
reasonable defaults, but allowed some sort of override mechanism? This way, whether you fetched a row from PG, or Sqlite, or whatever, you know that you could morph it into what you need.Rick
On 6/3/06, Michael Bayer [EMAIL PROTECTED]
wrote: right unless they do the override column type thing. which is inconvenient if they want Decimal all over the place.
im
thinking that with this, along with the various unicode requests we've
had, that some real engine/dialect level this is the official map of
types I'd like you to use type of thing needs to be created, which is
more generic than having flags like convert_unicode and such.
but then it would also have to be easy. not
Re: [Sqlalchemy-users] decimal type support in sqlalchemy
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:The problem of course it that float is a lossy type, sometime try round tripping 0.1 through a Decimaldata 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 datatypes.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 mappinglet them override to get the expected behavior.Please keep itout 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
Re: [Sqlalchemy-users] decimal type support in sqlalchemy
On Jun 6, 2006, at 12:21 AM, William K. Volkman wrote: Consider the fact that psycopg2 implements user defined data types. Now how should a TypePolicy react to that? Bottom line 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. um, perhaps youre misunderstanding, we are only talking about being able to write database-agnostic code that expects a float to receive a float, not a Decimal, in all cases regardless of database being used. Secondly, we are suggesting a method by which a user can specify that he or she would like particular types to be used when reflecting tables, rather than the default selection. Essentially, the ability to customize this map: http://www.sqlalchemy.org/trac/browser/sqlalchemy/trunk/lib/ sqlalchemy/databases/postgres.py#L122 so...you are free to choose to not override the mapping at all. to interact with user defined types correctly would probably require a correspoinding custom TypeEngine class on the SA side of things to be created in any case. in fact, to reflect postgres tables which do define custom datatypes, the custom type map feature would be *required* since some method would be needed to tell the postgres module about your custom type and what TypeEngine object should be used to deal with it on the python side. ___ Sqlalchemy-users mailing list Sqlalchemy-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sqlalchemy-users
Re: [Sqlalchemy-users] decimal type support in sqlalchemy
oh, now i just understood your email. I would say this should be added to the wiki: http://www.sqlalchemy.org/trac/wiki/DatabaseNotes which i have just done! psycopg1 is no longer supported...this float issue is just one of many. On Jun 3, 2006, at 3:42 AM, Yuan HOng wrote: Thanks for pointing this out. I found out that psycopg 1.1.21 gives back a Numeric as float. When I switched to psycopg2, a Decimal object is automatically returned. I was switching from SQLObjects, and there the Numeric is automatically converted to Decimal seemingly by SQLObjects, so I took that for granted. Maybe this should also be added to SA, since then the application won't be dependant on the return type of the DBAPI layer? On 6/3/06, Michael Bayer [EMAIL PROTECTED] wrote: the float type coming from Numeric etc. is straight from the DBAPI, in this case psycopg2. If youd like to make your own Decimal type which translates this value back and forth from whatever float value psycopg2 is giving you, simply subclass TypeDecorator, specify Numeric as the 'impl', and implement the appropriate convert_bind_param(), convert_result_value() methods. instructions are here: http://www.sqlalchemy.org/docs/types.myt#types_custom if you get that done, theres no reason it cant be stuck into the types module, just wouldnt be available if youre on 2.3. -- Hong Yuan 大管家网上建材超市 装修装潢建材一站式购物 http://www.homemaster.cn ___ Sqlalchemy-users mailing list Sqlalchemy-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sqlalchemy-users ___ Sqlalchemy-users mailing list Sqlalchemy-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sqlalchemy-users
Re: [Sqlalchemy-users] decimal type support in sqlalchemy
i had forgotten to modify the main docs that psycopg1 is not supported, just did that. On Jun 3, 2006, at 3:42 AM, Yuan HOng wrote: Thanks for pointing this out. I found out that psycopg 1.1.21 gives back a Numeric as float. When I switched to psycopg2, a Decimal object is automatically returned. I was switching from SQLObjects, and there the Numeric is automatically converted to Decimal seemingly by SQLObjects, so I took that for granted. Maybe this should also be added to SA, since then the application won't be dependant on the return type of the DBAPI layer? On 6/3/06, Michael Bayer [EMAIL PROTECTED] wrote: the float type coming from Numeric etc. is straight from the DBAPI, in this case psycopg2. If youd like to make your own Decimal type which translates this value back and forth from whatever float value psycopg2 is giving you, simply subclass TypeDecorator, specify Numeric as the 'impl', and implement the appropriate convert_bind_param(), convert_result_value() methods. instructions are here: http://www.sqlalchemy.org/docs/types.myt#types_custom if you get that done, theres no reason it cant be stuck into the types module, just wouldnt be available if youre on 2.3. -- Hong Yuan 大管家网上建材超市 装修装潢建材一站式购物 http://www.homemaster.cn ___ Sqlalchemy-users mailing list Sqlalchemy-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sqlalchemy-users ___ Sqlalchemy-users mailing list Sqlalchemy-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sqlalchemy-users
Re: [Sqlalchemy-users] decimal type support in sqlalchemy
On 6/3/06, Michael Bayer [EMAIL PROTECTED] wrote: The Numeric types in SQLAlchemy dont modify the incoming or outgoingreturn type of bind parameters at all. Maybe they should. Letting the DBAPI driver do what it wants for type conversion breaks the database independence that SA purports to provide, no? Rick ___ Sqlalchemy-users mailing list Sqlalchemy-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sqlalchemy-users
Re: [Sqlalchemy-users] decimal type support in sqlalchemy
yes, looking at psycopg2's source code i can see that its checking
for python 2.4 and then using Decimal:
if sys.version_info[0] = 2 and sys.version_info[1] = 4:
define_macros.append(('HAVE_DECIMAL','1'))
#ifdef HAVE_DECIMAL
PyObject *decimal = PyImport_ImportModule(decimal);
if (decimal) {
decimalType = PyObject_GetAttrString(decimal, Decimal);
}
#endif
So, I did a test locally with PG and confirmed that you do in fact
get a Decimal back when using Py2.4:
db = create_engine('postgres://scott:[EMAIL PROTECTED]/test?echo=True')
table = Table('sometable', db,
Column('col1', Numeric))
db.create(table)
db.execute(table.insert(), dict(col1=2.5))
x = db.connect().scalar(table.select())
print type(x)
print x
class 'decimal.Decimal'
2.50
The Numeric types in SQLAlchemy dont modify the incoming or outgoing
return type of bind parameters at all. this disagrees with your
initial assertion that you get a float type backso...do you
have a test case ? is it possible you are assigning a float to a
mapped object and then just getting back that same float without any
DB round trip going on ?
On Jun 3, 2006, at 3:42 AM, Yuan HOng wrote:
Thanks for pointing this out. I found out that psycopg 1.1.21 gives
back a Numeric as float. When I switched to psycopg2, a Decimal object
is automatically returned.
I was switching from SQLObjects, and there the Numeric is
automatically converted to Decimal seemingly by SQLObjects, so I took
that for granted. Maybe this should also be added to SA, since then
the application won't be dependant on the return type of the DBAPI
layer?
On 6/3/06, Michael Bayer [EMAIL PROTECTED] wrote:
the float type coming from Numeric etc. is straight from the DBAPI,
in this case psycopg2. If youd like to make your own Decimal type
which translates this value back and forth from whatever float value
psycopg2 is giving you, simply subclass TypeDecorator, specify
Numeric as the 'impl', and implement the appropriate
convert_bind_param(), convert_result_value() methods.
instructions are here:
http://www.sqlalchemy.org/docs/types.myt#types_custom
if you get that done, theres no reason it cant be stuck into the
types module, just wouldnt be available if youre on 2.3.
--
Hong Yuan
大管家网上建材超市
装修装潢建材一站式购物
http://www.homemaster.cn
___
Sqlalchemy-users mailing list
Sqlalchemy-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sqlalchemy-users
Re: [Sqlalchemy-users] decimal type support in sqlalchemy
Right, this would be a global type policy object that the Dialects
would consult to determine the appropriate conversion to make. Right
now that's done by convention, this would make things more explicit and
allow global overrides of type conversion policy.
It makes sense to leave the actual conversion to the Dialects
themselves, because there may be some db-specific hacks needed, or it
may be possible for some DBAPI modules to be programmed to
automatically convert according to the policy (I think that's possible
for psycopg's adaption, for instance). Maybe the policy object could
expose a library of standard conversion routines to keep things more or
less standardized between the Dialects.
As to would go in the Dialect and what would go in the global Policy
object, I guess that's going to determined. I would suggest a good rule
of thumb is to keep the really DB-specific stuff in the Dialect, and
reserve the global object for these across the board type of things.
Rick
Right, I would say the data conversion itself should stay in the
Dialect, what the Dialects need is a way to consult a global object
containing a map of theOn 6/4/06, Michael Bayer [EMAIL PROTECTED] wrote:
you can override types at the column level, even if you use reflection:table = Table('sometable', meta, Column('somecolumn', MyType),
autoload = True)which will reflect every column except somecolumn. so we have that right now.
I
usually see the Dialect as the thing between the python and database
worlds. its where you determine the exact language youre going
to speak with the database, and it has options on its behavior.
and for this typing thing, i think we need a way to specify behaviors
across the board in addition to per-column, since otherwise people
have to have expicit types all over the place and it dilutes the
usefulness of reflection.in reality,
type-based decisions are always ultimately at the metadata level
since its determined by TypeEngine objects attached to Column
objects. but they just need some place to get global information
about what desired behavior they should have.that
global info could be in an actual MetaData object but then how do we
decide what options go at the MetaData level and which ones go in the
Dialect (i.e. create_engine) ? users would have to know
which options go where, which might seem kind of arbitrary. also
i would worry MetaData is just going to become another Engine again and
have database behavior undesrieably bound to a schema description.On Jun 3, 2006, at 11:15 PM, Rick Morrison wrote:
I'm feeling it more on the MetaData level. You're looking at two interfaces that any SA user is going to be concerned with:the
first is at the database level...those types will be necessarily fixed,
by either an existing schema or by the type support or restrictions of
the database itself. the second is at the resultset / mapped
object level. This is where the user is going to want some control over
data type, to fit into their idea of how to work with the data.What's
between these two worlds is the MetaData. Right now, the conversion is
implicit and controlled by the DB engine (or maybe more exactly, by the
DBAPI interface). But during that conversion, the metadata for that
column is available, right? If instead of the implicit conversion, what
if there were some sort of pluggable / adaption mechanism that used
reasonable defaults, but allowed some sort of override mechanism? This way, whether you fetched a row from PG, or Sqlite, or whatever, you know that you could morph it into what you need.Rick
On 6/3/06, Michael Bayer [EMAIL PROTECTED]
wrote: right unless they do the override column type thing. which is inconvenient if they want Decimal all over the place.
im
thinking that with this, along with the various unicode requests we've
had, that some real engine/dialect level this is the official map of
types I'd like you to use type of thing needs to be created, which is
more generic than having flags like convert_unicode and such.
but then it would also have to be easy. not sure. heres
some ideas: explicit keywords: x = create_engine(url, string_type=Unicode, numeric_type=Decimal)translate python types to SQL types (i think this is problematic):
x = create_engine(url, types = {str : Unicode, float : Decimal})translate generic SA types to more specific SA types:
x = create_engine(url, types = {String:Unicode, Numeric:Decimal})
just
list out the more specific types, which know how to replace their
more generic types, i sort of like this one but not sure if it works: x = create_engine(url, use_types = [Unicode, Decimal])
On Jun 3, 2006, at 4:55 PM, Rick Morrison wrote: Or maybe a different column type so that user can control what comes back. Course that wouldn't work with table reflection
Rick On 6/3/06, Michael Bayer
[EMAIL PROTECTED] wrote: for
this one, i would think float would be the default. then
what do we do for people who specifically want a Decimal ? sounds
like another
Re: [Sqlalchemy-users] decimal type support in sqlalchemy
you can override types at the column level, even if you use reflection:table = Table('sometable', meta, Column('somecolumn', MyType), autoload = True)which will reflect every column except "somecolumn". so we have that right now.I usually see the Dialect as the "thing between the python and database worlds". its where you determine the exact "language" youre going to speak with the database, and it has options on its behavior. and for this typing thing, i think we need a way to specify behaviors "across the board" in addition to per-column, since otherwise people have to have expicit types all over the place and it dilutes the usefulness of reflection.in reality, type-based decisions are always ultimately at the "metadata" level since its determined by TypeEngine objects attached to Column objects. but they just need some place to get global information about what desired behavior they should have.that global info could be in an actual MetaData object but then how do we decide what options go at the MetaData level and which ones go in the Dialect (i.e. create_engine) ? users would have to know which options go where, which might seem kind of arbitrary. also i would worry MetaData is just going to become another Engine again and have database behavior undesrieably bound to a schema description.On Jun 3, 2006, at 11:15 PM, Rick Morrison wrote:I'm feeling it more on the MetaData level. You're looking at two interfaces that any SA user is going to be concerned with:the first is at the database level...those types will be necessarily fixed, by either an existing schema or by the type support or restrictions of the database itself. the second is at the resultset / mapped object level. This is where the user is going to want some control over data type, to fit into their idea of how to work with the data.What's between these two worlds is the MetaData. Right now, the conversion is implicit and controlled by the DB engine (or maybe more exactly, by the DBAPI interface). But during that conversion, the metadata for that column is available, right? If instead of the implicit conversion, what if there were some sort of pluggable / adaption mechanism that used reasonable defaults, but allowed some sort of override mechanism? This way, whether you fetched a row from PG, or Sqlite, or whatever, you know that you could morph it into what you need.RickOn 6/3/06, Michael Bayer [EMAIL PROTECTED] wrote: right unless they do the "override column type" thing. which is inconvenient if they want Decimal all over the place.im thinking that with this, along with the various unicode requests we've had, that some real engine/dialect level "this is the official map of types I'd like you to use" type of thing needs to be created, which is more generic than having flags like "convert_unicode" and such. but then it would also have to be easy. not sure. heres some ideas: explicit keywords: x = create_engine(url, string_type=Unicode, numeric_type=Decimal)translate python types to SQL types (i think this is problematic): x = create_engine(url, types = {str : Unicode, float : Decimal})translate generic SA types to more specific SA types: x = create_engine(url, types = {String:Unicode, Numeric:Decimal}) just list out the more specific types, which "know" how to replace their more generic types, i sort of like this one but not sure if it works: x = create_engine(url, use_types = [Unicode, Decimal])On Jun 3, 2006, at 4:55 PM, Rick Morrison wrote: Or maybe a different column type so that user can control what comes back. Course that wouldn't work with table reflection Rick On 6/3/06, Michael Bayer [EMAIL PROTECTED] wrote: for this one, i would think "float" would be the default. then what do we do for people who specifically want a Decimal ? sounds like another flag-like situation like "convert_unicode". On Jun 3, 2006, at 2:16 PM, Rick Morrison wrote: On 6/3/06, Michael Bayer [EMAIL PROTECTED] wrote: The Numeric types in SQLAlchemy dont modify the incoming or outgoingreturn type of bind parameters at all. Maybe they should. Letting the DBAPI driver "do what it wants" for type conversion breaks the database independence that SA purports to provide, no? Rick___
Sqlalchemy-users mailing list
Sqlalchemy-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sqlalchemy-users
Re: [Sqlalchemy-users] decimal type support in sqlalchemy
I'm feeling it more on the MetaData level. You're looking at two interfaces that any SA user is going to be concerned with:the first is at the database level...those types will be necessarily fixed, by either an existing schema or by the type support or restrictions of the database itself.
the second is at the resultset / mapped object level. This is where the user is going to want some control over data type, to fit into their idea of how to work with the data.What's between these two worlds is the MetaData. Right now, the conversion is implicit and controlled by the DB engine (or maybe more exactly, by the DBAPI interface). But during that conversion, the metadata for that column is available, right? If instead of the implicit conversion, what if there were some sort of pluggable / adaption mechanism that used reasonable defaults, but allowed some sort of override mechanism?
This way, whether you fetched a row from PG, or Sqlite, or whatever, you know that you could morph it into what you need.RickOn 6/3/06,
Michael Bayer [EMAIL PROTECTED] wrote:
right unless they do the override column type thing. which is inconvenient if they want Decimal all over the place.im thinking that with this, along with the various unicode requests we've had, that some real engine/dialect level this is the official map of types I'd like you to use type of thing needs to be created, which is more generic than having flags like convert_unicode and such. but then it would also have to be easy. not sure. heres some ideas:
explicit keywords: x = create_engine(url, string_type=Unicode, numeric_type=Decimal)translate python types to SQL types (i think this is problematic):
x = create_engine(url, types = {str : Unicode, float : Decimal})translate generic SA types to more specific SA types:
x = create_engine(url, types = {String:Unicode, Numeric:Decimal})
just list out the more specific types, which know how to replace their more generic types, i sort of like this one but not sure if it works:
x = create_engine(url, use_types = [Unicode, Decimal])On Jun 3, 2006, at 4:55 PM, Rick Morrison wrote:
Or maybe a different column type so that user can control what comes back. Course that wouldn't work with table reflection Rick On 6/3/06,
Michael Bayer [EMAIL PROTECTED] wrote:
for this one, i would think float would be the default. then what do we do for people who specifically want a Decimal ? sounds like another flag-like situation like convert_unicode.
On Jun 3, 2006, at 2:16 PM, Rick Morrison wrote: On 6/3/06, Michael Bayer
[EMAIL PROTECTED] wrote:
The Numeric types in SQLAlchemy dont modify the incoming or outgoingreturn type of bind parameters at all. Maybe they should. Letting the DBAPI driver do what it wants for type conversion breaks the database independence that SA purports to provide, no?
Rick
___
Sqlalchemy-users mailing list
Sqlalchemy-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sqlalchemy-users
Re: [Sqlalchemy-users] decimal type support in sqlalchemy
Hello, On Mon, 2006-06-05 at 14:39 -0400, Michael Bayer wrote: so. does that just mean instead of sending a dictionary to Dialect/create_engine(), we send a TypePolicy object ? This seems like a lot of overhead for very little gain as well as not solving the problem. In theory the DBAPI modules already know the best, most efficient DB to Python data type mapping. The fact that Python didn't have a Decimal (quasi-infinite precision) numeric type was why psycopg1 used float. 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). The difficulty with mixing mxDateTime objects with the current python Datetime objects is another example. The mxDateTime objects work better, why the Datetime module was not made a compatible superset seems a poor decision to me. The only suspicion that I have about that is that it would have undermined the commercial sale of the mxDateTime modules. Consider the fact that psycopg2 implements user defined data types. Now how should a TypePolicy react to that? Bottom line 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. Thanks, William. ___ Sqlalchemy-users mailing list Sqlalchemy-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sqlalchemy-users
Re: [Sqlalchemy-users] decimal type support in sqlalchemy
Thanks for pointing this out. I found out that psycopg 1.1.21 gives back a Numeric as float. When I switched to psycopg2, a Decimal object is automatically returned. I was switching from SQLObjects, and there the Numeric is automatically converted to Decimal seemingly by SQLObjects, so I took that for granted. Maybe this should also be added to SA, since then the application won't be dependant on the return type of the DBAPI layer? On 6/3/06, Michael Bayer [EMAIL PROTECTED] wrote: the float type coming from Numeric etc. is straight from the DBAPI, in this case psycopg2. If youd like to make your own Decimal type which translates this value back and forth from whatever float value psycopg2 is giving you, simply subclass TypeDecorator, specify Numeric as the 'impl', and implement the appropriate convert_bind_param(), convert_result_value() methods. instructions are here: http://www.sqlalchemy.org/docs/types.myt#types_custom if you get that done, theres no reason it cant be stuck into the types module, just wouldnt be available if youre on 2.3. -- Hong Yuan 大管家网上建材超市 装修装潢建材一站式购物 http://www.homemaster.cn ___ Sqlalchemy-users mailing list Sqlalchemy-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sqlalchemy-users
Re: [Sqlalchemy-users] decimal type support in sqlalchemy
Last I heard, SA was requiring only Python 2.3, so in-library support for Decimal would be ruled out. RickOn 5/30/06, Yuan HOng [EMAIL PROTECTED] wrote:I got the schema reflected from a PostgreSQL table, where some fields are defined as numeric type. In sqlalchemy the column type is shown assqlalchemy.databases.postgres.PGNumeric. It seems that contents ofthese fields are returned by sqlalchemy as a float instead of adecimal.Decimal object.Is there a way to get a Decimal object returned instead?--Hong Yuan大管家网上建材超市装修装潢建材一站式购物http://www.homemaster.cn ___ Sqlalchemy-users mailing list Sqlalchemy-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sqlalchemy-users
Re: [Sqlalchemy-users] decimal type support in sqlalchemy
Does that mean Python2.4 is not officially supported by SA, in things such like Decimal support? On 6/2/06, Rick Morrison [EMAIL PROTECTED] wrote: Last I heard, SA was requiring only Python 2.3, so in-library support for Decimal would be ruled out. Rick -- Hong Yuan 大管家网上建材超市 装修装潢建材一站式购物 http://www.homemaster.cn ___ Sqlalchemy-users mailing list Sqlalchemy-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sqlalchemy-users
Re: [Sqlalchemy-users] decimal type support in sqlalchemy
the float type coming from Numeric etc. is straight from the DBAPI, in this case psycopg2. If youd like to make your own Decimal type which translates this value back and forth from whatever float value psycopg2 is giving you, simply subclass TypeDecorator, specify Numeric as the 'impl', and implement the appropriate convert_bind_param(), convert_result_value() methods. instructions are here: http://www.sqlalchemy.org/docs/types.myt#types_custom if you get that done, theres no reason it cant be stuck into the types module, just wouldnt be available if youre on 2.3. On Jun 2, 2006, at 10:13 PM, Yuan HOng wrote: Does that mean Python2.4 is not officially supported by SA, in things such like Decimal support? On 6/2/06, Rick Morrison [EMAIL PROTECTED] wrote: Last I heard, SA was requiring only Python 2.3, so in-library support for Decimal would be ruled out. Rick -- Hong Yuan 大管家网上建材超市 装修装潢建材一站式购物 http://www.homemaster.cn ___ Sqlalchemy-users mailing list Sqlalchemy-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sqlalchemy-users ___ Sqlalchemy-users mailing list Sqlalchemy-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sqlalchemy-users
