libzdb-general

libzdb-general@tildeslash.com

2 participants
147 discussions

Libzdb not working with ProxySQL
by g4-lisz＠tonarchiv.ch 24 Jun '25

24 Jun '25

Hi there, I wrote an application using libzdb, which works fine when I connect directly to a MySQL server. But when I connect to ProxySQL I get this error when doing a Connection_executeQuery(): SQLException: Commands out of sync; you can't run this command now raised in Connection_executeQuery at src/db/Connection.c:335 It's a very basic select: "SELECT * FROM instance". When I do the same with libmysql (acutally it's libmariadb), there's no issue. This is the test code: #include <stdio.h> #include <zdb.h> main() { URL_T url = URL_new("mysql://sbuser:sbpass@127.0.0.1:6033/cpr_db"); ConnectionPool_T pool = ConnectionPool_new(url); ConnectionPool_start(pool); Connection_T con = ConnectionPool_getConnection(pool); ResultSet_T result = Connection_executeQuery(con, "SELECT * FROM instance"); while (ResultSet_next(result)) { int id = ResultSet_getInt(result, 1); printf("%dn", id); } Connection_close(con); ConnectionPool_free(&pool); URL_free(&url); } Any idea what is the issue here? Cheers Till

2 4

Question about Exceptions
by g4-lisz＠tonarchiv.ch 24 Jun '25

24 Jun '25

Hi there, To me it's a bit unclear in which case I should use Connection_getLastError(). And, when using Exception_frame.message, if it makes sense to catch a specific exception. What I mean is: TRY { Connection_executeQuery(...); } CATCH (SQLException) { printf("SQLException -- %sn", Connection_getLastError(c)); } versus TRY { Connection_executeQuery(...); } CATCH (SQLException) { printf("SQLException -- %sn", Exception_frame.message); } versus TRY { Connection_executeQuery(...); } ELSE { printf("Exception -- %sn", Exception_frame.message); } Ok, I understand that ELSE { } will catch every exception, so I can't safely use Connection_getLastError() there. But with CATCH(SQLException), is there a situation where Connection_getLastError() is preferred over Exception_frame.message? Cheers, Till

2 2

Feature Request: ResultSet_isnullByName
by g4-lisz＠tonarchiv.ch 06 Jun '25

06 Jun '25

Hello everyone! This is my first post to this list... I just started using libzdb. It's exactly what I was looking for. I realized that I have to use ResultSet_isnull() to differentiate between NULL and 0 on integers... I started to use the ...ByName functions because it makes my code more readable and also more robust. Now I was wondering why there's no ResultSet_isnullByName() function. Maybe there's a good reason for it? I just added the missing code and I can't see any issue with using it... Cheers Till

2 5

[Announce] libzdb 3.4.1
by Jan-Henrik Haukeland 03 Jun '25

03 Jun '25

Version 3.4.1 of libzdb is available: Download: https://www.tildeslash.com/libzdb/dist/libzdb-3.4.1.tar.gz SHA256 checksum: 5b4633fc2a16880f776197f4045f62ef8db5062f63030fa221011d4b85d736cb Please see the release notes at https://tildeslash.com/libzdb/#release_notes Notably, this version reintroduces shared cache support for SQLite. To enable this, set the ‘shared-cache=true’ parameter in the SQLite connection URL. Although shared cache has been deprecated by SQLite, it remains crucial in multi-threaded scenarios where each thread establishes a connection and writes to the database. By combining shared cache support with the SQLite unlock notify API, we observe a significant reduction in database lock errors and improved concurrency.

1 0

[Announce] libzdb 3.4.0
by Jan-Henrik Haukeland 01 Aug '24

01 Aug '24

Version 3.4.0 of libzdb is available: Download: https://www.tildeslash.com/libzdb/dist/libzdb-3.4.0.tar.gz SHA256 checksum: abd675719bcbdde430aa4ee13975b980d55d2abcb5cc228082a30320a6bb9f0f Please see the full release notes at https://tildeslash.com/libzdb/#release_notes Hot on the heels of the previous release, here's a new one. I wanted this out to complement the previous release. Of note in this release are: • Support for specifying the transaction isolation level using Connection_beginTransactionType(). Or Connection::beginTransaction in C++. • Activation of multi-thread mode with SQLite, which should be very useful and improve concurrency for multi-threaded applications. Also, some clean up and removal of support for the deprecated shared cache mode. Add serialized=true to the URL if you instead want to use SQLite in serialized mode. SQLite has a page describing threading modes in more detail, https://www.sqlite.org/threadsafe.html • Plus some C++ fixes. • Finally, we introduce a useful little macro, 'valueOr', inspired by C++'s std::optional's value_or() function. This macro is defined in zdb.h and can be used with pointer and numeric types to set a default value if a function or expression returns NULL, 0, or a negative value. It should be quite useful with e.g. ResultSet. Example: const char* host = valueOr(ResultSet_getStringByName(r, "host"), "localhost”);

1 0

[Announce] libzdb 3.3.0
by Jan-Henrik Haukeland 23 Jul '24

23 Jul '24

Version 3.3.0 of libzdb is now available: Download: https://www.tildeslash.com/libzdb/dist/libzdb-3.2.3.tar.gz SHA256 checksum: b1f979f48f4c52f71821f4b2983ef26cf08fc58337effe5651155cfaa96ce95d Please see the release notes at https://tildeslash.com/libzdb/#release_notes The Connection Pool has a better locking strategy and should be much more responsive when multiple threads request connections simultaneously.

1 0

[Announce] libzdb 3.2.3
by Jan-Henrik Haukeland 18 Oct '22

18 Oct '22

Version 3.2.3 of libzdb is now available: Download: https://tildeslash.com/libzdb/dist/libzdb-3.2.3.tar.gz MD5 checksum: bbde5515b5d2508b80cf18c03c8c6a82 Please see the release notes at https://tildeslash.com/libzdb/#release_notes

1 0

Re: SWIG support
by Liviu ANDRON 19 Jul '22

19 Jul '22

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(a)tildeslash.com> wrote: > Send libzdb-general mailing list submissions to > libzdb-general(a)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(a)tildeslash.com > > You can reach the person managing the list at > libzdb-general-owner(a)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(a)tildeslash.com> > To: This is the libzdb general mailing list > <libzdb-general(a)tildeslash.com> > Subject: Re: SWIG support > Message-ID: <CE8F59E5-9D72-436C-8AC0-983E261ADCB9(a)tildeslash.com> > Content-Type: text/plain; charset="utf-8" > > > > > On 18 Jul 2022, at 11:11, Liviu Andron <liviu.andron(a)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! > > >

1 0

SWIG support
by Liviu Andron 18 Jul '22

18 Jul '22

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

2 1

Read-Only Transaction
by nBeta Github 23 Nov '20

23 Nov '20

Dear libzdb maintainers, There is possibility to start read-only transactions? If not there are plans to support such a feature? I have seen in the source code that it will be fairly simple to add, I can take it over my self such an endeavor but I need to know it is in the best interest and conforms with your own rules and future development. Thanks, Cosmin Cioranu

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

libzdb-general