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!


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.tildeslash.com/pipermail/libzdb-general/attachments/20220718/8bdd62a2/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 40t7alhvlac91.png
Type: image/png
Size: 70139 bytes
Desc: not available
URL: <http://www.tildeslash.com/pipermail/libzdb-general/attachments/20220718/8bdd62a2/attachment.png>

------------------------------

Subject: Digest Footer

_______________________________________________
libzdb-general mailing list
libzdb-general@tildeslash.com
http://www.tildeslash.com/mailman/listinfo/libzdb-general


------------------------------

End of libzdb-general Digest, Vol 72, Issue 2
*********************************************