Michael Bayer wrote: Thanks for your response.
> Eric Smith wrote: >> In 0.6, dialects.oracle.base.NUMBER derives from types.Numeric and >> types.Integer. In 0.5.3, I think the equivalent is >> databases.oracle.OracleNumeric, which just derives from types.Numeric. >> There's a separate databases.oracle.OracleInteger which just derives >> from types.Integer. >> >> This new behavior breaks my code, because I have something which is >> the equivalent of: >> >> if isinstance(t, types.Integer): >> v = int(val) >> elif isinstance(t, types.Numeric): >> v = Decimal(val) >> >> (There's other stuff going on in this code, but this illustrates the >> problem. Ignore typos, if any. The real code is table driven so >> modifying the individual tests isn't so easy.) >> >> t is the type of an Oracle column I'm trying to insert into, and val >> is a string. In 0.5, this code works, but in 0.6 all of the numeric >> columns match the first isinstance call, even ones with a specified >> scale. > > the first thing to note is that you don't have to use oracle.NUMERIC. If > you stick with Integer and Numeric on your Table, those are the types > you'll usually see, unless the Table object has been reflected. I should have mentioned that, sorry. This is a reflected Table object, so I'm getting back oracle.NUMERIC. What I'm trying to do is make sure my values can be inserted into the reflected Table, by looking at the type of each olumn. The only ones I really need to reformat are dates, because my date values are strings that aren't accepted by Oracle. > So assuming you have a reflected table, if you have oracle.NUMERIC you're > going to look for type.scale == 0 to detect an INT. Right. I think that's what I've ultimately decided to do. Either that or just reformat the date values, and leave all other data types as strings and hope that Oracle does the right things with them. > CHANGES mentions it as such: > > - the Oracle dialect now features NUMBER which intends > to act justlike Oracle's NUMBER type. It is the primary > numeric type returned by table reflection and attempts > to return Decimal()/float/int based on the precision/scale > parameters. [ticket:885] > > you can check #885 for details on the change. Further efforts would > involve a detailed description in the oracle docs at the top of base.py, > and an area in 06Migration describing changes to specific dialects > including Oracle. Thanks, that completely explains the issue. I appreciate your help. Eric. --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
