Hello,

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?

I understand that for an PreparedStatement object the arguments must be kept until execute, but for setString has to convert the string into a temporary variable that will be destroyed after the call. I am not aware of a possibility to take ownership of that object. There's a define, SWIG_PYTHON_STRICT_BYTE_CHAR, but that means that all strings have to be transferred now as bytes (b"mysql://localhost:3306/test?user=root&password=root" instead of just "mysql://localhost:3306/test?user=root&password=root") which is confusing for new code and not easily compatible with old code. Knowing that in Python it is easier to assembly strings, I preferred, for the moment, to "remove" PreparedStatement: %ignore PreparedStatement; and use Connection::execute / Connection::executeQyery (the simple versions ...)

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.

Now that you say it, I see them :)): https://docs.sqlalchemy.org/en/14/core/pooling.html. But I don't think I can dump all the work already done and put all my hope in something else. I took over some first try of SQL connection pooling using an already altered libzdb version, with Python wrappers around. This seems like a nightmare for maintenance. I prefer SWIG and some light changes in libzdb.

Good joke and speed might be the answer of my boss in libzdb vs sqlalchemy (although it shouldn't matter for the needed work)

Thank you, Liviu

On Mon, Jul 18, 2022 at 7:19 PM libzdb-general-request@tildeslash.com wrote:

Send libzdb-general mailing list submissions to libzdb-general@tildeslash.com

To subscribe or unsubscribe via the World Wide Web, visit http://www.tildeslash.com/mailman/listinfo/libzdb-general or, via email, send a message with subject or body 'help' to libzdb-general-request@tildeslash.com

You can reach the person managing the list at libzdb-general-owner@tildeslash.com

When replying, please edit your Subject line so it is more specific than "Re: Contents of libzdb-general digest..."

Today's Topics:

1. Re: SWIG support (Jan-Henrik Haukeland)

---

Message: 1 Date: Mon, 18 Jul 2022 19:19:18 +0200 From: Jan-Henrik Haukeland hauk@tildeslash.com To: This is the libzdb general mailing list libzdb-general@tildeslash.com Subject: Re: SWIG support Message-ID: CE8F59E5-9D72-436C-8AC0-983E261ADCB9@tildeslash.com Content-Type: text/plain; charset="utf-8"

...

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!