You can subscribe to this list here.
2005 |
Jan
|
Feb
|
Mar
(4) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(2) |
Nov
|
Dec
(8) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2006 |
Jan
(12) |
Feb
(31) |
Mar
(25) |
Apr
(1) |
May
(25) |
Jun
(12) |
Jul
(2) |
Aug
(6) |
Sep
(11) |
Oct
(18) |
Nov
(11) |
Dec
(33) |
2007 |
Jan
(35) |
Feb
(57) |
Mar
(35) |
Apr
(9) |
May
(1) |
Jun
(16) |
Jul
(22) |
Aug
(7) |
Sep
(17) |
Oct
(19) |
Nov
(17) |
Dec
(12) |
2008 |
Jan
(9) |
Feb
(21) |
Mar
(14) |
Apr
(63) |
May
(27) |
Jun
(29) |
Jul
(47) |
Aug
(20) |
Sep
(35) |
Oct
(27) |
Nov
(27) |
Dec
(21) |
2009 |
Jan
(35) |
Feb
(48) |
Mar
(27) |
Apr
(54) |
May
(23) |
Jun
(26) |
Jul
(22) |
Aug
(45) |
Sep
(15) |
Oct
(20) |
Nov
(19) |
Dec
(12) |
2010 |
Jan
(82) |
Feb
(38) |
Mar
(10) |
Apr
(8) |
May
(3) |
Jun
(5) |
Jul
(1) |
Aug
(4) |
Sep
(101) |
Oct
(38) |
Nov
(25) |
Dec
(110) |
2011 |
Jan
(44) |
Feb
(12) |
Mar
(21) |
Apr
(7) |
May
(2) |
Jun
(24) |
Jul
(28) |
Aug
(15) |
Sep
(2) |
Oct
(29) |
Nov
(34) |
Dec
(11) |
2012 |
Jan
(8) |
Feb
(16) |
Mar
(23) |
Apr
(19) |
May
(62) |
Jun
(24) |
Jul
(34) |
Aug
(12) |
Sep
(49) |
Oct
(52) |
Nov
(76) |
Dec
(46) |
2013 |
Jan
(29) |
Feb
(97) |
Mar
(144) |
Apr
(70) |
May
(14) |
Jun
(42) |
Jul
(41) |
Aug
(4) |
Sep
(26) |
Oct
(9) |
Nov
(16) |
Dec
(6) |
2014 |
Jan
(7) |
Feb
(12) |
Mar
(10) |
Apr
(12) |
May
|
Jun
(6) |
Jul
(3) |
Aug
(1) |
Sep
|
Oct
(7) |
Nov
(11) |
Dec
(9) |
2015 |
Jan
(7) |
Feb
(2) |
Mar
(28) |
Apr
(18) |
May
(9) |
Jun
(1) |
Jul
(1) |
Aug
(3) |
Sep
(9) |
Oct
(10) |
Nov
(3) |
Dec
(2) |
2016 |
Jan
(2) |
Feb
|
Mar
(1) |
Apr
(3) |
May
|
Jun
|
Jul
|
Aug
|
Sep
(8) |
Oct
(3) |
Nov
(10) |
Dec
|
2017 |
Jan
|
Feb
|
Mar
(2) |
Apr
|
May
(5) |
Jun
|
Jul
(1) |
Aug
(3) |
Sep
(2) |
Oct
|
Nov
|
Dec
|
2018 |
Jan
|
Feb
(4) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(9) |
Dec
|
2019 |
Jan
(2) |
Feb
|
Mar
(10) |
Apr
(3) |
May
(11) |
Jun
(4) |
Jul
|
Aug
(12) |
Sep
(1) |
Oct
(3) |
Nov
(2) |
Dec
(7) |
2020 |
Jan
|
Feb
(2) |
Mar
|
Apr
|
May
|
Jun
|
Jul
(1) |
Aug
|
Sep
|
Oct
(1) |
Nov
|
Dec
|
2021 |
Jan
|
Feb
|
Mar
|
Apr
(3) |
May
(14) |
Jun
(3) |
Jul
|
Aug
(6) |
Sep
(2) |
Oct
(7) |
Nov
|
Dec
(1) |
2022 |
Jan
|
Feb
(1) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2023 |
Jan
|
Feb
|
Mar
|
Apr
(5) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: <sbu...@up...> - 2023-04-26 00:25:21
|
Hello, my name is Sascha I am using SOCI 4.0.3 to access different database systems with the ODBC backend. All is working fine so far, but now I try to implement a reconnect logic I case the Database connection failed. I try it in the following way: I have a timer that tries ever x seconds to connect to the Database by open a connection, fire a query Select 1 from dual against the database and if all works it closes the database connection. If the select or connect failed, it further tries every x seconds. Once the query succeed (Database is back again) the connection pool should be reconnect all sessions to the Database. I tried several ways to archive this: Loop trough the pool and use the reconnect on every Session in the Pool -> Fails (either SIGABRT or SIGPIPE application exited) Loop trough the pool and close the Session and Open it again -> Fails (either SIGABRT or SIGPIPE application exited) Loop trough the pool and open the Session again -> Fails (Could not connect already open btw connected session (but session is not connected) The Application also exit with some SIGNAL and ignoring that I have try catch around the pool operations. Can someone help me out how to clean up and reconnect all sessions in the Pool after the Database is back online again? It will be also okay for me to destroy the pool and recreate/init it again but don’t know how to do that ☹ If you need more Information please let me know. Thx and Regards Sascha |
From: Vadim Z. <vz...@ze...> - 2023-04-25 13:00:06
|
On Tue, 25 Apr 2023 09:48:15 +0200 Tomaz Canabrava <tca...@kd...> wrote: TC> My name is Tomaz Canabrava, I'm a Opensource developer mostly interested in TC> contributing back to projects that I use. Hi Tomaz and welcome! I'm also an open source developer interested in exactly the same thing, but this has somehow resulted me in maintaining SOCI now :-/ TC> I forked a soci in github and I'm using version 4.0.3 to develop an TC> application that should run in all major operating systems but it seems TC> that the current mailine branch of soci has more modern CMake constructs TC> than 4.0.3 Unfortunately I don't know much about CMake and prefer to touch it as little as possible. Thankfully there are other people who take care of it in SOCI, mostly, but I'm afraid this means I won't be able to help you with anything CMake-related. TC> I had to hack around some issues that I found to be able to link Soci in TC> linux / mac, as you can see in this patch. I also want to know if patches TC> for 4.0.x are still accepted, Sure, I can merge PRs to 4.0, it's just that personally I don't have any plans to work on it. TC> if not, if it's safe to do a new release with current mailine branch or TC> if the team needs help to finish what's needed for a new release. I really, really need to test the final version of the PR 954 and make a new release once it's merged. But FWIW we do use current SOCI master in production without any (known) problems, with multiple backends. TC> But now on windows I'm having this issue: TC> TC> error LNK2019: unresolved external symbol "struct TC> soci::sqlite3_backend_factory const soci::sqlite3" (?sqlite3@soci TC> @@3Usqlite3_backend_factory@1@B) referenced in function "public: bool TC> __cdecl SociWriter::createOrOpen(class std::string const &)" TC> (?createOrOpen@SociWriter@lvtmdb@Codethink@@QEAA_NAEBV?$basic_string@DU TC> ?$char_traits@D@std@@V?$allocator@D@2@@std@@@Z) TC> [C:\Project\Build\lvtmdb.vcxproj] TC> TC> And I'm linking on all targets with: TC> Soci::Core TC> Soci::soci_sqlite3 TC> TC> (that are the names I exported via cmake ALIAS) TC> TC> Any help is appreciated :) Are you using static or shared SOCI libraries? When using shared libraries you shouldn't depend on this variable. When using static ones, it should be found in the soci_sqlite3... Best regards, VZ |
From: Tomaz C. <tca...@kd...> - 2023-04-25 07:48:35
|
Hello, My name is Tomaz Canabrava, I'm a Opensource developer mostly interested in contributing back to projects that I use. I recently started to use Soci - as I need to replace another database layer in my software. I forked a soci in github and I'm using version 4.0.3 to develop an application that should run in all major operating systems but it seems that the current mailine branch of soci has more modern CMake constructs than 4.0.3 I had to hack around some issues that I found to be able to link Soci in linux / mac, as you can see in this patch. I also want to know if patches for 4.0.x are still accepted, if not, if it's safe to do a new release with current mailine branch or if the team needs help to finish what's needed for a new release. https://github.com/tcanabrava/soci/commit/b641dfcc854580d4c2abd87a67a759905fccfe98 without this I am unable to compile and link, in source or as a submodule in windows, mac and linux (it complains about the missing "soci/soci-config.h") But now on windows I'm having this issue: error LNK2019: unresolved external symbol "struct soci::sqlite3_backend_factory const soci::sqlite3" (?sqlite3@soci @@3Usqlite3_backend_factory@1@B) referenced in function "public: bool __cdecl SociWriter::createOrOpen(class std::string const &)" (?createOrOpen@SociWriter@lvtmdb@Codethink@@QEAA_NAEBV?$basic_string@DU ?$char_traits@D@std@@V?$allocator@D@2@@std@@@Z) [C:\Project\Build\lvtmdb.vcxproj] And I'm linking on all targets with: Soci::Core Soci::soci_sqlite3 (that are the names I exported via cmake ALIAS) Any help is appreciated :) Best, Tomaz |
From: Vadim Z. <vz...@ze...> - 2023-04-24 09:30:20
|
On Tue, 18 Apr 2023 16:22:46 +0000 LUCAS AYALA FRAGOSO <luc...@ma...> wrote: LAF> I've got a question regarding dynamic binding and bulk operations LAF> (only for DQLs). It is possible to do dynamic binding with bulk LAF> operations in order to reduce network roundtrips? LAF> LAF> I have to use the Core interface with `exchange_for_rowset`, but it LAF> seems there is no option to do prefetching since the fetch size used LAF> to call to the backend is determined by the size of the bind variables LAF> (using vectors) and I can't provide such vectors. Is there any option LAF> to do prefetching and dynamic binding? No, sorry, I don't think so, using vectors is the only form of performing bulk operations that I know about. Regards, VZ |
From: LUCAS A. F. <luc...@ma...> - 2023-04-18 17:56:20
|
Hello all, I've got a question regarding dynamic binding and bulk operations (only for DQLs). It is possible to do dynamic binding with bulk operations in order to reduce network roundtrips? I have to use the Core interface with `exchange_for_rowset`, but it seems there is no option to do prefetching since the fetch size used to call to the backend is determined by the size of the bind variables (using vectors) and I can't provide such vectors. Is there any option to do prefetching and dynamic binding? Thanks in advance! |
From: Vadim Z. <vz...@ze...> - 2022-02-10 19:26:06
|
Hello, Latest SOCI release, 4.0.3, has just been made available. This release contains several bug fixes but remains fully compatible with the previous 4.0.x releases and doesn't introduce any new requirements, so updating to it should be quick and simple. Please see https://github.com/SOCI/soci/blob/v4.0.3/CHANGES for the list of the notable changes. The release archives are available at Source Forge: https://sourceforge.net/projects/soci/files/soci/soci-4.0.3/soci-4.0.3.tar.gz https://sourceforge.net/projects/soci/files/soci/soci-4.0.3/soci-4.0.3.zip or also on GitHub, using v4.0.3 tag. The documentation for the latest release is available online at http://soci.sourceforge.net/doc/release/4.0/ and also included in the release archives above. We'd like to thank the following people for contributing to this release: Denis Arnaud Dmitry Arkhipkin gaocheng3 (at asiainfo.sg) gypsy5oul Ilya Sinitsyn Juan Jose Castellanos Lorenz Brun Lukas Zanner Mariana Meireles Matheus Gabriel Werny de Lima Mathäus Mendel please see the AUTHORS file for the full list of contributors. We hope you will find this release useful! Vadim Zeitlin on behalf of SOCI development team |
From: Jim M. <nef...@gm...> - 2021-12-05 00:18:29
|
Hi all- I didn't use your code right the first time. I didn't know I needed to code tcl api stuff in the typemap. Now I took an example from here: SWIG and Tcl <http://www.swig.org/Doc1.1/HTML/Tcl.html> and put it right in my interface file and c file. Is someone out there in TCL sphere that can confirm this behavior in the newest swig 4.0.2? TypeError in method 'mypow', argument 3 of type 'double *' %module korn %include "std_vector.i" %include "std_string.i" %include "typemaps.i" #ifdef SWIG<tcl> %typemap(argout) double *outvalue { char temp[TCL_DOUBLE_SPACE]; Tcl_PrintDouble(interp,*($source),dtemp); Tcl_SetVar(interp,$arg,temp,0); } %typemap(in) double *outvalue { static double temp; $target = &temp; } #endif %{ /* Put headers and other declarations here */ int mypow(double a, double b, double* outvalue); %} int mypow(double a, double b, double* outvalue); int mypow(double a, double b, double* outvalue) { if ((a < 0) || (b < 0)) return -1; *outvalue = pow(a, b); return 0; }; |
From: Jim M. <nef...@gm...> - 2021-10-25 04:33:28
|
Hi Vadim- I forgot to mention I am using COMODO for my system. It likes to block me and put things in a virtual container and makes it look like I did something wrong. It is a WIP until I get better with that security system so I can code without those moments. THANKS On Sun, Oct 24, 2021 at 11:32 PM Vadim Zeitlin <vz...@ze...> wrote: > On Fri, 22 Oct 2021 22:44:48 -0400 Jim McNamara <nef...@gm...> > wrote: > > JM> Hi all- > JM> I can't get the .sln file to appear so I can run msbuild.exe SOCI.sln. > JM> > JM> cmake -DSOCI_CXX11=ON -DWITH_BOOST=OFF -DWITH_ORACLE=OFF > -DWITH_DB2=OFF > JM> -DWITH_MYSQL=OFF -DWITH_ODBC=OFF -DWITH_POSTGRESQL=OFF > -DWITH_SQLITE3=OFF > JM> -DWITH_FIREBIRD=ON -DFIREBIRD_INCLUDE_DIR="C:/Program > JM> Files/Firebird/Firebird_4_0/include" -DFIREBIRD_LIBRARIES="C:/Program > JM> Files/Firebird/Firebird_4_0/lib/fbclient_ms.lib" > JM> -DSOCI_FIREBIRD_TEST_CONNSTR:STRING="service=localhost:/Program > JM> Files/firebird/firebird_4_0/examples/empbuild/EMPLOYEE.FBD user=SYSDBA > JM> password=mypassword" ../ > JM> > JM> Is anyone else using visual studio 2019? > > Yes, SOCI builds with it without any problems. I don't understand what > exactly are you doing and having multiple messages about (apparently?) the > same problem doesn't help, but if you start from the beginning, i.e. clean > working tree and use the same commands as in appveyor.yml, you shouldn't > have any problems with building. > > Regards, > VZ_______________________________________________ > soci-users mailing list > soc...@li... > https://lists.sourceforge.net/lists/listinfo/soci-users > |
From: Jim M. <nef...@gm...> - 2021-10-25 04:10:52
|
Hi Vadim I have SOCI up and running for firebird 4.0. I just stopped long enough tonight to fool with getting bluefish to work in MSYS2 and install abyss web server, so I can start a new mini website. The fact that I am using visual-studio is an immense help now to get me going. Once I get bluefish going, I will make some project videos with the software at home and put it all on my site. THANKS On Sun, Oct 24, 2021 at 11:32 PM Vadim Zeitlin <vz...@ze...> wrote: > On Fri, 22 Oct 2021 22:44:48 -0400 Jim McNamara <nef...@gm...> > wrote: > > JM> Hi all- > JM> I can't get the .sln file to appear so I can run msbuild.exe SOCI.sln. > JM> > JM> cmake -DSOCI_CXX11=ON -DWITH_BOOST=OFF -DWITH_ORACLE=OFF > -DWITH_DB2=OFF > JM> -DWITH_MYSQL=OFF -DWITH_ODBC=OFF -DWITH_POSTGRESQL=OFF > -DWITH_SQLITE3=OFF > JM> -DWITH_FIREBIRD=ON -DFIREBIRD_INCLUDE_DIR="C:/Program > JM> Files/Firebird/Firebird_4_0/include" -DFIREBIRD_LIBRARIES="C:/Program > JM> Files/Firebird/Firebird_4_0/lib/fbclient_ms.lib" > JM> -DSOCI_FIREBIRD_TEST_CONNSTR:STRING="service=localhost:/Program > JM> Files/firebird/firebird_4_0/examples/empbuild/EMPLOYEE.FBD user=SYSDBA > JM> password=mypassword" ../ > JM> > JM> Is anyone else using visual studio 2019? > > Yes, SOCI builds with it without any problems. I don't understand what > exactly are you doing and having multiple messages about (apparently?) the > same problem doesn't help, but if you start from the beginning, i.e. clean > working tree and use the same commands as in appveyor.yml, you shouldn't > have any problems with building. > > Regards, > VZ_______________________________________________ > soci-users mailing list > soc...@li... > https://lists.sourceforge.net/lists/listinfo/soci-users > |
From: Vadim Z. <vz...@ze...> - 2021-10-25 03:32:11
|
On Fri, 22 Oct 2021 22:44:48 -0400 Jim McNamara <nef...@gm...> wrote: JM> Hi all- JM> I can't get the .sln file to appear so I can run msbuild.exe SOCI.sln. JM> JM> cmake -DSOCI_CXX11=ON -DWITH_BOOST=OFF -DWITH_ORACLE=OFF -DWITH_DB2=OFF JM> -DWITH_MYSQL=OFF -DWITH_ODBC=OFF -DWITH_POSTGRESQL=OFF -DWITH_SQLITE3=OFF JM> -DWITH_FIREBIRD=ON -DFIREBIRD_INCLUDE_DIR="C:/Program JM> Files/Firebird/Firebird_4_0/include" -DFIREBIRD_LIBRARIES="C:/Program JM> Files/Firebird/Firebird_4_0/lib/fbclient_ms.lib" JM> -DSOCI_FIREBIRD_TEST_CONNSTR:STRING="service=localhost:/Program JM> Files/firebird/firebird_4_0/examples/empbuild/EMPLOYEE.FBD user=SYSDBA JM> password=mypassword" ../ JM> JM> Is anyone else using visual studio 2019? Yes, SOCI builds with it without any problems. I don't understand what exactly are you doing and having multiple messages about (apparently?) the same problem doesn't help, but if you start from the beginning, i.e. clean working tree and use the same commands as in appveyor.yml, you shouldn't have any problems with building. Regards, VZ |
From: Jim M. <nef...@gm...> - 2021-10-23 18:20:29
|
Hi all- It turns out Comodo firewall likes to block many things. build is okay now. thanks |
From: Jim M. <nef...@gm...> - 2021-10-23 05:44:26
|
Hi all- I get the following error message when trying to run make on my cmake soci script. Please let me know if you have an idea to help me fix it. THANKS c:\soci-4.0.2\build>make.exe [ 1%] Building CXX object src/core/CMakeFiles/soci_core.dir/backend-loader.cpp.obj C:/soci-4.0.2/src/core/backend-loader.cpp:239:20: error: use of undeclared identifier 'soci_'; did you mean 'soci'? h = DLOPEN(LIBNAME(name).c_str()); ^ C:/soci-4.0.2/src/core/backend-loader.cpp:46:25: note: expanded from macro 'LIBNAME' #define LIBNAME(x) (SOCI_LIB_PREFIX + x + "_" SOCI_ABI_VERSION SOCI_DEBUG_POSTFIX SOCI_LIB_SUFFIX) ^ <command line>:4:25: note: expanded from here #define SOCI_LIB_PREFIX soci_ ^ C:/soci-4.0.2/include\soci/backend-loader.h:16:11: note: 'soci' declared here namespace soci ^ C:/soci-4.0.2/src/core/backend-loader.cpp:239:20: error: unexpected namespace name 'soci': expected expression h = DLOPEN(LIBNAME(name).c_str()); ^ C:/soci-4.0.2/src/core/backend-loader.cpp:46:25: note: expanded from macro 'LIBNAME' #define LIBNAME(x) (SOCI_LIB_PREFIX + x + "_" SOCI_ABI_VERSION SOCI_DEBUG_POSTFIX SOCI_LIB_SUFFIX) ^ <command line>:4:25: note: expanded from here #define SOCI_LIB_PREFIX soci_ ^ C:/soci-4.0.2/src/core/backend-loader.cpp:245:73: error: use of undeclared identifier 'soci_'; did you mean 'soci'? std::string const fullFileName(search_paths_[i] + "/" + LIBNAME(name)); ^ C:/soci-4.0.2/src/core/backend-loader.cpp:46:25: note: expanded from macro 'LIBNAME' #define LIBNAME(x) (SOCI_LIB_PREFIX + x + "_" SOCI_ABI_VERSION SOCI_DEBUG_POSTFIX SOCI_LIB_SUFFIX) ^ <command line>:4:25: note: expanded from here #define SOCI_LIB_PREFIX soci_ ^ C:/soci-4.0.2/include\soci/backend-loader.h:16:11: note: 'soci' declared here namespace soci ^ C:/soci-4.0.2/src/core/backend-loader.cpp:245:73: error: unexpected namespace name 'soci': expected expression std::string const fullFileName(search_paths_[i] + "/" + LIBNAME(name)); ^ C:/soci-4.0.2/src/core/backend-loader.cpp:46:25: note: expanded from macro 'LIBNAME' #define LIBNAME(x) (SOCI_LIB_PREFIX + x + "_" SOCI_ABI_VERSION SOCI_DEBUG_POSTFIX SOCI_LIB_SUFFIX) ^ <command line>:4:25: note: expanded from here #define SOCI_LIB_PREFIX soci_ ^ 4 errors generated. make[2]: *** [src/core/CMakeFiles/soci_core.dir/build.make:77: src/core/CMakeFiles/soci_core.dir/backend-loader.cpp.obj] Error 1 make[1]: *** [CMakeFiles/Makefile2:363: src/core/CMakeFiles/soci_core.dir/all] Error 2 make: *** [Makefile:146: all] Error 2 c:\soci-4.0.2\build> |
From: Jim M. <nef...@gm...> - 2021-10-23 05:41:36
|
Hi- I am trying to run clang and msys64 for build tools and using the cmake script that built the Makefile. visual studio 2019. soci-4.0.2 cmake 3.20.6 |
From: Jim M. <nef...@gm...> - 2021-10-23 02:45:09
|
Hi all- I can't get the .sln file to appear so I can run msbuild.exe SOCI.sln. cmake -DSOCI_CXX11=ON -DWITH_BOOST=OFF -DWITH_ORACLE=OFF -DWITH_DB2=OFF -DWITH_MYSQL=OFF -DWITH_ODBC=OFF -DWITH_POSTGRESQL=OFF -DWITH_SQLITE3=OFF -DWITH_FIREBIRD=ON -DFIREBIRD_INCLUDE_DIR="C:/Program Files/Firebird/Firebird_4_0/include" -DFIREBIRD_LIBRARIES="C:/Program Files/Firebird/Firebird_4_0/lib/fbclient_ms.lib" -DSOCI_FIREBIRD_TEST_CONNSTR:STRING="service=localhost:/Program Files/firebird/firebird_4_0/examples/empbuild/EMPLOYEE.FBD user=SYSDBA password=mypassword" ../ Is anyone else using visual studio 2019? thanks. |
From: Vadim Z. <vz...@ze...> - 2021-09-02 14:04:26
|
On Thu, 2 Sep 2021 10:04:45 +0100 Andrew Grafham <and...@gm...> wrote: AG> I'm looking at this again and the backend with support for bulk operations AG> is very different from the current MySQL version. In fact, the structure is AG> more similar to the ODBC backend. I was wondering about having essentially AG> 2 separate session implementations for MySQL, and instantiating the right AG> one at runtime via the make_session factory method, based on what version AG> of MySQL we have connected to. Does that sound reasonable? Hi, I am not sure if it's really worth having 2 separate session classes if there is just one method which differs between them, but why not. You would probably want to use a common base class to avoid duplicating the common code between these classes, right? Regards, VZ |
From: Andrew G. <and...@gm...> - 2021-09-02 09:05:02
|
Hi, I'm looking at this again and the backend with support for bulk operations is very different from the current MySQL version. In fact, the structure is more similar to the ODBC backend. I was wondering about having essentially 2 separate session implementations for MySQL, and instantiating the right one at runtime via the make_session factory method, based on what version of MySQL we have connected to. Does that sound reasonable? Cheers Andy |
From: Vadim Z. <vz...@ze...> - 2021-08-09 10:56:06
|
On Mon, 9 Aug 2021 10:12:45 +0100 Andrew Grafham <and...@gm...> wrote: AG> Any ideas how it would detect at runtime whether the server supports bulk AG> operations or not? Sorry, no, I thought it would be just a server version check, but I didn't realize it would be so problematic. And if there is some function for checking the server capabilities in MySQL API, I'm not aware of it (but then, again, I hardly know MySQL API at all, so this doesn't mean much). AG> It's not very helpful - if you're using an older version of MySQL, and AG> you create a statement and set its attribute STMT_ATTR_ARRAY_SIZE, it AG> doesn't return an error until you actually try to execute the AG> statement. Is this error understandable at least? I.e. is it immediately clear that it's due to the server being too old? If it is, I guess we could also try redoing the statement without STMT_ATTR_ARRAY_SIZE and set some internal flag to not use it any more for the future requests. However this would be much more complicated than just a version check, of course. AG> It's not straightforward to add a check on the server's version number AG> because you could be running against MySQL or MariaDB, and there is not AG> a single version where it was added. E.g. MariaDB 10.2.3 had bulk AG> operation support but then they removed it again until 10.2.7. FWIW I think it would be fine to just check for MariaDB >= 10.2.7 and not bother with 10.2.{4,5,6} versions. Regards, VZ |
From: Andrew G. <and...@gm...> - 2021-08-09 09:13:06
|
On Fri, 6 Aug 2021 at 14:09, Vadim Zeitlin <vz...@ze...> wrote: > On Fri, 6 Aug 2021 09:28:33 +0100 Andrew Grafham <and...@gm...> > wrote: > > AG> Would we need to keep backward compatibility with older versions of > MariaDB > AG> that don't support Array Binding? > > Sorry, I really don't know much (well, anything) about M{y,aria}SQL API. > Which version added support for the array bindings? Are earlier versions > still in use? > > AG> If so, how would you like it to determine whether to use Array Binding > AG> or not? Could we use a #define at compile time? > > We need compile-time checks as we don't want to break the library > compilation, but we probably also need run-time checks as I suspect that > nothing good will happen if you try to use this functionality with a server > which doesn't support it. > > Regards, > VZ_______________________________________________ > > Any ideas how it would detect at runtime whether the server supports bulk operations or not? It's not very helpful - if you're using an older version of MySQL, and you create a statement and set its attribute STMT_ATTR_ARRAY_SIZE, it doesn't return an error until you actually try to execute the statement. It's not straightforward to add a check on the server's version number because you could be running against MySQL or MariaDB, and there is not a single version where it was added. E.g. MariaDB 10.2.3 had bulk operation support but then they removed it again until 10.2.7. Thanks Andy |
From: Vadim Z. <vz...@ze...> - 2021-08-06 13:09:10
|
On Fri, 6 Aug 2021 09:28:33 +0100 Andrew Grafham <and...@gm...> wrote: AG> Would we need to keep backward compatibility with older versions of MariaDB AG> that don't support Array Binding? Sorry, I really don't know much (well, anything) about M{y,aria}SQL API. Which version added support for the array bindings? Are earlier versions still in use? AG> If so, how would you like it to determine whether to use Array Binding AG> or not? Could we use a #define at compile time? We need compile-time checks as we don't want to break the library compilation, but we probably also need run-time checks as I suspect that nothing good will happen if you try to use this functionality with a server which doesn't support it. Regards, VZ |
From: Andrew G. <and...@gm...> - 2021-08-06 08:28:52
|
On Thu, 5 Aug 2021 at 16:47, Vadim Zeitlin <vz...@ze...> wrote: > On Thu, 5 Aug 2021 16:39:20 +0100 Andrew Grafham <and...@gm...> > wrote: > > AG> Are there any plans to add support for Array Binding (as mentioned > AG> here MYSQL_BIND > AG> - MariaDB Knowledge Base <https://mariadb.com/kb/en/mysql_bind/>) to > the > AG> MySQL backend? > > I don't use MySQL myself currently, so I don't really have any motivation > for doing it, but if anybody does, any patches/PRs would be welcome, of > course, so please don't hesitate implementing this if you do need it. > > Thanks in advance, > VZ_______________________________________________ > > Would we need to keep backward compatibility with older versions of MariaDB that don't support Array Binding? If so, how would you like it to determine whether to use Array Binding or not? Could we use a #define at compile time? Cheers Andy |
From: Vadim Z. <vz...@ze...> - 2021-08-05 15:46:57
|
On Thu, 5 Aug 2021 16:39:20 +0100 Andrew Grafham <and...@gm...> wrote: AG> Are there any plans to add support for Array Binding (as mentioned AG> here MYSQL_BIND AG> - MariaDB Knowledge Base <https://mariadb.com/kb/en/mysql_bind/>) to the AG> MySQL backend? I don't use MySQL myself currently, so I don't really have any motivation for doing it, but if anybody does, any patches/PRs would be welcome, of course, so please don't hesitate implementing this if you do need it. Thanks in advance, VZ |
From: Andrew G. <and...@gm...> - 2021-08-05 15:39:45
|
Hi, Are there any plans to add support for Array Binding (as mentioned here MYSQL_BIND - MariaDB Knowledge Base <https://mariadb.com/kb/en/mysql_bind/>) to the MySQL backend? At the moment, if you use the vector based inserts it seems to be sending the rows to the database one at a time rather than doing anything in bulk, which isn't ideal for performance. It looks superficially similar to how the ODBC backend does Column wise binding, so maybe it wouldn't be too difficult for me to do, if nobody else is working on it? Thanks Andy |
From: Jim M. <nef...@gm...> - 2021-06-08 19:37:07
|
Hi, Robert at Deepwoods answered my wrapping question. Thanks |
From: Jim M. <nef...@gm...> - 2021-06-07 02:25:18
|
Hi- Tomay, Vadim is helping me with v3.0. I am now making videos to demonstrate connecting to firebird with soci and swig. I have to review 1 or 2 videos today for technical correctness. I connect from tcl to firebird. I wonder is it enough to run the suite of tests at install with cmake to get a more or less answer. Seems there is always something new implemented in each major version that tests wont catch or have a test made for and for your requirements is that enough? For instance I vaguely remember something about boolean in V3.0. Does in production mean all new features like boolean data type in v3.0 are implemented? I think mateusz used to help out (a lot) with stuff like that. Robo-loki |
From: Tomay <tom...@gm...> - 2021-06-02 15:13:55
|
Hello, Firebird v4.0 has been released on 01-06-2021 I wonder if this version is still compatible with the current soci backend API. If anyone is using Firebird like me and wanna try v4.0, please report any issues so I/we can decide whether to use it in production or not. TIA. |