[Zope] [OT] Example of Forcing Type coercion on a DCOracle2 column?

John Ziniti jziniti@speakeasy.org
Wed, 19 Mar 2003 17:09:36 -0500

Thanks Matt.  I've been able to get around the initial problem
I was having by using the XMLTYPE's getClobValue() to have
Oracle return a CLOB instead of the XMLTYPE, which was
causing DCOracle2 to Segfault.

However, no write()s to this CLOB ever get written back to
the database.

I've also discovered the Zope-DB mailing list, so I'll be using
that to post these types of problems from now on.

Matthew T. Kromer wrote:

> John Ziniti wrote:
>> Hello --
>> The DCOracle2 Documentation states that it is possible to force
>> type coercion on a result column to particular type, but does not
>> give an example of how to do this.  Does anyone have any
>> suggestions?  I am trying to force an XMLTYPE column into
>> a CLOB.
>> TIA,
>> John Ziniti
> It doesn't go into detail because you really, really don't want to 
> unless you know what you are doing.
> What the DCOracle2 type coercion does is assert to Oracle that the 
> python object is whatever type you say it is.
> What this is most useful for is changing a string into something else 
> -- but you have to be very careful that your input data is in fact 
> properly formatted.
> For example, if I say
> import DCOracle2
> i = DCOracle2.TypeCoercion("foo", "SQLT_INT")
> I'm creating a coerced variable "i" that will claim to be an int.  In 
> fact, when Oracle goes to read it, it will read 0x666f6f00 (depending 
> on the byte order).  This may or may not be 1718578944 -- but it 
> certainly isn't a very useful value.  The coercion is applied AFTER 
> the normal python type->oracle data type binding happens, ie it really 
> just affects the bind declaration.  If I coerce the number 1, I'm 
> really referring to an address in memory pointing to a value 
> containing 0x00000001 with a length of four bytes.  When oracle is 
> passed this pointer, its told what the data type is it points at.  The 
> TypeCoercion overrides what the declared type is, but doesn't 
> *reformat* the data.
> Why would you want to do this?  Well, maybe you want to handle the 
> binary conversion of values yourself.  The underlying C module dco2 
> will let you get at the raw memory behind a result, so you could 
> extend DCOracle2 to understand new types without writing additional C 
> code.