On 5/17/05, Guido van Rossum <gu...@el...> wrote:
> > Null in database speak still has a type. In other words, there is a
> > difference between a null number and a null string and a null date.
> > Python does not have such a distinction so cx_Oracle simply assumes
> > string. In many cases this won't be a problem even if the underlying
> > data type is number since Oracle implicitly converts data types but in
> > other cases it really matters so you need to specify.
>=20
> Can you give an example of where it matters? (We've got a lot of
> cx_Oracle code in-house here and it has never been an issue AFAIK.)
It matters when you are performing executemany() if one of the first
values are null and one of the remaining values are not null and of a
different data type than string. It also matters when binding arrays.
In other cases, cx_Oracle will rebind a new variable of the correct
type and size which slows things down but otherwise nothing untoward
takes place. Does that explain it?
> > Interfaces are always interesting since the viewpoints are often
> > considerably different. Most times the interface is seamless but there
> > are a few instances where the database viewpoint pokes out. :-) Any
> > suggestions on how to improve this are welcome, of course!
>=20
> So true.
>=20
> > > example, when inserting a 100K-long string into a table column whose
> > > type is CLOB, why would I have to say that it's a CLOB again?
> >
> > Any string longer than 4000 characters cannot be represented as
> > varchar2 but there are several options: long, long raw, CLOB, BLOB so
> > which one gets chosen? At the moment cx_Oracle does not guess at all
> > and simply allows the error to be propagated. Again, suggestions are
> > welcome!
>=20
> It would depend on what happens if you guessed wrong. For example, if
> the conversion to CLOB were lossless and Oracle would automatically
> convert a CLOB to the required type, you could guess CLOB and the worst
> that could happen is that things slow down. But if the conversion is
> lossy or Oracle bites you instead of converting, the status quo seems as
> good as it gets. I guess one of the problems is that you have to pick
> one of the Oracle types without knowing the type that's actually
> required.
Guessing wrong would cause Oracle to blow up so I think the status quo
is the best of a bad situation.
> BTW, this reminds me. What would be the disadvantage of defaulting
> arraysize to something large (e.g. 1000, which we've found to work well
> for our code) other than some wasted memory? How can I calculate the
> memory needed when I set arraysize to a certain value?
Memory is the reason for limiting this and there is some overhead in
preparing the bind variable buffers for use, in particular with BLOB
and CLOB variables where a descriptor must be allocated for each row.
As for calculating the memory you'd have to look at the OCI (or
cx_Oracle) to determine the sizes. It depends on the data type and
size selected -- either implicitly when the variable is bound or
explicitly when setinputsizes() is called.
BTW, in terms of performance, the difference between the different
array sizes is the amount of round trips performed. In general on a
reasonably fast network there is not much difference between an array
size of 50 and an array size of 1000. So it all depends on how much
RAM you have to burn and how important performance is -- the typical
tradeoff. :-)
> --Guido van Rossum (home page: http://www.python.org/~guido)
>=20
> -------------------------------------------------------
> This SF.Net email is sponsored by Oracle Space Sweepstakes
> Want to be the first software developer in space?
> Enter now for the Oracle Space Sweepstakes!
> http://ads.osdn.com/?ad_idt12&alloc_id=16344&opclick
> _______________________________________________
> cx-oracle-users mailing list
> cx-...@li...
> https://lists.sourceforge.net/lists/listinfo/cx-oracle-users
>
|
