Is it possible to use sqlobject to connect to a mysql database from iron python? If so, how? What must I install?
I have sqlobject installed for cpython and it works fine, but if I use that same package in ironpython I get "ImportError: No module named _mysql". I understand this to mean that ironpython cannot load the C-based .dlls necessary to access the mysql API. What's the workaround, or is there one?
Looking at the source code sqlobject is pure python, the code is depended on MySQLdb which is restricted to cpython.
However if you modify the code to use mysql.connector (http://dev.mysql.com/doc/connector-python/en/index.html) library which is written in pure python you should be able to estanblish a connection to mysql
Note: That mysql.connector doesn't follow the same api as MySQLdb and will require considerable amount of rewrite to the source code
I believe this may be your best workaround
You have to install the '_mysql' module in python. I have no idea which version of python are you using.
Here are some links to install '_mysql' module for python 2.x or python 3.x
http://www.lfd.uci.edu/~gohlke/pythonlibs/#mysql-python
http://www.technicalbard.com/files/MySQL-python-1.2.2.win32-py2.6.exe
If you see this, it's likely you did some wrong when installing MySQLdb; re-read (or read) README. _mysql is the low-level C module that interfaces with the MySQL client library.
Various versions of MySQLdb in the past have had build issues on "weird" platforms; "weird" in this case means "not Linux", though generally there aren't problems on Unix/POSIX platforms, including BSDs and Mac OS X. Windows has been more problematic, in part because there is no mysql_config available in the Windows installation of MySQL. 1.2.1 solves most, if not all, of these problems, but you will still have to edit a configuration file so that the setup knows where to find MySQL and what libraries to include.
ImportError: libmysqlclient_r.so.14: cannot open shared object file: No such file or directory
The number after .so may vary, but this means you have a version of MySQLdb compiled against one version of MySQL, and are now trying to run it against a different version. The shared library version tends to change between major releases.
Solution: Rebuilt MySQLdb, or get the matching version of MySQL.
Another thing that can cause this: The MySQL libraries may not be on your system path.
Solutions:
set the LD_LIBRARY_PATH environment variable so that it includes the path to the MySQL libraries.
set static=True in site.cfg for static linking
reconfigure your system so that the MySQL libraries are on the default loader path. In Linux, you edit /etc/ld.so.conf and run ldconfig. For Solaris, see Linker and Libraries Guide.
ImportError: ld.so.1: python: fatal: libmtmalloc.so.1: DF_1_NOOPEN tagged object may not be dlopen()'ed
This is a weird one from Solaris. What does it mean? I have no idea. However, things like this can happen if there is some sort of a compiler or environment mismatch between Python and MySQL. For example, on some commercial systems, you might have some code compiled with their own compiler, and other things compiled with GCC. They don't always mesh together. One way to encounter this is by getting binary packages from different vendors.
Solution: Rebuild Python or MySQL (or maybe both) from source.
ImportError: dlopen(./_mysql.so, 2): Symbol not found: _sprintf$LDBLStub Referenced from: ./_mysql.so Expected in: dynamic lookup
This is one from Mac OS X. It seems to have been a compiler mismatch, but this time between two different versions of GCC. It seems nearly every major release of GCC changes the ABI in some why, so linking code compiled with GCC-3.3 and GCC-4.0, for example, can be problematic.
http://mysql-python.sourceforge.net/FAQ.html
http://dakrauth.com/blog/entry/python-and-django-setup-mac-os-x-leopard/
© 2022 - 2024 — McMap. All rights reserved.