Hello,
I needed Python 3 support so I started working with SWIG, by making an i file around zdbpp.h. Unfortunately, some changes are needed and some interfaces seem hard to support. PreparedStatement::setString is particularly hard as SWIG temporarily converts the Python's Unicode string to UTF8, so the PreparedStatement object should copy the resulting string instead of just keeping it. By example, in MySQL, _setString from MysqlPreparedStatement.c keeps the pointer: P->bind[i].buffer = (char*)x; . That pointer won't be valid when the execute() is finally called. Is SWIG support something interesting for you? By no means I am not a SWIG expert, but could I propagate these changes in a separate branch or something ? How can I avoid starting just another lonely private fork ?
I appreciate this project for its code rigor and up-to-date maintenance.
Thank you, Liviu
On 18 Jul 2022, at 11:11, Liviu Andron liviu.andron@bjtmail.com wrote:
Hello,
I needed Python 3 support so I started working with SWIG, by making an i file around zdbpp.h. Unfortunately, some changes are needed and some interfaces seem hard to support. PreparedStatement::setString is particularly hard as SWIG temporarily converts the Python's Unicode string to UTF8, so the PreparedStatement object should copy the resulting string instead of just keeping it. By example, in MySQL, _setString from MysqlPreparedStatement.c keeps the pointer: P->bind[i].buffer = (char*)x; . That pointer won't be valid when the execute() is finally called.
Both PreparedStatement::setString and PreparedStatement::setBlob require the parameter value to be passed by reference. The reason, especially for setBlob, is that the size might be in many megabytes and we want to avoid copy to be faster. Client code need to have a reference to the buffer in any case and holding on to it until calling PreparedStatement.execute seems reasonable. Hopefully this might be possible to do in the SWIG code also?
Is SWIG support something interesting for you? By no means I am not a SWIG expert, but could I propagate these changes in a separate branch or something ? How can I avoid starting just another lonely private fork ?
I though that almost all scripting languages and higher level languages already have a plethora of Database Connection and ORM offerings. I appreciate that you want to bring libzdb to Python, but suspect it will be fringe there. I’m not sure we will be able to maintain a SWIG implementation as we don’t use and we don’t know anything about SWIG.
As a side-note, just saw this on reddit today:-)
I appreciate this project for its code rigor and up-to-date maintenance.
Thank you!