libzdb-general

libzdb-general@tildeslash.com

1 participants
152 discussions

[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

install problem
by 颜培震 13 Jul '20

13 Jul '20

Dear, I install the libzdb,but failed err msg is "in function _Atomic expected declaration specifiers before 'KstatementID' ". if I want install the version 3.3.3 ,which gcc version is better ?could you help me ? thanks ! C++ install dir

2 1

How to get MYSQL_RES in libzdb
by 范学冬 27 May '20

27 May '20

Hi guys, I‘m trying to rewrite my project with Libzdb, however, my origin project was used to MYSQL official style, now I’m facing problem with the result of mysql. If I want to get MYSQL_RES in Libzdb, what should I do?

1 0

[Announce] libzdb 3.2.2
by Jan-Henrik Haukeland 31 Mar '20

31 Mar '20

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

1 0

[Announce] libzdb 3.2.1
by Jan-Henrik Haukeland 06 Mar '20

06 Mar '20

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

1 0

Compile issue on opensuse 15.1
by Admin Beckspaced 19 Feb '20

19 Feb '20

Dear libzdb users ;) trying to compile libzdb 3.2 on an opensuse 15.1 box via ./configure --prefix=/usr --libdir=/usr/lib64 --without-postgresql --without-sqlite make then throws an error, see below ... how can I fix this? thanks & greetings Becki cx20:~/software/libzdb/libzdb-3.2 # make make all-recursive make[1]: Entering directory '/root/software/libzdb/libzdb-3.2' Making all in . make[2]: Entering directory '/root/software/libzdb/libzdb-3.2' make[2]: Nothing to be done for 'all-am'. make[2]: Leaving directory '/root/software/libzdb/libzdb-3.2' Making all in test make[2]: Entering directory '/root/software/libzdb/libzdb-3.2/test' g++ -DHAVE_CONFIG_H -I/usr/include/mysql -I/usr/include/mysql/mariadb -I../zdb -std=c++17 -g -O2 -c -o zdbpp-zdbpp.o `test -f 'zdbpp.cpp' || echo './'`zdbpp.cpp zdbpp.cpp: In function ‘void testQuery(zdb::ConnectionPool&)’: zdbpp.cpp:60:9: error: ‘assert’ was not declared in this scope assert(result.columnCount() == 4); ^~~~~~ zdbpp.cpp:60:9: note: suggested alternative: ‘qsort’ assert(result.columnCount() == 4); ^~~~~~ qsort make[2]: *** [Makefile:445: zdbpp-zdbpp.o] Error 1 make[2]: Leaving directory '/root/software/libzdb/libzdb-3.2/test' make[1]: *** [Makefile:758: all-recursive] Error 1 make[1]: Leaving directory '/root/software/libzdb/libzdb-3.2' make: *** [Makefile:503: all] Error 2

2 2

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