chornbeak / pyodbc

Automatically exported from code.google.com/p/pyodbc
MIT No Attribution
0 stars 0 forks source link

Numpy types for inserting rows #311

Open GoogleCodeExporter opened 8 years ago

GoogleCodeExporter commented 8 years ago
What steps will reproduce the problem?
1. Use a numpy integer (numpy.int8,int16,...)
2. Insert as appropriate type in a db2 table

What is the expected output? What do you see instead?
It is impossible to insert using numpy types, or if inserted, the 
interpretation is wrong: the bits in the numpy types are interpreted wrong.

What version of the product are you using? On what operating system?
pyodbc 2.x and 3.x, on Linux 64-bit. Connecting to a RedHat 6.3 db2 9.7 server.

Please add support for numpy types in your library! It will greatly improve how 
it can be used for administering numerics inserted into dbs.

Original issue reported on code.google.com by erlend.a...@gmail.com on 12 Mar 2013 at 7:45

GoogleCodeExporter commented 8 years ago
[deleted comment]
GoogleCodeExporter commented 8 years ago
[deleted comment]
GoogleCodeExporter commented 8 years ago
It might be more a numpy problem rather than a pyodbc issue. The misbehavior is 
due to the fail of PyInt_Check or PyLong_Check on numpy.int32 and numpy.int64. 
After some searches, seems it is a well known issue but without a good solution 
yet.

Original comment by randomiz...@gmail.com on 27 Aug 2013 at 9:13

GoogleCodeExporter commented 8 years ago
To be honest, the python integers are the ones that are weird. This can easily 
be verified with sys.getsizeof. A numpy.int64 is a c integer using 64 bits of 
memory. python longs uses an arbitrary number of bits, depending on the 
magnitude of the integer. This issue may even cause problems in the database if 
you try to insert an integer which is bigger than the database type allows.

Example:
a=long(1000)
b=numpy.int64(a)

sys.getsizeof(a)
sys.getsizeof(b)

c=2**200
d=numpy.int64(c)

sys.getsizeof(c)

Original comment by erlend.a...@gmail.com on 28 Aug 2013 at 5:44