Thanks for the quick reply.  A few follow-up questions...

On Sun, Feb 5, 2012 at 9:03 PM, Michael Bayer <mike...@zzzcomputing.com> wrote:
> My first suggestion would be to just use cdecimal.  That way performance 
> would not be an issue - I patch it in at program start time using the example 
> at 
> http://docs.sqlalchemy.org/en/latest/core/types.html#sqlalchemy.types.Numeric 
> .   I've been using this approach in production financial applications for 
> several years without issue.

That looks ideal.  I'll have to see about adding that to our systems.

> If you use the Float() type, the Decimal will be coerced into a regular 
> float(), but you're looking for performance here so that's not the solution.

Does that mean when I eventually I set up a table with a column of
type Float(asdecimal=False), I'll still be hit by the conversion
penalty as the read data is converted to a Decimal first by the
connection, and then to a Float by whatever handles the columns?  It
sounds like yes.


> There's not a public API right now to turn off this handling - it would imply 
> the _OracleNumeric type and other parts of the cx_oracle dialect would need 
> to be further complicated to support two modes of operation, and it was 
> enormously difficult to get precision numeric round trips as it is.    A 
> monkeypatch that would force it off would be:
>
>        engine = create_engine(...)
>        engine.dialect._to_decimal = float
>
> another way you could do it would be to use a connection pool event.   Using 
> the connect event:
>
> from sqlalchemy import event
> @event.listens_for(engine, "connect")
> def connect(connection, rec):
>   connection.outputtypehandler = None
>
> Note that disabling the outputtypehandler will also mess up unicode handling, 
> unless you replace it with another output handler that returns a "unicode" 
> cursor.var().

I'm not too worried about unicode conversions.  All the text in the
database should be ASCII, and I've seen no attempts at unicode
handling anywhere in the code base.

If I do shut off the outputtypehandler on the connection, will that
cause any other problems as I start adding Table objects with the
appropriate Columns?  Will the connection outputtypehandler be reset
when it goes back into the pool?  Or should I just keep one connection
from returning to the pool solely for these old style queries?

-- 
--Anthony

-- 
You received this message because you are subscribed to the Google Groups 
"sqlalchemy" group.
To post to this group, send email to sqlalchemy@googlegroups.com.
To unsubscribe from this group, send email to 
sqlalchemy+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/sqlalchemy?hl=en.

Reply via email to