From boris at codesynthesis.com Fri Feb 1 08:14:01 2013 From: boris at codesynthesis.com (Boris Kolpackov) Date: Fri Feb 1 07:18:03 2013 Subject: [odb-users] another test from odb-tests-2.1.1 fails with mariadb-5.5.28a In-Reply-To: <20130131170823.5f6eaf595f56c34e12ef266d@zotac.lan> References: <20130130221547.49368ac5c90461cc4bb3cd53@zotac.lan> <20130131105654.d83ec01ec20162ac7532c7d2@zotac.lan> <20130131170823.5f6eaf595f56c34e12ef266d@zotac.lan> Message-ID: Hi Hugo, Hugo.Mildenberger@web.de writes: > Yes. After having included the fix you provided for the QString/utf8 issue, > the test suite completed successfully with MariaDB 5.1.66. Ok, so this seems to be MariaDB 5.5-specific. I just tried the tests with the latest MySQL (5.5.29), that is, using both MySQL 5.5.29 (as packaged by Debian) and libmysqlclient headers/libraries (as provided by Oracle). Everything works fine. So I tend to think this is either a MariaDB bug or a setup issue. Regarding the possible setup issue, one thing that might be worth checking is that you are using libmysqlclient from 5.5 as opposed to 5.1. Though for me everything works fine with both 5.5 and 5.1 clients. Boris From Hugo.Mildenberger at web.de Fri Feb 1 16:56:45 2013 From: Hugo.Mildenberger at web.de (Hugo.Mildenberger@web.de) Date: Fri Feb 1 16:40:06 2013 Subject: [odb-users] another test from odb-tests-2.1.1 fails with mariadb-5.5.28a In-Reply-To: References: <20130130221547.49368ac5c90461cc4bb3cd53@zotac.lan> <20130131105654.d83ec01ec20162ac7532c7d2@zotac.lan> <20130131170823.5f6eaf595f56c34e12ef266d@zotac.lan> Message-ID: <20130201225645.05b7ae808bec8fa3e513b688@zotac.lan> Hi Boris On Fri, 1 Feb 2013 15:14:01 +0200 Boris Kolpackov wrote: > Ok, so this seems to be MariaDB 5.5-specific. I just tried the tests > with the latest MySQL (5.5.29), that is, using both MySQL 5.5.29 (as > packaged by Debian) and libmysqlclient headers/libraries (as provided > by Oracle). Everything works fine. > > So I tend to think this is either a MariaDB bug or a setup issue. > Regarding the possible setup issue, one thing that might be worth > checking is that you are using libmysqlclient from 5.5 as opposed > to 5.1. Though for me everything works fine with both 5.5 and 5.1 > clients. That is one reason why I use a source code distribution. And no, the 'libmysqlclient.so' will get freshly installed each time. I also removed /var/lib/mysql, restarted the server and recompiled libodb-mysql when I changed mariadb versions. MySQL-5.5.29 runs fine here too, but MariaDB-5.5.2{8,9} do not. Here is an excerpt from a server side trace which looks interesting: 187 Execute INSERT INTO `boost_mysql_dt_object_times` (`object_id`,`index`,`value`) VALUES (1,0,'') 187 Reset stmt 187 Execute INSERT INTO `boost_mysql_dt_object_times` (`object_id`,`index`,`value`) VALUES (1,1,NULL) 187 Reset stmt 187 Execute INSERT INTO `boost_mysql_dt_object_times` (`object_id`,`index`,`value`) VALUES (1,2,'') 187 Reset stmt 187 Execute INSERT INTO `boost_mysql_dt_object_times` (`object_id`,`index`,`value`) VALUES (1,3,'') This fits with the output from a manual select: select * from boost_mysql_dt_object_times; +-----------+-------+---------------------+ | object_id | index | value | +-----------+-------+---------------------+ | 1 | 0 | 0000-00-00 00:00:00 | | 1 | 1 | NULL | | 1 | 2 | 0000-00-00 00:00:00 | | 1 | 3 | 0000-00-00 00:00:00 | +-----------+-------+---------------------+ Now, how to proceed? I finally persuaded libmysqlclient to create a trace file, but it did not contain anything useful. The trace flags are apparently only documented in the source code... what a mess. I tried MYSQL_DEBUG=d:t:o:f,/tmp/client4.trace, but I certainly missed just the significant one. As an aside, I had to set MYSQL_DEBUG in the driver script inside of func_exec_program_core(). Neither exporting MYSQL_DEBUG nor setting --debug= in ../../../db.options did work. Maybe you have an idea for a strategic place where to put trace statements. Hugo From jneuhart at tlirr.com Fri Feb 1 17:31:15 2013 From: jneuhart at tlirr.com (Jordan J. Neuhart) Date: Fri Feb 1 17:14:33 2013 Subject: [odb-users] Using ODB Qt Profile Library w/ Qt5 Message-ID: <681FA42AB546F84C8CFDFCAA6D89A62804061CD4@husker.tlirr.local> Greetings, Does anyone know how to get the Qt Profile library to work with Qt5 on windows? Right now, it won't build because the VC++ solution has a linker dependency for QtCore4.dll. Changing this to Qt5Core.dll seems to let the project build, but I'm not sure if there is more to be done. Thanks for any help, Jordan Neuhart Database Administrator Sofware Developer T-L Irrigation Co. P.O. Box 1047 151 East Hwy 6 & AB Road Hastings, NE 68902-1047 office: 402-462-4128 ext. 264 800-330-4264 ext. 264 cell: 402-217-1377 email: jjn@tlirr.com website: http://www.tlirr.com From davejohansen at gmail.com Sat Feb 2 15:07:41 2013 From: davejohansen at gmail.com (Dave Johansen) Date: Sat Feb 2 14:50:53 2013 Subject: [odb-users] No check for gmp.h in ./configure for odb Message-ID: I just started working on getting odb 2.1.1 built on CentOS 6 and I noticed that the ./configure didn't check for the existence of gmp.h and so it failed during the build process instead of the initial configure. From boris at codesynthesis.com Sun Feb 3 08:37:25 2013 From: boris at codesynthesis.com (Boris Kolpackov) Date: Sun Feb 3 07:40:57 2013 Subject: [odb-users] No check for gmp.h in ./configure for odb In-Reply-To: References: Message-ID: Hi Dave, Dave Johansen writes: > I just started working on getting odb 2.1.1 built on CentOS 6 and I noticed > that the ./configure didn't check for the existence of gmp.h and so it > failed during the build process instead of the initial configure. Hm, this is a tricky one. ODB itself doesn't use GMP. It is, however, required by the GCC plugin headers (for now). So under normal circumstances, it is safe to assume that if you have the GCC plugin headers installed then you also have GMP. If you install them from source, then GCC's configure will check for GMP. If you installed them as a package, then that package should have a dependency on GMP. So I am not sure we should check for GMP in ODB's configure. Did you install the plugin headers from the package? If so and it didn't prompt you to install GMP also, then I would say it is a missing dependency in the package and it would be a good idea to report it upstream. Boris From boris at codesynthesis.com Sun Feb 3 11:24:24 2013 From: boris at codesynthesis.com (Boris Kolpackov) Date: Sun Feb 3 10:27:56 2013 Subject: [odb-users] Using ODB Qt Profile Library w/ Qt5 In-Reply-To: <681FA42AB546F84C8CFDFCAA6D89A62804061CD4@husker.tlirr.local> References: <681FA42AB546F84C8CFDFCAA6D89A62804061CD4@husker.tlirr.local> Message-ID: Hi Jordan, Jordan J. Neuhart writes: > Does anyone know how to get the Qt Profile library to work with Qt5 on > windows? Right now, it won't build because the VC++ solution has a > linker dependency for QtCore4.dll. Changing this to Qt5Core.dll seems > to let the project build, but I'm not sure if there is more to be done. Good questions. To answer it I just ran all the test in the test suite against Qt5 and everything worked fine out of the box. So looks like all you need to do is change the linker dependency. We also plan to support Qt5 "officially" with the next release of ODB (coming out in a week or two). This will include a set of VC++ project/ solution files for Qt5 in addition to Qt4. Boris From davejohansen at gmail.com Sun Feb 3 17:27:42 2013 From: davejohansen at gmail.com (Dave Johansen) Date: Sun Feb 3 17:10:46 2013 Subject: [odb-users] No check for gmp.h in ./configure for odb In-Reply-To: References: Message-ID: On Sun, Feb 3, 2013 at 6:37 AM, Boris Kolpackov wrote: > Hi Dave, > > Dave Johansen writes: > > > I just started working on getting odb 2.1.1 built on CentOS 6 and I > noticed > > that the ./configure didn't check for the existence of gmp.h and so it > > failed during the build process instead of the initial configure. > > Hm, this is a tricky one. ODB itself doesn't use GMP. It is, however, > required by the GCC plugin headers (for now). So under normal > circumstances, it is safe to assume that if you have the GCC plugin > headers installed then you also have GMP. If you install them from > source, then GCC's configure will check for GMP. If you installed > them as a package, then that package should have a dependency on GMP. > So I am not sure we should check for GMP in ODB's configure. > > Did you install the plugin headers from the package? If so and it > didn't prompt you to install GMP also, then I would say it is a missing > dependency in the package and it would be a good idea to report it > upstream. > > Boris > Sounds good. I posted on the CentOS mailing list to see if this could be resolved upstream. The post can be found here: http://lists.centos.org/pipermail/centos-devel/2013-February/009017.html Thanks, Dave From jneuhart at tlirr.com Mon Feb 4 16:35:43 2013 From: jneuhart at tlirr.com (Jordan J. Neuhart) Date: Mon Feb 4 16:18:38 2013 Subject: [odb-users] Using ODB Qt Profile Library w/ Qt5 In-Reply-To: References: <681FA42AB546F84C8CFDFCAA6D89A62804061CD4@husker.tlirr.local> Message-ID: <681FA42AB546F84C8CFDFCAA6D89A62804061E35@husker.tlirr.local> Boris, Whenever I try to build and run the tests I get this error: c:\odb\libodb-qt-2.1.1\odb\qt\date-time\sqlite\qdate-traits.hxx(44): error C2039: 'fromAscii' : is not a member of 'QString' c:\qt\qt5.0.1\5.0.1\msvc2010\include\qtcore\qstring.h(208) : see declaration of 'QString' This is in Visual Studio, and I am using version 5.0.1 of Qt. Reading the Qt documentation, I see that QString::fromAscii has been deprecated. Has this been fixed in newer builds of ODB? Thanks, Jordan Neuhart -----Original Message----- From: Boris Kolpackov [mailto:boris@codesynthesis.com] Sent: Sunday, February 03, 2013 10:24 AM To: Jordan J. Neuhart Cc: odb-users@codesynthesis.com Subject: Re: [odb-users] Using ODB Qt Profile Library w/ Qt5 Hi Jordan, Jordan J. Neuhart writes: > Does anyone know how to get the Qt Profile library to work with Qt5 on > windows? Right now, it won't build because the VC++ solution has a > linker dependency for QtCore4.dll. Changing this to Qt5Core.dll seems > to let the project build, but I'm not sure if there is more to be done. Good questions. To answer it I just ran all the test in the test suite against Qt5 and everything worked fine out of the box. So looks like all you need to do is change the linker dependency. We also plan to support Qt5 "officially" with the next release of ODB (coming out in a week or two). This will include a set of VC++ project/ solution files for Qt5 in addition to Qt4. Boris From davejohansen at gmail.com Tue Feb 5 00:43:56 2013 From: davejohansen at gmail.com (Dave Johansen) Date: Tue Feb 5 00:26:49 2013 Subject: [odb-users] sqlite test failure on CentOS 6 Message-ID: I just built libodb-sqlite-2.1.1 on CentOS and ran the tests and one of the tests failed. When doing the configure, I got the following warning: configure: WARNING: libsqlite3 is built without sqlite3_unlock_notify support; multi-threaded support will be limited And then when running the test common/threads, it printed "database operation timeout" a bunch and then failed. What can I do to help diagnose the issue further? Thanks, Dave From Hugo.Mildenberger at web.de Tue Feb 5 06:02:04 2013 From: Hugo.Mildenberger at web.de (Hugo.Mildenberger@web.de) Date: Tue Feb 5 05:44:58 2013 Subject: [odb-users] sqlite test failure on CentOS 6 In-Reply-To: References: Message-ID: <20130205120204.5514bf8e9df0e79f2a1e28da@zotac.lan> Dave Johansen wrote: > I just built libodb-sqlite-2.1.1 on CentOS and ran the tests and one of the > tests failed. When doing the configure, I got the following warning: > configure: WARNING: libsqlite3 is built without sqlite3_unlock_notify > support; multi-threaded support will be limited > > And then when running the test common/threads, it printed "database > operation timeout" a bunch and then failed. What can I do to help diagnose > the issue further? Dave, the sqlite package had to be compiled with -DSQLITE_ENABLE_UNLOCK_NOTIFY in CPPFLAGS. Perhaps CentOS offers another sqlite package which supports unlock notify? From boris at codesynthesis.com Tue Feb 5 09:06:40 2013 From: boris at codesynthesis.com (Boris Kolpackov) Date: Tue Feb 5 08:10:14 2013 Subject: [odb-users] another test from odb-tests-2.1.1 fails with mariadb-5.5.28a In-Reply-To: <20130201225645.05b7ae808bec8fa3e513b688@zotac.lan> References: <20130130221547.49368ac5c90461cc4bb3cd53@zotac.lan> <20130131105654.d83ec01ec20162ac7532c7d2@zotac.lan> <20130131170823.5f6eaf595f56c34e12ef266d@zotac.lan> <20130201225645.05b7ae808bec8fa3e513b688@zotac.lan> Message-ID: Hi Hugo, I reviewed the code involved one more time and I might have found something that could cause this. Can you try these patches and let me know if they help? Boost: http://scm.codesynthesis.com/?p=odb/libodb-boost.git;a=patch;h=fa7c954409d6fa27440d965797f14c6c01397aee Qt: http://scm.codesynthesis.com/?p=odb/libodb-qt.git;a=patch;h=4503191a037be58e769613281f90efa5310e547e If that doesn't help, then I will try to create a minimal test using the C API that reproduces this issue. Boris From boris at codesynthesis.com Tue Feb 5 09:25:19 2013 From: boris at codesynthesis.com (Boris Kolpackov) Date: Tue Feb 5 08:28:53 2013 Subject: [odb-users] sqlite test failure on CentOS 6 In-Reply-To: References: Message-ID: Hi Dave, Dave Johansen writes: > I just built libodb-sqlite-2.1.1 on CentOS and ran the tests and one of the > tests failed. When doing the configure, I got the following warning: > configure: WARNING: libsqlite3 is built without sqlite3_unlock_notify > support; multi-threaded support will be limited > > And then when running the test common/threads, it printed "database > operation timeout" a bunch and then failed. As Hugo mentioned in his reply, ODB needs the SQLite unlock notification functionality to support multi-threaded database access. Without this support the 'threads' test in the test suite will fail. These days most recent distributions already build SQLite with unlock notify enabled by default (I've heard it is required by Mozilla, among other projects). I guess CentOS 6 hasn't switched yet. I see two ways to resolve the test failure: 1. Find libsqlite3 that has unlock notify enabled. As Hugo suggested, maybe there is an alternative/updated package. 2. If all else fails, you can disable the 'threads' test by passing the --disable-threads configure option to the test suite. Boris From boris at codesynthesis.com Tue Feb 5 10:18:50 2013 From: boris at codesynthesis.com (Boris Kolpackov) Date: Tue Feb 5 09:22:23 2013 Subject: [odb-users] Using ODB Qt Profile Library w/ Qt5 In-Reply-To: <681FA42AB546F84C8CFDFCAA6D89A62804061E35@husker.tlirr.local> References: <681FA42AB546F84C8CFDFCAA6D89A62804061CD4@husker.tlirr.local> <681FA42AB546F84C8CFDFCAA6D89A62804061E35@husker.tlirr.local> Message-ID: Hi Jordan, Jordan J. Neuhart writes: > Whenever I try to build and run the tests I get this error: > > c:\odb\libodb-qt-2.1.1\odb\qt\date-time\sqlite\qdate-traits.hxx(44): > error C2039: 'fromAscii' : is not a member of 'QString' Strange, I am using 5.0.0 and I had to explicitly disable the deprecated API with the QT_DISABLE_DEPRECATED_BEFORE to reproduce this. In any case, I've fixed this for the next release. You can either apply the patch: http://scm.codesynthesis.com/?p=odb/libodb-qt.git;a=patch;h=45611484324c284701d1fb6b5873ed4a05f0535b Or you can simply replace all the fromAscii() calls with fromLatin1(). Boris From davejohansen at gmail.com Tue Feb 5 10:22:00 2013 From: davejohansen at gmail.com (Dave Johansen) Date: Tue Feb 5 10:04:51 2013 Subject: [odb-users] sqlite test failure on CentOS 6 In-Reply-To: References: Message-ID: On Tue, Feb 5, 2013 at 7:25 AM, Boris Kolpackov wrote: > > Hi Dave, > > Dave Johansen writes: > > > I just built libodb-sqlite-2.1.1 on CentOS and ran the tests and one of > > the > > tests failed. When doing the configure, I got the following warning: > > configure: WARNING: libsqlite3 is built without sqlite3_unlock_notify > > support; multi-threaded support will be limited > > > > And then when running the test common/threads, it printed "database > > operation timeout" a bunch and then failed. > > As Hugo mentioned in his reply, ODB needs the SQLite unlock notification > functionality to support multi-threaded database access. Without this > support the 'threads' test in the test suite will fail. > > These days most recent distributions already build SQLite with unlock > notify enabled by default (I've heard it is required by Mozilla, among > other projects). I guess CentOS 6 hasn't switched yet. I see two ways > to resolve the test failure: > > 1. Find libsqlite3 that has unlock notify enabled. As Hugo suggested, > maybe there is an alternative/updated package. > > 2. If all else fails, you can disable the 'threads' test by passing > the --disable-threads configure option to the test suite. There doesn't appear to be an alternate package in the CentOS or EPEL repos. There's one in Atomic ( http://pkgs.org/centos-6-rhel-6/atomic-i386/sqlite-3.7.9-1.el6.art.i686.rpm.html ), but I'm not sure if it has the appropriate build flags set or not. For now, I'll just run the tests with --disable-threads since I won't be using multi-threaded database access. Thanks, Dave From jneuhart at tlirr.com Tue Feb 5 11:11:22 2013 From: jneuhart at tlirr.com (Jordan J. Neuhart) Date: Tue Feb 5 10:54:12 2013 Subject: [odb-users] Using ODB Qt Profile Library w/ Qt5 In-Reply-To: References: <681FA42AB546F84C8CFDFCAA6D89A62804061CD4@husker.tlirr.local> <681FA42AB546F84C8CFDFCAA6D89A62804061E35@husker.tlirr.local> Message-ID: <681FA42AB546F84C8CFDFCAA6D89A62804061EE1@husker.tlirr.local> Boris, Thanks, for the patch. I had already gone through and replaced the calls yesterday, and it seems to work ok. Thanks, Jordan Neuhart -----Original Message----- From: Boris Kolpackov [mailto:boris@codesynthesis.com] Sent: Tuesday, February 05, 2013 9:19 AM To: Jordan J. Neuhart Cc: odb-users@codesynthesis.com Subject: Re: [odb-users] Using ODB Qt Profile Library w/ Qt5 Hi Jordan, Jordan J. Neuhart writes: > Whenever I try to build and run the tests I get this error: > > c:\odb\libodb-qt-2.1.1\odb\qt\date-time\sqlite\qdate-traits.hxx(44): > error C2039: 'fromAscii' : is not a member of 'QString' Strange, I am using 5.0.0 and I had to explicitly disable the deprecated API with the QT_DISABLE_DEPRECATED_BEFORE to reproduce this. In any case, I've fixed this for the next release. You can either apply the patch: http://scm.codesynthesis.com/?p=odb/libodb-qt.git;a=patch;h=45611484324c 284701d1fb6b5873ed4a05f0535b Or you can simply replace all the fromAscii() calls with fromLatin1(). Boris From Hugo.Mildenberger at web.de Tue Feb 5 12:37:44 2013 From: Hugo.Mildenberger at web.de (Hugo.Mildenberger@web.de) Date: Tue Feb 5 12:20:35 2013 Subject: [odb-users] another test from odb-tests-2.1.1 fails with mariadb-5.5.28a In-Reply-To: References: <20130130221547.49368ac5c90461cc4bb3cd53@zotac.lan> <20130131105654.d83ec01ec20162ac7532c7d2@zotac.lan> <20130131170823.5f6eaf595f56c34e12ef266d@zotac.lan> <20130201225645.05b7ae808bec8fa3e513b688@zotac.lan> Message-ID: <20130205183744.93347ad9f2b3b4906ef0c11c@zotac.lan> Boris Kolpackov wrote: > I reviewed the code involved one more time and I might have found > something that could cause this. Can you try these patches and > let me know if they help? > > Boost: http://scm.codesynthesis.com/?p=odb/libodb-boost.git;a=patch;h=fa7c954409d6fa27440d965797f14c6c01397aee > Qt: http://scm.codesynthesis.com/?p=odb/libodb-qt.git;a=patch;h=4503191a037be58e769613281f90efa5310e547e > > If that doesn't help, then I will try to create a minimal test using > the C API that reproduces this issue. Well, apparently the patch set fixed it. I say apparently because I'm not completely sure about it, in turn because some Gentoo maintainers sometimes smuggle in small patches without bumping the ebuild revision number. When reinstalling a package, a new patch set can be loaded from a remote server in the background. I haven't yet checked all the details here, but I've reinstalled MariaDB-5.5.28a. A minimal test case would be useful for a upstream bug report anyway. This error did also not occur when using the new MariaDB native client without yet having applied this patch set. By the way, I've observed that within the structure "st_mysql_time" the field "time_type" is also not initialized by odb. Although the documentation officially states that callers of mysql_stmt_bind_param may leave this field unassigned, one can not know if all developers who eventually become involved will remember this statement. But now comes the next failed test (with mmariadb-5.5.28a): make[2]: Entering directory `/var/tmp/portage/dev-db/odb-2.1.1/work/ odb-tests-2.1.1-mysql/mysql/truncation' ./driver --options-file ../../db.options driver: driver.cxx:78: int main(int, char**): Assertion `o->str_ == long_str' failed. ./../../tester: line 39: 8281 Aborted (core dumped) ./driver --options-file "$top_builddir/ db.options" > test.out FAIL: ../../tester ============================================ 1 of 1 test failed Please report to odb-users@codesynthesis.com ============================================ make[2]: *** [check-TESTS] Fehler 1 make[2]: Leaving directory `/var/tmp/portage/dev-db/odb-2.1.1/work/odb-tests-2.1.1-mysql/mysql/truncation' As far as I remember, exactly this error previously also happened with the MariaDB native client. I've now put a trace statement in driver.cxx, just before the assertion: o->str_:'cccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccc cccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccc cccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccc ccccQp???@E?6' long_str:'cccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccc ccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccc ccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccc cccccccccccccccccccccccccccccccccccccccccccccc' The wrong part starts after offset 0+256. When changing the length of long_str from 300 to 256, this subtest runs ok. Setting length to 257, the test again fails. When having commented out this subtest, the assertion (o->str_ == longer_str) failed, and after that (p->vec_ == o.vec_) did not evaluate to true. Kind regards Hugo From Hugo.Mildenberger at web.de Wed Feb 6 04:51:47 2013 From: Hugo.Mildenberger at web.de (Hugo.Mildenberger@web.de) Date: Wed Feb 6 04:34:34 2013 Subject: [odb-users] another test from odb-tests-2.1.1 fails with mariadb-5.5.28a In-Reply-To: <20130205183744.93347ad9f2b3b4906ef0c11c@zotac.lan> References: <20130130221547.49368ac5c90461cc4bb3cd53@zotac.lan> <20130131105654.d83ec01ec20162ac7532c7d2@zotac.lan> <20130131170823.5f6eaf595f56c34e12ef266d@zotac.lan> <20130201225645.05b7ae808bec8fa3e513b688@zotac.lan> <20130205183744.93347ad9f2b3b4906ef0c11c@zotac.lan> Message-ID: <20130206105147.4bf647e1bc9a16e991bb85e1@zotac.lan> Hugo.Mildenberger@web.de wrote: > Well, apparently the patch set fixed it. I'm sorry, but this result was a false positive. The patch set actually does not fix the MariaDB problem. After a system reboot the original error reappeared, affecting both tests in boost/mysql/date-time and qt/mysql/date-time. The fix (and other symptoms) were obviously caused by the MariaDB native client library which somehow survived it's deletion. Except for a caching issue I have no idea why this happened. From boris at codesynthesis.com Wed Feb 6 07:30:08 2013 From: boris at codesynthesis.com (Boris Kolpackov) Date: Wed Feb 6 06:33:43 2013 Subject: [odb-users] another test from odb-tests-2.1.1 fails with mariadb-5.5.28a In-Reply-To: <20130205183744.93347ad9f2b3b4906ef0c11c@zotac.lan> References: <20130130221547.49368ac5c90461cc4bb3cd53@zotac.lan> <20130131105654.d83ec01ec20162ac7532c7d2@zotac.lan> <20130131170823.5f6eaf595f56c34e12ef266d@zotac.lan> <20130201225645.05b7ae808bec8fa3e513b688@zotac.lan> <20130205183744.93347ad9f2b3b4906ef0c11c@zotac.lan> Message-ID: Hi Hugo, Hugo.Mildenberger@web.de writes: > A minimal test case would be useful for a upstream bug report anyway. The test case is attached. > This error did also not occur when using the new MariaDB native client > without yet having applied this patch set. Ah, I didn't realize they re-implemented the client library. That would explain all the test failures. > By the way, I've observed that within the structure "st_mysql_time" the > field "time_type" is also not initialized by odb. Although the > documentation officially states that callers of mysql_stmt_bind_param > may leave this field unassigned, one can not know if all developers > who eventually become involved will remember this statement. Where do you see this? The only documentation for MYSQL_TIME that I know is here: http://dev.mysql.com/doc/refman/5.5/en/c-api-prepared-statement-data-structures.html And it doesn't say anything about time_type (nor st_mysql_time, for that matter). > But now comes the next failed test (with mmariadb-5.5.28a): While I sympathize with MariaDB efforts, I am afraid I don't have the time to help them debug their new client library. Re-creating ODB functionality test cases using the C API is a very tedious process. They are, however, welcome to use ODB themselves for testing their code. Boris From Hugo.Mildenberger at web.de Wed Feb 6 09:01:00 2013 From: Hugo.Mildenberger at web.de (Hugo.Mildenberger@web.de) Date: Wed Feb 6 08:43:46 2013 Subject: [odb-users] another test from odb-tests-2.1.1 fails with mariadb-5.5.28a In-Reply-To: References: <20130130221547.49368ac5c90461cc4bb3cd53@zotac.lan> <20130131105654.d83ec01ec20162ac7532c7d2@zotac.lan> <20130131170823.5f6eaf595f56c34e12ef266d@zotac.lan> <20130201225645.05b7ae808bec8fa3e513b688@zotac.lan> <20130205183744.93347ad9f2b3b4906ef0c11c@zotac.lan> Message-ID: <20130206150100.ae5600a4305c75c5320abed9@zotac.lan> Hi Boris Boris Kolpackov wrote: > > A minimal test case would be useful for a upstream bug report anyway. > > The test case is attached. I did not receive any attachment. > Ah, I didn't realize they re-implemented the client library. That would > explain all the test failures. No. Your post regarding this issue overlapped with an intermediate post I sent when I discovered what happened. In case it did not reach you, here it is again: I'm sorry, but this result was a false positive. The patch set actually does not fix the MariaDB problem. After a system reboot the original error reappeared, affecting both tests in boost/mysql/date-time and qt/mysql/date-time. The fix (and other symptoms) were obviously caused by the MariaDB native client library which somehow survived it's deletion. Except for a caching issue I have no idea why this happened. The native client is a separate project. I used the bzr development version in a hitherto fruitless attempt to isolate the reason for the datetime issue. And tried that only days after I had sent the first report regarding the datetime issue to the odb mailing list. > > By the way, I've observed that within the structure "st_mysql_time" the > > field "time_type" is also not initialized by odb. Although the > > documentation officially states that callers of mysql_stmt_bind_param > > may leave this field unassigned, one can not know if all developers > > who eventually become involved will remember this statement. > > Where do you see this? The only documentation for MYSQL_TIME that I > know is here: > > http://dev.mysql.com/doc/refman/5.5/en/c-api-prepared-statement-data-structures.html > > And it doesn't say anything about time_type (nor st_mysql_time, for > that matter). I also can't find it for the moment. Maybe it was from sources ? mariadb-5.5.28a/mariadb-5.5.28a/libmysql.c: 2740 Binding dates and times. 2741 For binding dates and times prepared statements API provides 2742 clients with MYSQL_TIME structure. A pointer to instance of this 2743 structure should be assigned to MYSQL_BIND::buffer whenever 2744 MYSQL_TYPE_TIME, MYSQL_TYPE_DATE, MYSQL_TYPE_DATETIME typecodes 2745 are used. When typecode is MYSQL_TYPE_TIME, only members 2746 'hour', 'minute', 'second' and 'neg' (is time offset negative) 2747 are used. These members only will be sent to the server. 2748 MYSQL_TYPE_DATE implies use of 'year', 'month', 'day', 'neg'. 2749 MYSQL_TYPE_DATETIME utilizes both parts of MYSQL_TIME structure. 2750 You don't have to set MYSQL_TIME::time_type member: it's not 2751 used when sending data to the server, typecode information is 2752 enough. 'second_part' member can hold microsecond precision of 2753 time value, but now it's only supported on protocol level: you 2754 can't store microsecond in a column, or use in temporal 2755 calculations. However, if you send a time value with microsecond 2756 part for 'SELECT ?', statement, you'll get it back unchanged 2757 from the server. 2758 2759 Data conversion. 2760 If conversion from host language type to data representation, 2761 corresponding to SQL type, is required it's done on the server. 2762 Data truncation is possible when conversion is lossy. For 2763 example, if you supply MYSQL_TYPE_DATETIME value out of valid 2764 SQL type TIMESTAMP range, the same conversion will be applied as 2765 if this value would have been sent as string in the old 2766 protocol. TODO: document how the server will behave in case of 2767 truncation/data loss. Hugo From boris at codesynthesis.com Wed Feb 6 10:42:19 2013 From: boris at codesynthesis.com (Boris Kolpackov) Date: Wed Feb 6 09:45:55 2013 Subject: [odb-users] another test from odb-tests-2.1.1 fails with mariadb-5.5.28a In-Reply-To: <20130206150100.ae5600a4305c75c5320abed9@zotac.lan> References: <20130130221547.49368ac5c90461cc4bb3cd53@zotac.lan> <20130131105654.d83ec01ec20162ac7532c7d2@zotac.lan> <20130131170823.5f6eaf595f56c34e12ef266d@zotac.lan> <20130201225645.05b7ae808bec8fa3e513b688@zotac.lan> <20130205183744.93347ad9f2b3b4906ef0c11c@zotac.lan> <20130206150100.ae5600a4305c75c5320abed9@zotac.lan> Message-ID: Hi Hugo, Hugo.Mildenberger@web.de writes: > I did not receive any attachment. Sorry, here it is. > The native client is a separate project. [...] I got your second email and realize the patch didn't fix anything. I am still confused whether you were using MariaDB native client (which, as I understand, is a re-implementation of the MySQL client library) or you used the standard MySQL client library, or maybe both. I am also not clear whether the tests fail with the native client, standard client, both, or some versions of the native client (I remember reading that a newer version of something fixed something). As you can see, I am quite confused... ;-) BTW, regarding that second test failure, it looks like a memory overrun and in such cases valgrind can be really helpful. Boris From boris at codesynthesis.com Wed Feb 6 10:45:24 2013 From: boris at codesynthesis.com (Boris Kolpackov) Date: Wed Feb 6 09:48:59 2013 Subject: [odb-users] another test from odb-tests-2.1.1 fails with mariadb-5.5.28a In-Reply-To: References: <20130131105654.d83ec01ec20162ac7532c7d2@zotac.lan> <20130131170823.5f6eaf595f56c34e12ef266d@zotac.lan> <20130201225645.05b7ae808bec8fa3e513b688@zotac.lan> <20130205183744.93347ad9f2b3b4906ef0c11c@zotac.lan> <20130206150100.ae5600a4305c75c5320abed9@zotac.lan> Message-ID: Boris Kolpackov writes: > Hugo.Mildenberger@web.de writes: > > > I did not receive any attachment. > > Sorry, here it is. Arrr... http://codesynthesis.com/~boris/tmp/odb/mysql-test.cxx Boris From uwe_kindler at web.de Wed Feb 6 15:08:36 2013 From: uwe_kindler at web.de (Uwe Kindler) Date: Thu Feb 7 04:41:59 2013 Subject: [odb-users] libodb-1.2.0 build with MinGW GCC4.7.2 fails Message-ID: <5112B844.1060007@web.de> Hi Boris, we are currently in the process of preparing the transition from Qt4 to Qt5 for our internal projects - so I'm really glad to read that full Qt5 support is planned for the next releases. As part of the transation we move from our MinGW GCC 4.6.2 compiler to the MinGW GCC 4.7.2 compiler that is provided as part of the Qt5.0.1 installation here: http://releases.qt-project.org/qt5/5.0.1/qt-windows-opensource-5.0.1-mingw47_32-x86-offline.exe Unfortunately the libodb-1.2.0 build fails during the final linking step with an error message: ../libtool: eval: line 7867: unexpected EOF while looking for matching `'' ../libtool: eval: line 7868: syntax error: unexpected end of file I uploaded the complete configure and make output to pastebin: http://pastebin.com/3qZVruxb Using the old MinGW GCC 4.6.2 compiler in the same environment works without problems. Do you have any idea what the error message could mean? Thank you and kind regards, Uwe From vsokolov at anl.gov Wed Feb 6 18:27:52 2013 From: vsokolov at anl.gov (Sokolov, Vadim O.) Date: Thu Feb 7 04:42:03 2013 Subject: [odb-users] schema_catalog Message-ID: <143C78680FCC2F4196592087ACC3AB44231666@BUTKUS.anl.gov> I am using names schemas in my application and at run time, I would like to know what schemas are defined in schema_catalog. Is there is a way to do it? Thank you, Vadim From boris at codesynthesis.com Thu Feb 7 05:58:40 2013 From: boris at codesynthesis.com (Boris Kolpackov) Date: Thu Feb 7 05:02:17 2013 Subject: [odb-users] libodb-1.2.0 build with MinGW GCC4.7.2 fails In-Reply-To: <5112B844.1060007@web.de> References: <5112B844.1060007@web.de> Message-ID: Hi Uwe, Uwe Kindler writes: > Unfortunately the libodb-1.2.0 build fails during the final linking step > with an error message: > > ../libtool: eval: line 7867: unexpected EOF while looking for matching `'' > ../libtool: eval: line 7868: syntax error: unexpected end of file I looked at the output and it is very strange. It appears that there is a stray "'" in "-L/temp/x32-4.7.2-posix-sjlj-r8/prefix/opt/lib'" that causes the problem. I am not sure whether GCC was configured with this path or if it is libtool that somehow added it. Can you run this command and paste its output: g++ -v hello.cxx Thanks, Boris From Hugo.Mildenberger at web.de Thu Feb 7 06:10:48 2013 From: Hugo.Mildenberger at web.de (Hugo.Mildenberger@web.de) Date: Thu Feb 7 05:53:27 2013 Subject: [odb-users] another test from odb-tests-2.1.1 fails with mariadb-5.5.28a In-Reply-To: References: <20130130221547.49368ac5c90461cc4bb3cd53@zotac.lan> <20130131105654.d83ec01ec20162ac7532c7d2@zotac.lan> <20130131170823.5f6eaf595f56c34e12ef266d@zotac.lan> <20130201225645.05b7ae808bec8fa3e513b688@zotac.lan> <20130205183744.93347ad9f2b3b4906ef0c11c@zotac.lan> <20130206150100.ae5600a4305c75c5320abed9@zotac.lan> Message-ID: <20130207121048.e00e241511b74352f5265487@zotac.lan> Hi Boris, Boris Kolpackov wrote: > I got your second email and realize the patch didn't fix anything. > I am still confused whether you were using MariaDB native client > (which, as I understand, is a re-implementation of the MySQL > client library) or you used the standard MySQL client library, or > maybe both. I am also not clear whether the tests fail with the > native client, standard client, both, or some versions of the > native client (I remember reading that a newer version of > something fixed something). As you can see, I am quite > confused... ;-) I'm sorry. I was myself quite confused about the many things that what went astray. But I'm now again really using libmysqlclient.so.18.0.0 which comes with mariadb-5.5.28a. By the way, I missed the functionality to track the values passed to mysql_stmt_bind_param(). The odb tracer classes were not of much help with prepared statements. But now, after having implanted a tracer into libmysql.c instead, I observed that the odb-test suite passed strange values for the "second_part" field of MYSQL_TIME. This field is defined to represent microseconds: [+] 2013-02-07 11:25:10 7020097254353692004; libmysql.c +2050 in net_store_datetime() 7020097254353692004 * 1E-6 seconds / 3600 / 24 / 365 = 222 605.8 years Previously, in accordance with the MySQL documentation, this field was unused. Now MariaDB obviously attempts to normalize the date/time value. Using gdb, it is very difficult to follow all the conversions going on between template code fragments. But commenting out all tests except localtime finally showed that the culprit is o.times.push_back (second_clock::local_time ()); Possibly this is not the only problematic conversion. I also noted that the huge microsecond value remained constant across several tests, hence it can not be derived from system time. Hugo From neembi at gmail.com Thu Feb 7 06:05:26 2013 From: neembi at gmail.com (Ben Morgan) Date: Thu Feb 7 06:31:26 2013 Subject: [odb-users] Cannot suppress inline file creation Message-ID: This is a bug report. *ODB object-relation mapping (ORM) compiler for C++ 2.1.1* In the ODB 2.1.0 Compiler Manualit says For an input file in the form name.hxx (other file extensions can be used instead of .hxx), the following C++ files are generated: name-odb.hxx(header file), name-odb.ixx (inline file, generated unless the --suppress-inline option is specified), and name-odb.cxx (source file). If I try to use that option, I get an error unknown option '--suppress-inline' and the inline file is created anyway. Is this option removed in versions > 2.1.0, or is it fixed in 2.2.0? Thanks! Ben From boris at codesynthesis.com Thu Feb 7 07:45:14 2013 From: boris at codesynthesis.com (Boris Kolpackov) Date: Thu Feb 7 06:48:55 2013 Subject: [odb-users] another test from odb-tests-2.1.1 fails with mariadb-5.5.28a In-Reply-To: <20130207121048.e00e241511b74352f5265487@zotac.lan> References: <20130131170823.5f6eaf595f56c34e12ef266d@zotac.lan> <20130201225645.05b7ae808bec8fa3e513b688@zotac.lan> <20130205183744.93347ad9f2b3b4906ef0c11c@zotac.lan> <20130206150100.ae5600a4305c75c5320abed9@zotac.lan> <20130207121048.e00e241511b74352f5265487@zotac.lan> Message-ID: Hi Hugo, Hugo.Mildenberger@web.de writes: > By the way, I missed the functionality to track the values passed to > mysql_stmt_bind_param(). The odb tracer classes were not of much help > with prepared statements. The main purpose of the tracer API is to see which statements are executed. I agree it would be nice to also see the values being passed, but that would be non-trivial to implement and also slow things down significantly. > But now, after having implanted a tracer into libmysql.c instead, I > observed that the odb-test suite passed strange values for the > "second_part" field of MYSQL_TIME. > > [...] > > Previously, in accordance with the MySQL documentation, this field was > unused. Now MariaDB obviously attempts to normalize the date/time value. Actually it is "currently unused", not "previously unused", according to the MySQL 5.5 docs. So it seems it is now used in MariaDB without any documentation to this effect. In any case, I've updated ODB to always initialize every single (documented) member in MYSQL_TIME. Below are the patches. Can you try them and verify that this fixes the issue? http://scm.codesynthesis.com/?p=odb/libodb-qt.git;a=patch;h=ab5046438ca91ed7659e3f2bcc13235bc311ad32 http://scm.codesynthesis.com/?p=odb/libodb-boost.git;a=patch;h=23419030f7fa4cc96d0a086a6af87e7ef2e2ed18 Thanks for tracking this down! Boris From boris at codesynthesis.com Thu Feb 7 07:52:26 2013 From: boris at codesynthesis.com (Boris Kolpackov) Date: Thu Feb 7 06:56:01 2013 Subject: [odb-users] Cannot suppress inline file creation In-Reply-To: References: Message-ID: Hi Ben, Ben Morgan writes: > For an input file in the form name.hxx (other file extensions can be used > instead of .hxx), the following C++ files are generated: > name-odb.hxx(header file), > name-odb.ixx (inline file, generated unless the --suppress-inline option is > specified), and name-odb.cxx (source file). > > If I try to use that option, I get an error > > unknown option '--suppress-inline' Yes, it is something we have already documented but not implemented (yet). You don't see that often, do you ;-)? It won't be difficult to support it in the upcoming 2.2.0, but I am wondering why you want to suppress the inline function? You are the first person asking for this since the ODB's first release... Boris From boris at codesynthesis.com Thu Feb 7 07:58:05 2013 From: boris at codesynthesis.com (Boris Kolpackov) Date: Thu Feb 7 07:01:42 2013 Subject: [odb-users] schema_catalog In-Reply-To: <143C78680FCC2F4196592087ACC3AB44231666@BUTKUS.anl.gov> References: <143C78680FCC2F4196592087ACC3AB44231666@BUTKUS.anl.gov> Message-ID: Hi Vadim. Sokolov, Vadim O. writes: > I am using names schemas in my application and at run time, I would > like to know what schemas are defined in schema_catalog. Is there is > a way to do it? No, not currently. While we can add this support, I am wondering what's the use case? Is it something to do with dynamic loading of the database support code (i.e., this way you can detect which components have been loaded)? Boris From Hugo.Mildenberger at web.de Thu Feb 7 08:26:06 2013 From: Hugo.Mildenberger at web.de (Hugo.Mildenberger@web.de) Date: Thu Feb 7 08:08:44 2013 Subject: [odb-users] another test from odb-tests-2.1.1 fails with mariadb-5.5.28a In-Reply-To: References: <20130131170823.5f6eaf595f56c34e12ef266d@zotac.lan> <20130201225645.05b7ae808bec8fa3e513b688@zotac.lan> <20130205183744.93347ad9f2b3b4906ef0c11c@zotac.lan> <20130206150100.ae5600a4305c75c5320abed9@zotac.lan> <20130207121048.e00e241511b74352f5265487@zotac.lan> Message-ID: <20130207142606.b8447afb8ef2e16c4cb561ed@zotac.lan> Hi Boris, Boris Kolpackov wrote: > In any case, I've updated ODB to always initialize every single > (documented) member in MYSQL_TIME. Below are the patches. Can you > try them and verify that this fixes the issue? All tests passed (including examples), with support for Boost and Qt being active. Hugo From neembi at gmail.com Thu Feb 7 08:05:31 2013 From: neembi at gmail.com (Ben Morgan) Date: Thu Feb 7 09:47:56 2013 Subject: [odb-users] Cannot suppress inline file creation In-Reply-To: References: Message-ID: Thanks for the quick response! On Thu, Feb 7, 2013 at 1:52 PM, Boris Kolpackov wrote: > It won't be difficult to support it in the upcoming 2.2.0, but I am > wondering why you want to suppress the inline function? You are the > first person asking for this since the ODB's first release... Well... perhaps I am doing something very unnatural... I'm trying to make a library that a number of programs will use to access a database. So I go for this structure: include/mylib datatype_headers.hpp ... odb/ datatype_headers.hxx So the idea is to be able to have other programs be able to include and if needed . But datatype.hxx needs to refer to datatype.hpp, soo I use --include-prefix, but then at the bottom there is also #include "../datatype.ixx", which is in the same directory though! (I solved this problem now by using --include-regex). If you think my naming/structure is bad, please tell me. This is only my second serious library (attempt). I had to hack enough with "--ixx-suffix ixx and --odb-file-suffix .", etc. to get it as is - which almost suggests that I'm doing something wrong... Ben From neembi at gmail.com Thu Feb 7 08:40:29 2013 From: neembi at gmail.com (Ben Morgan) Date: Thu Feb 7 09:47:56 2013 Subject: [odb-users] unsigned long long not in C++98 standard Message-ID: Another bug report, I think... >From the current Manual Section 3.11: The erase_query() function has the following overloaded versions: template unsigned long long erase_query (); template unsigned long long erase_query (const odb::query&); However, this makes it not support C++98 correctly anymore [1]. Example: Compile any header like so: odb -d pgsql -q --std c++98 myheader.hxx and then with GCC: gcc -Wall -Wextra -Werror -std=c++98 myheader-odb.cxx and you get an error: error: ISO C++ 1998 does not support 'long long' [-Werror=long-long] Is this an intentional deviation? Thanks! Ben 1: See for example: http://david.tribble.com/text/cdiffs.htm From uwe_kindler at web.de Thu Feb 7 09:23:21 2013 From: uwe_kindler at web.de (Uwe Kindler) Date: Thu Feb 7 09:47:56 2013 Subject: [odb-users] libodb-1.2.0 build with MinGW GCC4.7.2 fails In-Reply-To: References: <5112B844.1060007@web.de> Message-ID: <5113B8D9.1010205@web.de> Hi Boris, > Hi Uwe, > > Uwe Kindler writes: > >> Unfortunately the libodb-1.2.0 build fails during the final linking step >> with an error message: >> >> ../libtool: eval: line 7867: unexpected EOF while looking for matching `'' >> ../libtool: eval: line 7868: syntax error: unexpected end of file > > I looked at the output and it is very strange. It appears that there is > a stray "'" in "-L/temp/x32-4.7.2-posix-sjlj-r8/prefix/opt/lib'" that > causes the problem. I am not sure whether GCC was configured with this > path or if it is libtool that somehow added it. Can you run this command > and paste its output: > > g++ -v hello.cxx > > Thanks, > Boris > I pasted the output here: http://pastebin.com/JNHpGhHa Uwe From boris at codesynthesis.com Thu Feb 7 10:57:20 2013 From: boris at codesynthesis.com (Boris Kolpackov) Date: Thu Feb 7 10:00:55 2013 Subject: [odb-users] another test from odb-tests-2.1.1 fails with mariadb-5.5.28a In-Reply-To: <20130207142606.b8447afb8ef2e16c4cb561ed@zotac.lan> References: <20130201225645.05b7ae808bec8fa3e513b688@zotac.lan> <20130205183744.93347ad9f2b3b4906ef0c11c@zotac.lan> <20130206150100.ae5600a4305c75c5320abed9@zotac.lan> <20130207121048.e00e241511b74352f5265487@zotac.lan> <20130207142606.b8447afb8ef2e16c4cb561ed@zotac.lan> Message-ID: Hi Hugo, Hugo.Mildenberger@web.de writes: > All tests passed (including examples), with support for Boost and Qt > being active. That's great news! Thanks for figuring this all out. Boris From boris at codesynthesis.com Thu Feb 7 11:10:26 2013 From: boris at codesynthesis.com (Boris Kolpackov) Date: Thu Feb 7 10:14:03 2013 Subject: [odb-users] Cannot suppress inline file creation In-Reply-To: References: Message-ID: Hi Ben, Ben Morgan writes: > Well... perhaps I am doing something very unnatural... I would recommended the following way to handle multi-header libraries: 1. Choose a header prefix. Normally, if your library is called, say, libfoo, then it will be foo/. 2. Always use this prefix to include headers from your library (both external users and internal source code files). And use bracket includes instead of quote includes. For example: #include #include 3. Use -I option to specify the location of foo/. When installed, the headers go into /usr/include/foo/..., so no -I is required in this case. It is quite easy to amend the ODB-generated files to follow this scheme. Simply pass the following two options to the ODB compiler: --include-prefix foo/ --include-with-brackets Boris From boris at codesynthesis.com Thu Feb 7 11:12:24 2013 From: boris at codesynthesis.com (Boris Kolpackov) Date: Thu Feb 7 10:16:00 2013 Subject: [odb-users] unsigned long long not in C++98 standard In-Reply-To: References: Message-ID: Hi Ben, Ben Morgan writes: > Is this an intentional deviation? Yes, any C++ compiler that anyone cares about these days supports long long. Boris From neembi at gmail.com Thu Feb 7 11:31:20 2013 From: neembi at gmail.com (Ben Morgan) Date: Fri Feb 8 02:10:23 2013 Subject: [odb-users] unsigned long long not in C++98 standard In-Reply-To: References: Message-ID: On Thu, Feb 7, 2013 at 5:12 PM, Boris Kolpackov wrote: >> Is this an intentional deviation? > > Yes, any C++ compiler that anyone cares about these days supports > long long. Ok, thanks for the information! Maybe it would be useful to put that in the manual as an explicit deviation from the C++98 standard, so people know to specify `-Wno-long-long` or equivalent to the compiler. I don't know, maybe under a *Gotcha* section or something. But that's up to you: I know now :-) Ben From vsokolov at anl.gov Thu Feb 7 15:34:36 2013 From: vsokolov at anl.gov (Sokolov, Vadim O.) Date: Fri Feb 8 02:10:24 2013 Subject: [odb-users] schema_catalog In-Reply-To: References: <143C78680FCC2F4196592087ACC3AB44231666@BUTKUS.anl.gov> Message-ID: <143C78680FCC2F4196592087ACC3AB44231891@BUTKUS.anl.gov> Hi Boris, Thank you for a quick reply. Here is our scenario, we have 3 sqlite databases (in 3 files and they correspond to 3 named schemas), I have a create_all_databases function this function creates a single odb::database (use ATTACH statement from sqlite) object through which a user can access any of the 3 databases seamlessly. However some of the applications might use just one or two out of tree databases and those will not appear in the in schema_catalog and I would get an exception. Vadim -----Original Message----- From: Boris Kolpackov [mailto:boris@codesynthesis.com] Sent: Thursday, February 07, 2013 6:58 AM To: Sokolov, Vadim O. Cc: odb-users@codesynthesis.com Subject: Re: [odb-users] schema_catalog Hi Vadim. Sokolov, Vadim O. writes: > I am using names schemas in my application and at run time, I would > like to know what schemas are defined in schema_catalog. Is there is > a way to do it? No, not currently. While we can add this support, I am wondering what's the use case? Is it something to do with dynamic loading of the database support code (i.e., this way you can detect which components have been loaded)? Boris From boris at codesynthesis.com Fri Feb 8 10:52:54 2013 From: boris at codesynthesis.com (Boris Kolpackov) Date: Fri Feb 8 10:35:21 2013 Subject: [odb-users] libodb-1.2.0 build with MinGW GCC4.7.2 fails In-Reply-To: <5114F238.7030508@web.de> References: <5112B844.1060007@web.de> <5113B8D9.1010205@web.de> <5114F238.7030508@web.de> Message-ID: Hi Uwe, [CC'ing odb-users back in] I've updated the autotools toolchain to more recent versions and that has fixed the issues. I will still need to do more thorough testing but so far it looks good. If everything goes well, the upcoming 2.2.0 release (planned for mid-next week) will ship with these updates and will work with MinGW GCC 4.7.2. Thanks for reporting this! Boris From boris at codesynthesis.com Fri Feb 8 11:30:41 2013 From: boris at codesynthesis.com (Boris Kolpackov) Date: Fri Feb 8 11:13:08 2013 Subject: [odb-users] schema_catalog In-Reply-To: <143C78680FCC2F4196592087ACC3AB44231891@BUTKUS.anl.gov> References: <143C78680FCC2F4196592087ACC3AB44231666@BUTKUS.anl.gov> <143C78680FCC2F4196592087ACC3AB44231891@BUTKUS.anl.gov> Message-ID: Hi Vadim, Sokolov, Vadim O. writes: > Here is our scenario, we have 3 sqlite databases (in 3 files and they > correspond to 3 named schemas), I have a create_all_databases function > this function creates a single odb::database (use ATTACH statement > from sqlite) object through which a user can access any of the 3 > databases seamlessly. However some of the applications might use > just one or two out of tree databases and those will not appear in > the in schema_catalog and I would get an exception. I see. Returning a list of names, while possible, is not very convenient. The implementation does not keep it so we will have to collect them and return an std::vector or something like this by value. While not a big deal, it doesn't feel very clean. Plus, with the new multi-database support, a schema with the specified name can be "available" only for certain databases (i.e., there can be schema "foo" for SQLite and MySQL and schema "bar" only for SQLite). So, ideally, we would need to return a vector of pairs. On the other hand, providing a function like exist() would be really easy and clean. It would take the database and the name and return true if a schema with this name exists for this database. Would that be sufficient for your scenario? Boris From vsokolov at anl.gov Fri Feb 8 12:22:33 2013 From: vsokolov at anl.gov (Sokolov, Vadim O.) Date: Sat Feb 9 03:54:35 2013 Subject: [odb-users] schema_catalog In-Reply-To: References: <143C78680FCC2F4196592087ACC3AB44231666@BUTKUS.anl.gov> <143C78680FCC2F4196592087ACC3AB44231891@BUTKUS.anl.gov> Message-ID: <143C78680FCC2F4196592087ACC3AB44231AE9@BUTKUS.anl.gov> Hi Boris, I agree something like exists method would be a clean way to implement the feature and would be sufficient for our scenario. Vadim -----Original Message----- From: Boris Kolpackov [mailto:boris@codesynthesis.com] Sent: Friday, February 08, 2013 10:31 AM To: Sokolov, Vadim O. Cc: odb-users@codesynthesis.com Subject: Re: [odb-users] schema_catalog Hi Vadim, Sokolov, Vadim O. writes: > Here is our scenario, we have 3 sqlite databases (in 3 files and they > correspond to 3 named schemas), I have a create_all_databases function > this function creates a single odb::database (use ATTACH statement > from sqlite) object through which a user can access any of the 3 > databases seamlessly. However some of the applications might use just > one or two out of tree databases and those will not appear in the in > schema_catalog and I would get an exception. I see. Returning a list of names, while possible, is not very convenient. The implementation does not keep it so we will have to collect them and return an std::vector or something like this by value. While not a big deal, it doesn't feel very clean. Plus, with the new multi-database support, a schema with the specified name can be "available" only for certain databases (i.e., there can be schema "foo" for SQLite and MySQL and schema "bar" only for SQLite). So, ideally, we would need to return a vector of pairs. On the other hand, providing a function like exist() would be really easy and clean. It would take the database and the name and return true if a schema with this name exists for this database. Would that be sufficient for your scenario? Boris From davejohansen at gmail.com Sat Feb 9 11:41:57 2013 From: davejohansen at gmail.com (Dave Johansen) Date: Sat Feb 9 11:24:17 2013 Subject: [odb-users] sqlite test failure on CentOS 6 In-Reply-To: References: Message-ID: On Tue, Feb 5, 2013 at 8:22 AM, Dave Johansen wrote: > > On Tue, Feb 5, 2013 at 7:25 AM, Boris Kolpackov > wrote: > > > > Hi Dave, > > > > Dave Johansen writes: > > > > > I just built libodb-sqlite-2.1.1 on CentOS and ran the tests and one > > > of > > > the > > > tests failed. When doing the configure, I got the following warning: > > > configure: WARNING: libsqlite3 is built without sqlite3_unlock_notify > > > support; multi-threaded support will be limited > > > > > > And then when running the test common/threads, it printed "database > > > operation timeout" a bunch and then failed. > > > > As Hugo mentioned in his reply, ODB needs the SQLite unlock notification > > functionality to support multi-threaded database access. Without this > > support the 'threads' test in the test suite will fail. > > > > These days most recent distributions already build SQLite with unlock > > notify enabled by default (I've heard it is required by Mozilla, among > > other projects). I guess CentOS 6 hasn't switched yet. I see two ways > > to resolve the test failure: > > > > 1. Find libsqlite3 that has unlock notify enabled. As Hugo suggested, > > maybe there is an alternative/updated package. > > > > 2. If all else fails, you can disable the 'threads' test by passing > > the --disable-threads configure option to the test suite. > > There doesn't appear to be an alternate package in the CentOS or EPEL > repos. There's one in Atomic ( > > http://pkgs.org/centos-6-rhel-6/atomic-i386/sqlite-3.7.9-1.el6.art.i686.rpm.html > ), but I'm not sure if it has the appropriate build flags set or not. > For now, I'll just run the tests with --disable-threads since I won't > be using multi-threaded database access. > Thanks, > Dave My first question is that the ./configure states that --disable-threads is "enabled by default". Is that a typo? Assuming that isn't an error, then would it be possible to have --disable-threads also disable the running of the threads test in make check? Or is running the threads test still desirable even though --disable-threads is set in the ./configure? Thanks, Dave From boris at codesynthesis.com Sat Feb 9 14:51:08 2013 From: boris at codesynthesis.com (Boris Kolpackov) Date: Sat Feb 9 14:33:25 2013 Subject: [odb-users] sqlite test failure on CentOS 6 In-Reply-To: References: Message-ID: Hi Dave, Dave Johansen writes: > My first question is that the ./configure states that > --disable-threads is "enabled by default". Is that a typo? No, it means threads are enable by default, rather than "disable threads" are enabled by default. > Assuming that isn't an error, then would it be possible to have > --disable-threads also disable the running of the threads test in make > check? That's exactly what it does. If you pass --disable-threads then the 'threads' test won't be run. Boris From boris at codesynthesis.com Mon Feb 11 05:23:13 2013 From: boris at codesynthesis.com (Boris Kolpackov) Date: Mon Feb 11 05:05:18 2013 Subject: [odb-users] schema_catalog In-Reply-To: <143C78680FCC2F4196592087ACC3AB44231AE9@BUTKUS.anl.gov> References: <143C78680FCC2F4196592087ACC3AB44231666@BUTKUS.anl.gov> <143C78680FCC2F4196592087ACC3AB44231891@BUTKUS.anl.gov> <143C78680FCC2F4196592087ACC3AB44231AE9@BUTKUS.anl.gov> Message-ID: Hi Vadim, Sokolov, Vadim O. writes: > I agree something like exists method would be a clean way to implement > the feature and would be sufficient for our scenario. Ok, great. I've sneaked this feature in for the 2.2.0 release. Boris From grignon.florian at gmail.com Mon Feb 11 09:39:36 2013 From: grignon.florian at gmail.com (florian grignon) Date: Mon Feb 11 09:21:49 2013 Subject: [odb-users] [Search of feature] LIKE in the ODB query language Message-ID: Hello odb-users : ) I went over the last threads about odb, and I don't think my question has every been asked. My question(s) concern the ODB query language. I'm looking for the like operator, and if not existing, I would patch or add it to the library. But searching inside the source code of the library (I'm under sqlite right now, but need it for SQlite, MySQL, and Postgre), I don't find any operator like. Even if we can do a "like" through the native query language. Moreover, during my searches inside the source code, I don't find the definition of the in operator and the in_range. I would like to know how to add the like operator. Thank you for all the work on ODB. I'm looking forward to read from you. florian. From boris at codesynthesis.com Mon Feb 11 13:15:09 2013 From: boris at codesynthesis.com (Boris Kolpackov) Date: Mon Feb 11 12:57:10 2013 Subject: [odb-users] [Search of feature] LIKE in the ODB query language In-Reply-To: References: Message-ID: Hi Florian, Thanks for re-sending your question to the mailing list ;-). florian grignon writes: > Even if we can do a "like" through the native query language. Here is an earlier post that shows how to do this via a native query: http://codesynthesis.com/pipermail/odb-users/2012-November/000918.html > [...] if not existing, I would patch or add it to the library. Moreover, > during my searches inside the source code, I don't find the definition > of the in operator and the in_range. Yes, the LIKE operator can be handled just like IN. In the SQLite runtime, in() functions are defined in odb/sqlite/query.hxx and implemented in odb/sqlite/query.txx. Also, LIKE is on our TODO list and we would like to support it. In fact, if you can wait a few days, I can implement it and give you the patch (we like to implement features that someone is willing to start using before the release). Boris From grignon.florian at gmail.com Tue Feb 12 04:08:13 2013 From: grignon.florian at gmail.com (florian grignon) Date: Tue Feb 12 03:50:09 2013 Subject: [odb-users] [Search of feature] LIKE in the ODB query language In-Reply-To: References: Message-ID: Hi Boris, Thank you for your answer. I'm gonna try to implement quickly the like. I would be very glad to have your patch when you're done with it. I did see that the like is in the TODO list, but I didn't see that it's going to be in the 2.2 ? Keep me in touch about the patch. On Mon, Feb 11, 2013 at 7:15 PM, Boris Kolpackov wrote: > Hi Florian, > > Thanks for re-sending your question to the mailing list ;-). > > florian grignon writes: > > > Even if we can do a "like" through the native query language. > > Here is an earlier post that shows how to do this via a native query: > > http://codesynthesis.com/pipermail/odb-users/2012-November/000918.html > > > > [...] if not existing, I would patch or add it to the library. Moreover, > > during my searches inside the source code, I don't find the definition > > of the in operator and the in_range. > > Yes, the LIKE operator can be handled just like IN. In the SQLite runtime, > in() functions are defined in odb/sqlite/query.hxx and implemented in > odb/sqlite/query.txx. > > Also, LIKE is on our TODO list and we would like to support it. In fact, > if you can wait a few days, I can implement it and give you the patch > (we like to implement features that someone is willing to start using > before the release). > > Boris > From boris at codesynthesis.com Wed Feb 13 06:53:05 2013 From: boris at codesynthesis.com (Boris Kolpackov) Date: Wed Feb 13 06:34:53 2013 Subject: [odb-users] ODB 2.2.0 released Message-ID: Hi, We have released ODB 2.2.0. The NEWS file entries for this release are as follows: * Multi-database support. This mechanism allows an application to simultaneously work with multiple database systems and comes in two flavors: static and dynamic. With static support the application uses the static database interfaces (that is, odb::::database instead of odb::database). With dynamic support the same application code can access multiple databases via a common interface. Dynamic multi-database supports also allows the application to dynamically load the database support code for individual database systems if and when necessary. For more information, refer to Chapter 14, "Multi-Database Support" in the ODB manual. * Support for prepared queries. Prepared queries are a thin wrapper around the underlying database system's prepared statements functionality. They provide a way to perform potentially expensive query preparation tasks only once and then execute the query multiple times. For more information, refer to Section 4.5, "Prepared Queries" in the ODB manual as well as the 'prepared' example in the odb-examples package. * Mapping for char[N] and std::array to database VARCHAR(N-1) (or similar) as well as for char to database CHAR(1) (or similar). For SQL Server and SQLite on Windows equivalent mappings for wchar_t are also provided. Also the query support for arrays has been improved to allow passing a value of the decayed type (pointer) as a query parameter. For more information, refer to the ODB manual "Type Mapping" sections for each database system. * Support for change-tracking std::vector and QList container equivalents. Change-tracking containers minimize the number of database operations necessary to synchronize the container state with the database. For more information, refer to Sections 5.4, "Change-Tracking Containers", 5.4.1 "Change-Tracking vector", and 22.3.1, "Change-Tracking QList" in the ODB manual. * Support for automatically-derived SQL name transformations (table, column, index, etc). At the higher level, it is possible to assign prefixes and suffixes (--table-prefix, --{index,fkey,sequence}--suffix options) as well as to convert to upper or lower case (--sql-name-case option). At the lower level, it is possible to specify transformations as regular expressions (--{table,column,index,fkey,sequence,sql-name}-regex options). For more information, refer to the SQL NAME TRANSFORMATIONS section in the ODB compiler command line interface documentation (man pages). * New options, --export-symbol and --extern-symbol, allow DLL-exporting of the generated database support code. * Support for transaction post- commit/rollback callbacks. For more information, refer to Section 13.1, "Transaction Callbacks" in the ODB manual. * Support for custom session implementations. For more information, refer to Section 10.2, "Custom Sessions" in the ODB manual. * Support for early connection release. Now the database connection is released when commit()/rollback() is called rather than when the transaction instance goes out of scope. * New odb::schema_catalog function, exists(), can be used to check whether a schema with the specified name exists in the catalog. * Support for SQL Server ROWVERSION-based optimistic concurrency. For more information, refer to Section 19.1.1, "ROWVERSION Support" in the ODB manual. * Support for specifying the SQL Server transaction isolation level. For more information, refer to Section 19.2, "SQL Server Database Class" in the ODB manual. * Support for "smart" containers. A smart container is provided with additional functions which allow it to insert, update, and delete individual elements in the database. Change-tracking containers are examples of smart containers that utilizes this new functionality. Currently only ordered smart containers are supported. Note also that with this addition the names of the database functions provided by the ODB compiler (see libodb/odb/container-traits.hxx) have changed. This will only affect you if you have added ODB persistence support for a custom container. This release also adds support for Qt5 in addition to Qt4, including VC++ project/solution files as well as the autotools build system update. We have also upgraded the private copy of GCC that is used by the ODB compiler binary packages to 4.7.2 (actually, 4.7.3 pre-release) on all the platforms. In particular, this should make a difference to projects wishing to use C++11 features. Another notable addition is support for mobile/embedded systems. With this release we have added Raspberry Pi ARM GNU/Linux computer as one of the test targets and written a guide on using ODB on Mobile and Embedded Systems: http://wiki.codesynthesis.com/Using_ODB_on_Mobile_and_Embedded_Systems A more detailed discussion of the major new features can be found in the following blog post: http://www.codesynthesis.com/~boris/blog/2013/02/13/odb-2-2-0-released/ This release has been tested with a large number of platform/compiler/ architecture/library combinations. Specifically: Platform Compiler Version C++ Std Arch Qt Boost Databases ------------------------------------------------------------------------- GNU/Linux GCC 4.4-4.8 C++98,11 x86 32/64 4,5 Y All GNU/Linux Clang 3.2 C++98,11 x86 64 4 Y All Raspberry Pi GCC 4.7 C++98 arm - - SQLite Solaris Sun CC 12u2 Cstd x86 32/64 - - All ex MS SQL Solaris Sun CC 12u2 STLPort x86 32/64 - - All ex MS SQL Solaris Sun CC 12u2 Cstd SPARC 32/64 - - All ex MS SQL Mac OS X GCC 4.2 C++98 x86 32 4 Y All ex MS SQL Windows VC++ 9.0 C++98 x86 32/64 4 Y All Windows VC++ 10.0 C++11 x86 32/64 4,5 Y All Windows VC++ 11.0 C++11 x86 32/64 4 Y All MinGW-W64 GCC 4.7 C++98 x86 32 5 Y All We would also like to thank everyone who reported bugs, suggested fixes or new features, as well as tested early versions of this release. In particular, big thanks goes to Hugo Mildenberger who is working on packaging ODB for Gentoo and Dave Johansen who is doing the same for RHEL/CentOS. Hugo Mildenberger has also tracked down a number of issues in ODB when using MariaDB in place of MySQL. Thanks to his efforts ODB tests now run cleanly against MariaDB. Source code and pre-compiled binary packages for this release are available from the ODB Download page: http://www.codesynthesis.com/products/odb/download.xhtml SHA1 checksums for the files in this release are as follows: c02bc276a48bd8afa3c38b54c1bae790eb061643 libodb-2.2.0.tar.bz2 84adcfdb7cd311ea5cd666a3945713a4ef1f69c5 libodb-2.2.0.tar.gz f799bb2a3dc4e1eb6c432d5be3fe45cbce56a46d libodb-2.2.0.zip 54bb977beb5bea52eac958eba7e7b1121d5a347a libodb-boost-2.2.0.tar.bz2 fdf57dba0618266e7b948c7e40e09ae2b128dbca libodb-boost-2.2.0.tar.gz 71d5f749264ef64ac2844b6a0f02063accc610ec libodb-boost-2.2.0.zip ef1fe4216f7756d101a82bc9b728dd4276ecbf73 libodb-mssql-2.2.0.tar.bz2 1daa0d6eda89477bc2a73be89dca4a55e720ddc7 libodb-mssql-2.2.0.tar.gz 620b801743c04b004c6f237f89e76954596c38cd libodb-mssql-2.2.0.zip acb7f12d58d264f2288285ddd6ed3f3df7c98e8c libodb-mysql-2.2.0.tar.bz2 39a1cdea0cb3e3b6f349c58ce03c4ca237a70e35 libodb-mysql-2.2.0.tar.gz 34cb972170e79fa5f3b3654f5c835dbc0a950097 libodb-mysql-2.2.0.zip 856920bcaf477881d590f4bd5391add18ac6e3e1 libodb-oracle-2.2.0.tar.bz2 916f268778baf5e068497fe5b6d5c50b4cd5e2da libodb-oracle-2.2.0.tar.gz 0639ae29941b72d091eede855523d13588ea2212 libodb-oracle-2.2.0.zip 0bf21dcc5b319e8c5932fb015340bfcbeff69d80 libodb-pgsql-2.2.0.tar.bz2 10eb2dfa5b9ff6c81fa03b00442661e3da7b664c libodb-pgsql-2.2.0.tar.gz 6b65f92137dd9f2f93af604ca08050cc51feded5 libodb-pgsql-2.2.0.zip d0a26521c1747458ca09e85b97fa7036506b54b5 libodb-qt-2.2.0.tar.bz2 c07a54d4cfa786c49acfe3e521877598ddc8a82c libodb-qt-2.2.0.tar.gz b78556dd925a1aebcfba3148b8811fe3b1beb228 libodb-qt-2.2.0.zip a05fee4a452fde7371a78d662e27dd97fbacc14b libodb-sqlite-2.2.0.tar.bz2 458a605ff5945484cd150d81f0b1a7ea16e3a10c libodb-sqlite-2.2.0.tar.gz 3bc453b745bc104a8fdbb7a6f054fa49bdc46e67 libodb-sqlite-2.2.0.zip c58e80e579c4c49fff19055ee2a47064b5fd0805 odb-2.2.0-i686-linux-gnu.tar.bz2 a8764c780244b137369e8a0382cf3025ae661f03 odb-2.2.0-i686-macosx.tar.bz2 2e62dc711c3108d8a35c7466f0eca8e191ed26ed odb-2.2.0-i686-solaris.tar.bz2 2df92be11f939962f227d8e57e68b7b2f2b64be9 odb-2.2.0-i686-windows.zip 205b40ddb1ba426a348e0007ba262c82a1a11fd1 odb-2.2.0-sparc-solaris.tar.bz2 61657833e119373b4d66f2ccbb1938d7cf57ab1d odb-2.2.0.tar.bz2 ba204e2f3201caac72ecfc6c1e5e3b68f64583fd odb-2.2.0.tar.gz bfaee59d843facc8ce641232b8b00f7ace7c7d22 odb-2.2.0-x86_64-linux-gnu.tar.bz2 560edb6af4798d6846f6182c22b30b2992af9571 odb-2.2.0.zip 8ba9d5303154a40adfb9db5d989cf56ca8c52b74 odb-examples-2.2.0.tar.bz2 d28a00e6580c3ce8d4bef64ad5836028c873f15e odb-examples-2.2.0.tar.gz 3bd6d2b727997873f326833152914ec8a027820b odb-examples-2.2.0.zip 3ea7fbd83c9c00806453a4b3fa5aefa3995f5c0a odb-tests-2.2.0.tar.bz2 4246bd448c1b149abc176375617326157ba48017 odb-tests-2.2.0.tar.gz 3d2fd3afdcbb212cd8419c4e6cf34ddba1836fe8 odb-tests-2.2.0.zip Enjoy, Boris From 49834715 at qq.com Wed Feb 13 02:16:03 2013 From: 49834715 at qq.com (fryli) Date: Wed Feb 13 06:39:02 2013 Subject: [odb-users] Help, how to generate the hxx files automately by odb Message-ID: <1360739763.19664.9.camel@localhost.localdomain> Hi, I have a database based on mysql, how can i generate all hxx files by odb not by myself manually? Another problem is i test the example "hello", the persistence operation only inserts two records into the mysql, but the first records John.Doe vanished, there should be three records. Who can tell me how to solve the problem? I created a person table: id,int, auto increment first, varchar(45) last, varchar(45) age,int From joehesse at gmail.com Wed Feb 13 08:44:57 2013 From: joehesse at gmail.com (Joseph Hesse) Date: Wed Feb 13 08:26:46 2013 Subject: [odb-users] Persistence of pointers Message-ID: <511B98D9.9010202@gmail.com> Hi, If I have: class X { // ... }; class Y { // ... X *p; // ... }; Can I save X, Y objects so the pointer relationship is maintained? Thank you, Joe From boris at codesynthesis.com Wed Feb 13 09:26:57 2013 From: boris at codesynthesis.com (Boris Kolpackov) Date: Wed Feb 13 09:08:43 2013 Subject: [odb-users] Persistence of pointers In-Reply-To: <511B98D9.9010202@gmail.com> References: <511B98D9.9010202@gmail.com> Message-ID: Hi Joseph, Joseph Hesse writes: > class X > { > // ... > }; > > class Y > { > // ... > X *p; > // ... > }; > > Can I save X, Y objects so the pointer relationship is maintained? Yes, you can. See Chapter 6, "Relationships" in the ODB manual for more on how to do this: http://www.codesynthesis.com/products/odb/doc/manual.xhtml#6 Boris From boris at codesynthesis.com Wed Feb 13 09:42:36 2013 From: boris at codesynthesis.com (Boris Kolpackov) Date: Wed Feb 13 09:24:26 2013 Subject: [odb-users] Help, how to generate the hxx files automately by odb In-Reply-To: <1360739763.19664.9.camel@localhost.localdomain> References: <1360739763.19664.9.camel@localhost.localdomain> Message-ID: Hi, fryli <49834715@qq.com> writes: > I have a database based on mysql, how can i generate all hxx files > by odb not by myself manually? No, this is not yet supported. We do have plans for an SQL-to-C++ compiler, thought. Note also that ODB supports manually mapping C++ classes to an existing database schema. That is, you can tell ODB the names of the tables/columns/etc., that the class should use, their types, null/not_null, etc. See the 'schema/custom' example in the odb-examples package for some examples. > Another problem is i test the example "hello", the persistence operation > only inserts two records into the mysql, but the first records John.Doe > vanished, there should be three records. Who can tell me how to solve > the problem? > I created a person table: > id,int, auto increment > first, varchar(45) > last, varchar(45) > age,int Not sure what the problem is, but the first thing to try is to tell the ODB compiler the types of each member. For example: #pragma db object class person { ... #pragma db id auto type("INT") unsigned long id_; #pragma db type("VARCHAR(45)") null std::string first_; #pragma db type("VARCHAR(45)") null std::string last_; #pragma db type("INT") null unsigned short age_; }; Generally, when mapping a class to an existing schema there is a very useful verification test to do: generate the schema with the --generate-schema option and make sure that the result SQL is semantically equivalent to your actual schema. For example, given the above mapping, I get the following schema: CREATE TABLE `person` ( `id` INT NOT NULL PRIMARY KEY AUTO_INCREMENT, `first` VARCHAR(45), `last` VARCHAR(45), `age` INT); Which is pretty much what you have (I assume id is a primary key). Boris From uwe_kindler at web.de Wed Feb 13 16:56:09 2013 From: uwe_kindler at web.de (Uwe Kindler) Date: Wed Feb 13 22:26:41 2013 Subject: [odb-users] libodb-sqlite-2.2.0 compile problem Message-ID: <511C0BF9.1000503@web.de> Hi Boris, I'm just compiling all ODB 2.2.0 libraries with MinGW GCC 4.7.2 and stumbled over the following libodb-sqlite-2.2.0 error: database.cxx:6:66: fatal error: odb/details/win32/windows.hxx: No such file or directory compilation terminated. make[2]: *** [database.lo] Error 1 I checked the directory /local/include/odb - the target directory of libodb make install command. The directory \local\include\odb\details is missing the win32 folder but contains the posix folder. I manually copied the win32 folder over to the install directory and was able to successfully finish compilation of libodb-sqlite-2.2.0. So it seems, make install command assumes we are on a posix (linux) system instead of a Windows system. But compilation of libodb now successfully works with MinGW GCC4.7.2 - thank you for this quick fix - your support is awesome. Kind regards, Uwe Kindler From boris at codesynthesis.com Thu Feb 14 00:13:47 2013 From: boris at codesynthesis.com (Boris Kolpackov) Date: Wed Feb 13 23:55:29 2013 Subject: [odb-users] libodb-sqlite-2.2.0 compile problem In-Reply-To: <511C0BF9.1000503@web.de> References: <511C0BF9.1000503@web.de> Message-ID: Hi Uwe, Uwe Kindler writes: > I'm just compiling all ODB 2.2.0 libraries with MinGW GCC 4.7.2 and > stumbled over the following libodb-sqlite-2.2.0 error: > > database.cxx:6:66: fatal error: odb/details/win32/windows.hxx: No such > file or directory Ah, I know what happens. Your GCC is configured to use POSIX threads (new thing in MinGW-W64; necessary to support C++11 threads). ODB now detects this and also uses POSIX threads instead of Win32. The side effect of this is that the Win32 headers, particularly, windows.hxx, are no longer installed. But libodb-sqlite (and also libodb-mssql) need this header on Win32 regardless of the threading model. I've fixed libodb build system to always install windows.hxx on Windows. I've tested it on my side and it work fine. Could you also give it a try and confirm that it is fixed? Then I will make the bug-fix official. http://www.codesynthesis.com/~boris/tmp/odb/libodb-2.2.1.zip > thank you for this quick fix - your support is awesome. Thanks, I am glad things are (mostly) working for you ;-). And thanks for the bug report, always appreciated! Boris From boris at codesynthesis.com Thu Feb 14 10:57:53 2013 From: boris at codesynthesis.com (Boris Kolpackov) Date: Thu Feb 14 10:39:31 2013 Subject: [odb-users] libodb 2.2.1 bugfix released Message-ID: Hi, New bugfix releases for the common ODB runtime library (libodb) is now available. It fixes an issue with a missing windows.hxx header file and only affects a very specific configuration: installed MinGW-W64 builds with the GCC compiler that uses the POSIX threading model (run gcc -v). Any other platform or configuration is not affected and no upgrade is necessary. For more details on this bug, see the following mailing list thread: http://www.codesynthesis.com/pipermail/odb-users/2013-February/001076.html You can download the new packages from the ODB download page: http://www.codesynthesis.com/products/odb/download.xhtml SHA1 checksums for the files in this release are as follows: c5b544b9e294e0a6b603d88aaef548ad167aec82 libodb-2.2.1.tar.bz2 8bb72efe12f74031a5590002e1b13930d0d061bb libodb-2.2.1.tar.gz 0bdd43614a7d8d47eb827711b65dba753a73efab libodb-2.2.1.zip Boris From PDurkan at cantor.com Thu Feb 14 16:50:37 2013 From: PDurkan at cantor.com (Durkan, Peter) Date: Thu Feb 14 23:18:16 2013 Subject: [odb-users] Incompatible ODB compiler and runtime version Message-ID: <4967068F5E7B884FA0BFE70578CFF1ED71E4F3D1@TBPINFN0201.cad.local> Hi, I just updated to the latest version and am not getting errors as in the subject when trying to build my project - ":4:4: error: #error incompatible ODB compiler and runtime versions" $$ odb --version 02/14/2013 16:49:30 EST ODB object-relational mapping (ORM) compiler for C++ 2.2.0 Copyright (c) 2009-2013 Code Synthesis Tools CC This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. Below is my version.hxx. // ODB interface version: minor, major, and alpha/beta versions. #define ODB_VERSION 20200 #define ODB_VERSION_STR "2.2" // libodb version: interface version plus the bugfix version. // #define LIBODB_VERSION 2020100 #define LIBODB_VERSION_STR "2.2.1" #include #endif // ODB_VERSION_HXX Any ideas? Thanks, Peter CONFIDENTIAL: This e-mail, including its contents and attachments, if any, are confidential. If you are not the named recipient please notify the sender and immediately delete it. You may not disseminate, distribute, or forward this e-mail message or disclose its contents to anybody else. Copyright and any other intellectual property rights in its contents are the sole property of Cantor Fitzgerald. E-mail transmission cannot be guaranteed to be secure or error-free. The sender therefore does not accept liability for any errors or omissions in the contents of this message which arise as a result of e-mail transmission. If verification is required please request a hard-copy version. Although we routinely screen for viruses, addressees should check this e-mail and any attachments for viruses. We make no representation or warranty as to the absence of viruses in this e-mail or any attachments. Please note that to ensure regulatory compliance and for the protection of our customers and business, we may monitor and read e-mails sent to and from our server(s). For further important information, please see http://www.cantor.com/legal/statement From boris at codesynthesis.com Fri Feb 15 02:49:22 2013 From: boris at codesynthesis.com (Boris Kolpackov) Date: Fri Feb 15 03:01:57 2013 Subject: [odb-users] Incompatible ODB compiler and runtime version In-Reply-To: <4967068F5E7B884FA0BFE70578CFF1ED71E4F3D1@TBPINFN0201.cad.local> References: <4967068F5E7B884FA0BFE70578CFF1ED71E4F3D1@TBPINFN0201.cad.local> Message-ID: Hi Peter, Durkan, Peter writes: > I just updated to the latest version and am not getting errors as in > the subject when trying to build my project - > > ":4:4: error: #error incompatible ODB compiler and runtime versions" This means that the ODB compiler somehow picks up an older/newer version of libodb. The best way to diagnose this problem is to run the ODB compiler with the -v option. This will trigger a lot of extra information being printed by the ODB compiler, but what we are interested in is the include search paths and their order. Specifically, look for a block of lines around the line that reads "#include "..." search starts here:". For example, if I run this on my box: $ odb -v -d mysql test.hxx The chunk of lines that we are interested in looks like this: ignoring nonexistent directory "/usr/local/include/x86_64-linux-gnu" ignoring nonexistent directory "/usr/lib/gcc/x86_64-linux-gnu/4.6/../../../../x86_64-linux-gnu/include" #include "..." search starts here: #include <...> search starts here: /usr/include/c++/4.6 /usr/include/c++/4.6/x86_64-linux-gnu/. /usr/include/c++/4.6/backward /usr/lib/gcc/x86_64-linux-gnu/4.6/include /usr/local/include /usr/lib/gcc/x86_64-linux-gnu/4.6/include-fixed /usr/include/x86_64-linux-gnu /usr/include End of search list. First, if you have any "ignoring nonexistent directory" lines, make sure none of the directories mentioned are where you think up-to-date libodb is installed. For example, you might have specified the libodb directory with -I but misspelled it. Next, examine all the directories after the "#include <...> search starts here" line in order (this is the order in which ODB will examine them). Look for the odb/version.hxx file in each. Once found, open it and check the ODB_VERSION_STR macro. It should be the same as the first two components (major and minor) of the ODB compiler version as printed with odb --version. For example, in my case, odb/version.hxx is found in /usr/local/include and its ODB_VERSION_STR is "2.2", which matches the 2.2.0 ODB compiler version. Let us know how it goes. Boris From PDurkan at cantor.com Fri Feb 15 08:30:26 2013 From: PDurkan at cantor.com (Durkan, Peter) Date: Fri Feb 15 09:00:58 2013 Subject: [odb-users] Incompatible ODB compiler and runtime version In-Reply-To: References: <4967068F5E7B884FA0BFE70578CFF1ED71E4F3D1@TBPINFN0201.cad.local> Message-ID: <4967068F5E7B884FA0BFE70578CFF1ED71E4F4EE@TBPINFN0201.cad.local> Hi Boris, Yes - this is exactly what happened. I had an older version installed that it was picking up. All looks good now! Thanks! Peter -----Original Message----- From: Boris Kolpackov [mailto:boris@codesynthesis.com] Sent: Friday, February 15, 2013 2:49 AM To: Durkan, Peter Cc: odb-users@codesynthesis.com Subject: Re: [odb-users] Incompatible ODB compiler and runtime version Hi Peter, Durkan, Peter writes: > I just updated to the latest version and am not getting errors as in > the subject when trying to build my project - > > ":4:4: error: #error incompatible ODB compiler and runtime versions" This means that the ODB compiler somehow picks up an older/newer version of libodb. The best way to diagnose this problem is to run the ODB compiler with the -v option. This will trigger a lot of extra information being printed by the ODB compiler, but what we are interested in is the include search paths and their order. Specifically, look for a block of lines around the line that reads "#include "..." search starts here:". For example, if I run this on my box: $ odb -v -d mysql test.hxx The chunk of lines that we are interested in looks like this: ignoring nonexistent directory "/usr/local/include/x86_64-linux-gnu" ignoring nonexistent directory "/usr/lib/gcc/x86_64-linux-gnu/4.6/../../../../x86_64-linux-gnu/include" #include "..." search starts here: #include <...> search starts here: /usr/include/c++/4.6 /usr/include/c++/4.6/x86_64-linux-gnu/. /usr/include/c++/4.6/backward /usr/lib/gcc/x86_64-linux-gnu/4.6/include /usr/local/include /usr/lib/gcc/x86_64-linux-gnu/4.6/include-fixed /usr/include/x86_64-linux-gnu /usr/include End of search list. First, if you have any "ignoring nonexistent directory" lines, make sure none of the directories mentioned are where you think up-to-date libodb is installed. For example, you might have specified the libodb directory with -I but misspelled it. Next, examine all the directories after the "#include <...> search starts here" line in order (this is the order in which ODB will examine them). Look for the odb/version.hxx file in each. Once found, open it and check the ODB_VERSION_STR macro. It should be the same as the first two components (major and minor) of the ODB compiler version as printed with odb --version. For example, in my case, odb/version.hxx is found in /usr/local/include and its ODB_VERSION_STR is "2.2", which matches the 2.2.0 ODB compiler version. Let us know how it goes. Boris CONFIDENTIAL: This e-mail, including its contents and attachments, if any, are confidential. If you are not the named recipient please notify the sender and immediately delete it. You may not disseminate, distribute, or forward this e-mail message or disclose its contents to anybody else. Copyright and any other intellectual property rights in its contents are the sole property of Cantor Fitzgerald. E-mail transmission cannot be guaranteed to be secure or error-free. The sender therefore does not accept liability for any errors or omissions in the contents of this message which arise as a result of e-mail transmission. If verification is required please request a hard-copy version. Although we routinely screen for viruses, addressees should check this e-mail and any attachments for viruses. We make no representation or warranty as to the absence of viruses in this e-mail or any attachments. Please note that to ensure regulatory compliance and for the protection of our customers and business, we may monitor and read e-mails sent to and from our server(s). For further important information, please see http://www.cantor.com/legal/statement From pstath at axxcelera.com Fri Feb 15 13:58:24 2013 From: pstath at axxcelera.com (Stath Paul) Date: Fri Feb 15 13:58:34 2013 Subject: [odb-users] ODB fails to compile if GCC doesn't support NLS Message-ID: <3233D27CC5658E4598557F8521F6B07E21755EAE49@RIC-MS01.abw.int> Boris -- I have found that ODB doesn't compile if the compiler you are using doesn't support NLS. I'm attempting to compile odb-2.2.0 from source. The GCC compiler I'm using was compiled w/o NLS support by throwing the "--disable-nls" switch during the configure process. I discovered this issue while trying to set up a BitBake recipe to compile ODB as part of an embedded Yocto based distribution. By default, GCC is compiled with NLS support. (--enable-nls) If the configure script detects that GCC is being built as a cross compiler, it defaults to --disable-nls. I was able to recreated the issue outside the Yocto build environment by compiling GCC w/o NLS support. Here is the output from "/opt/gcc-no-nls/bin/g++ -v" Using built-in specs. COLLECT_GCC=/opt/gcc-no-nls/bin/g++ COLLECT_LTO_WRAPPER=/opt/gcc-no-nls/libexec/gcc/i686-pc-linux-gnu/4.7.2/lto-wrapper Target: i686-pc-linux-gnu Configured with: ./configure --disable-nls --prefix=/opt/gcc-no-nls Thread model: posix gcc version 4.7.2 (GCC) I configured the build of ODB to use this compiler using: ./configure --with-gxx-name=/opt/gcc-no-nls/bin/g++ CXX=/opt/gcc-n0-nls/bin/g++ When I run make, I'm getting the following error: libtool: compile: /opt/gcc-no-nls/bin/g++ -DHAVE_CONFIG_H -I.. -I.. -I/opt/gcc-no-nls/lib/gcc/i686-pc-linux-gnu/4.7.2/plugin/include -I/home/pstath/src/libcutl-1.7.1 -g -O2 -MT instance.lo -MD -MP -MF .deps/instance.Tpo -c instance.cxx -fPIC -DPIC -o .libs/instance.o depbase=`echo include.lo | sed 's|[^/]*$|.deps/&|;s|\.lo$||'`;\ /bin/bash ../libtool --tag=CXX --mode=compile /opt/gcc-no-nls/bin/g++ -DHAVE_CONFIG_H -I'..' -I'..' -I/opt/gcc-no-nls/lib/gcc/i686-pc-linux-gnu/4.7.2/plugin/include -I/home/pstath/src/libcutl-1.7.1 -g -O2 -MT include.lo -MD -MP -MF $depbase.Tpo -c -o include.lo include.cxx &&\ mv -f $depbase.Tpo $depbase.Plo libtool: compile: /opt/gcc-no-nls/bin/g++ -DHAVE_CONFIG_H -I.. -I.. -I/opt/gcc-no-nls/lib/gcc/i686-pc-linux-gnu/4.7.2/plugin/include -I/home/pstath/src/libcutl-1.7.1 -g -O2 -MT include.lo -MD -MP -MF .deps/include.Tpo -c include.cxx -fPIC -DPIC -o .libs/include.o In file included from /opt/gcc-no-nls/lib/gcc/i686-pc-linux-gnu/4.7.2/../../../../include/c++/4.7.2/i686-pc-linux-gnu/bits/messages_members.h:37:0, from /opt/gcc-no-nls/lib/gcc/i686-pc-linux-gnu/4.7.2/../../../../include/c++/4.7.2/bits/locale_facets_nonio.h:1898, from /opt/gcc-no-nls/lib/gcc/i686-pc-linux-gnu/4.7.2/../../../../include/c++/4.7.2/locale:43, from include.cxx:9: /usr/include/libintl.h:40:14: error: expected unqualified-id before '__const' /usr/include/libintl.h:40:14: error: expected ')' before '__const' /usr/include/libintl.h:40:14: error: expected initializer before '__const' /usr/include/libintl.h:64:43: error: new declaration 'char* fake_ngettext(const char*, const char*, long unsigned int)' In file included from ../odb/gcc.hxx:44:0, from include.cxx:5: /opt/gcc-no-nls/lib/gcc/i686-pc-linux-gnu/4.7.2/plugin/include/intl.h:46:20: error: ambiguates old declaration 'const char* fake_ngettext(const char*, const char*, long unsigned int)' In file included from /opt/gcc-no-nls/lib/gcc/i686-pc-linux-gnu/4.7.2/../../../../include/c++/4.7.2/i686-pc-linux-gnu/bits/messages_members.h:37:0, from /opt/gcc-no-nls/lib/gcc/i686-pc-linux-gnu/4.7.2/../../../../include/c++/4.7.2/bits/locale_facets_nonio.h:1898, from /opt/gcc-no-nls/lib/gcc/i686-pc-linux-gnu/4.7.2/../../../../include/c++/4.7.2/locale:43, from include.cxx:9: /usr/include/libintl.h:83:14: error: expected unqualified-id before '__const' /usr/include/libintl.h:83:14: error: expected ')' before '__const' /usr/include/libintl.h:83:14: error: expected initializer before '__const' /usr/include/libintl.h:87:14: error: expected unqualified-id before '__const' /usr/include/libintl.h:87:14: error: expected ')' before '__const' /usr/include/libintl.h:87:14: error: expected initializer before '__const' make[2]: *** [include.lo] Error 1 I was able to correct the issue by making a slight modification to odb/gcc.hxx. One can either remove the "#include " on line 44, or Modify the line to be "#include ". >From what I can tell, odb is not internationalized. Is there a need to include (or ) at all? -- Paul Stath Senior Software Engineer Axxcelera Broadband Wireless From boris at codesynthesis.com Fri Feb 15 14:29:20 2013 From: boris at codesynthesis.com (Boris Kolpackov) Date: Fri Feb 15 14:29:29 2013 Subject: [odb-users] ODB fails to compile if GCC doesn't support NLS In-Reply-To: <3233D27CC5658E4598557F8521F6B07E21755EAE49@RIC-MS01.abw.int> References: <3233D27CC5658E4598557F8521F6B07E21755EAE49@RIC-MS01.abw.int> Message-ID: Hi Paul, Stath Paul writes: > /usr/include/libintl.h:40:14: error: expected unqualified-id before '__const' Yes, I've seen this while building binaries for GNU/Linux. Looks like some weird interaction between libstdc++ and GCC plugin headers. Specifically, intl.h in GCC defines gettext as a macro which causes havoc in libintl.h. > I was able to correct the issue by making a slight modification to > odb/gcc.hxx. > > One can either remove the "#include " on line 44, > > or > > Modify the line to be "#include ". > > From what I can tell, odb is not internationalized. Is there a need > to include (or ) at all? Good question. I just checked and none of the GCC plugin headers actually include intl.h. It also appears that ODB doesn't need this header (I've just tested with 4.5, 4.6, and 4.7). A lot of the includes in gcc.hxx are there just because "that's how GCC excepts them to be". So, yes, removing intl.h inclusion seems to be the fix. I will publish a bugfix shortly. Thanks for the report and let me know if there are any other issues. Boris From mdaniels at lanl.gov Sat Feb 16 17:53:47 2013 From: mdaniels at lanl.gov (Daniels, Marcus G) Date: Sat Feb 16 17:53:50 2013 Subject: [odb-users] HDF5 support? Message-ID: <532C594B7920A549A2A91CB4312CC576140D54FE@ECS-EXG-P-MB01.win.lanl.gov> Hi, Besides the work, is there any reason not to consider adding support for HDF5? http://www.hdfgroup.org/HDF5/ While Postgres has array types, HDF5 is designed for parallel computing environments where datasets of terabytes in size are read and written in native format in parallel. (I don't see existing RDBMs competing in this arena.) Marcus From boris at codesynthesis.com Mon Feb 18 02:56:41 2013 From: boris at codesynthesis.com (Boris Kolpackov) Date: Mon Feb 18 02:56:49 2013 Subject: [odb-users] HDF5 support? In-Reply-To: <532C594B7920A549A2A91CB4312CC576140D54FE@ECS-EXG-P-MB01.win.lanl.gov> References: <532C594B7920A549A2A91CB4312CC576140D54FE@ECS-EXG-P-MB01.win.lanl.gov> Message-ID: Hi Marcus, Daniels, Marcus G writes: > Besides the work, is there any reason not to consider adding support > for HDF5? I looked a bit into it, and it appears that HDF5 is more of a file format rather than a (relational) database. While right now ODB is exclusively about relational databases, the idea of also supporting file formats (XML, JSON, etc) seems like a natural extension and crossed our minds on several occasions. I think HDF5 will fit into this model (i.e., file format vs database) quite well. > While Postgres has array types, HDF5 is designed for parallel computing > environments where datasets of terabytes in size are read and written > in native format in parallel. (I don't see existing RDBMs competing in > this arena.) I wonder how will this parallelism fit into ODB? I don't believe HDF5 has a notion of transactions. How does HDF5 ensure ACID of the data? Boris From davejohansen at gmail.com Mon Feb 18 23:28:44 2013 From: davejohansen at gmail.com (Dave Johansen) Date: Mon Feb 18 23:28:51 2013 Subject: [odb-users] Build error on CentOS 6 Message-ID: I just tried building 2.2 on CentOS 6 and I get the following error: libtool: link: /opt/centos/devtoolset-1.1/root/usr/bin/g++ -g -O2 -o .libs/odb odb-odb.o odb-option-types.o odb-option-functions.o odb-profile.o semantics/relational/odb-name.o odb-options.o -L/home/dlj/projects/odb_2.2/odb-2.2.0/../libcutl-1.7.1/cutl /home/dlj/projects/odb_2.2/odb-2.2.0/../libcutl-1.7.1/cutl/.libs/libcutl.so -Wl,-rpath -Wl,/usr/local/lib /usr/bin/ld: .libs/odb: undefined reference to symbol 'pthread_cancel@ @GLIBC_2.0' /usr/bin/ld: note: 'pthread_cancel@@GLIBC_2.0' is defined in DSO /lib/libpthread.so.0 so try adding it to the linker command line /lib/libpthread.so.0: could not read symbols: Invalid operation Please let me know if there's anything else I can do to try and diagnose the problem. Dave From davejohansen at gmail.com Tue Feb 19 00:17:41 2013 From: davejohansen at gmail.com (Dave Johansen) Date: Tue Feb 19 00:17:48 2013 Subject: [odb-users] Re: Build error on CentOS 6 In-Reply-To: References: Message-ID: On Mon, Feb 18, 2013 at 9:28 PM, Dave Johansen wrote: > > I just tried building 2.2 on CentOS 6 and I get the following error: > libtool: link: /opt/centos/devtoolset-1.1/root/usr/bin/g++ -g -O2 -o .libs/odb odb-odb.o odb-option-types.o odb-option-functions.o odb-profile.o semantics/relational/odb-name.o odb-options.o -L/home/dlj/projects/odb_2.2/odb-2.2.0/../libcutl-1.7.1/cutl /home/dlj/projects/odb_2.2/odb-2.2.0/../libcutl-1.7.1/cutl/.libs/libcutl.so -Wl,-rpath -Wl,/usr/local/lib > /usr/bin/ld: .libs/odb: undefined reference to symbol 'pthread_cancel@@GLIBC_2.0' > /usr/bin/ld: note: 'pthread_cancel@@GLIBC_2.0' is defined in DSO /lib/libpthread.so.0 so try adding it to the linker command line > /lib/libpthread.so.0: could not read symbols: Invalid operation > > Please let me know if there's anything else I can do to try and diagnose the problem. > > Dave It actually looks like the issue is with libcutl 1.7.1 because I just tried building odb 2.1.1 with libcutl 1.7.1 and it gave me the same error but built just fine with libcutl 1.7.0. From boris at codesynthesis.com Tue Feb 19 00:29:19 2013 From: boris at codesynthesis.com (Boris Kolpackov) Date: Tue Feb 19 00:29:26 2013 Subject: [odb-users] Build error on CentOS 6 In-Reply-To: References: Message-ID: Dave Johansen writes: > I just tried building 2.2 on CentOS 6 and I get the following error: > > [...] > > /usr/bin/ld: .libs/odb: undefined reference to symbol 'pthread_cancel@@GLIBC_2.0' > /usr/bin/ld: note: 'pthread_cancel@@GLIBC_2.0' is defined in DSO > /lib/libpthread.so.0 so try adding it to the linker command line > /lib/libpthread.so.0: could not read symbols: Invalid operation I believe this thread explains what happens: http://lists.fedoraproject.org/pipermail/devel/2010-January/129148.html Now, because internal Boost uses threads by default, libcutl links to -lpthread. And this leads to what is described in that mailing list post. I am trying to confirm this on FC17 right now. In the meantime, you can build libcutl with threads disabled (ODB does not use threads) by passing the --disable-threads configure option. I believe this will fix the issue. Boris From boris at codesynthesis.com Tue Feb 19 00:59:27 2013 From: boris at codesynthesis.com (Boris Kolpackov) Date: Tue Feb 19 00:59:33 2013 Subject: [odb-users] Build error on CentOS 6 In-Reply-To: References: Message-ID: Hi Dave, Boris Kolpackov writes: > I am trying to confirm this on FC17 right now. I tried it on FC17 and everything builds fine, no undefined pthread_cancel symbol. I also read that mailing list thread further and it seems that they finally realized it is a bug in the toolchain. See this post: http://lists.fedoraproject.org/pipermail/devel/2010-January/129131.html So I guess it has been fixed in later FC versions. Can you confirm that everything builds fine on CentOS 6 if you pass the --disable-threads option to libcutl configure? Boris From mdaniels at lanl.gov Mon Feb 18 10:17:04 2013 From: mdaniels at lanl.gov (Daniels, Marcus G) Date: Tue Feb 19 01:24:02 2013 Subject: [odb-users] HDF5 support? In-Reply-To: References: <532C594B7920A549A2A91CB4312CC576140D54FE@ECS-EXG-P-MB01.win.lanl.gov> Message-ID: <532C594B7920A549A2A91CB4312CC576140D6E8D@ECS-EXG-P-MB01.win.lanl.gov> On Feb 18, 2013, at 12:56 AM, Boris Kolpackov wrote: Besides the work, is there any reason not to consider adding support for HDF5? I looked a bit into it, and it appears that HDF5 is more of a file format rather than a (relational) database. While right now ODB is exclusively about relational databases, the idea of also supporting file formats (XML, JSON, etc) seems like a natural extension and crossed our minds on several occasions. I think HDF5 will fit into this model (i.e., file format vs database) quite well. I'm not aware of anyone that uses HDF5 just as a file format anymore. I know of some cases of HDF4 being written by multiple independent clients, but HDF5 is a more complex standard and so I think everyone uses their libraries. It's more like documenting the format of a filesystem. (And HDF5 is a lot like a userspace filesystem.) While Postgres has array types, HDF5 is designed for parallel computing environments where datasets of terabytes in size are read and written in native format in parallel. (I don't see existing RDBMs competing in this arena.) I wonder how will this parallelism fit into ODB? I don't believe HDF5 has a notion of transactions. The kind of parallelism I have in mind would be decomposition of very large arrays. That is, suppose a X/Y/Z 3-d space is physically decomposed along the Z dimension on large RAID array and a query is made to collect a subspace of it. Further suppose that several servers were associated with different parts of the Z dimension (each chunk of Z on a server and over several hard drives). There would be parallelism collecting the data for a partial Z chunk. With HDF5, this would be coordinated over different ranks of a MPI process. How does HDF5 ensure ACID of the data? I don't think it has mechanisms for this. There are some proposals.. http://www.hdfgroup.org/pubs/rfcs/Metadata_Journaling_RFC.pdf One use case for HDF5 are large simulations, like ocean and climate models, that periodically dump their state to disk. This is 1) to facilitate analysis, and 2) so that if there is a system crash, the time invested in the simulation is not lost. The parallel access isn't like a database with lots of autonomous agents attached to it. It's one large parallel coordinated agent. The kind of data that's stored may be arrays of structures or structures of arrays, depending on the calculation. Advantages of HDF5 has over using multiple binary files include that it enforces type discipline over the data, and provides a single file that is self describing. Unfortunately it is fairly tedious to describe the types through its API (tedious in the same way as it is for derived types in MPI) and it would be neat if all that was necessary was to write down a C++ class. Cheers, Marcus From andrei.i.ivanov at commandus.com Tue Feb 19 02:04:23 2013 From: andrei.i.ivanov at commandus.com (=?UTF-8?B?0JDQvdC00YDQtdC5INCY0LLQsNC90L7Qsg==?=) Date: Tue Feb 19 02:13:45 2013 Subject: [odb-users] How to change name of relationship table? Message-ID: <512323F7.9010606@commandus.com> Hi all, Please give me advise how can I change table name used for related object. For instance, I have object "webuser" which stored in database as dbo.webusers, and some address identifiers related to the "webuser". I need store this values in "dbo.user_addr" not "webusers_addresses" because database objecsts already exists. What doing wrong? #pragma db object table("dbo.user_addr") class useraddress { public: #pragma db id int id_addr_; }; typedef std::vector> useraddress_ptrs; #pragma db object table("dbo.webusers") class webuser { ... useraddress_ptrs addresses_; #pragma db object(useraddress) table("dbo.user_addr") #pragma db value(useraddress_ptrs) value_not_null unordered id_column("webuser_id") value_column("id_addr") table("dbo.user_addr") ... } It creates webuser.sql : CREATE TABLE [dbo].[webusers_addresses] ( [webuser_id] INT NOT NULL, [id_addr] INT NOT NULL, that means #pragma db object table("dbo.user_addr") and #pragma db value(useraddress_ptrs) ... table("dbo.user_addr") does not take effect both. What I need to do? -- Best regards, Andrei Ivanov tel:+7 (914) 104-0619 fax:+1 (801) 880-0903 enum:+882 (9999) 255782 mailto:andrei.i.ivanov@commandus.com http://commandus.com/ jid:andrei.i.ivanov@gmail.com From boris at codesynthesis.com Tue Feb 19 02:24:12 2013 From: boris at codesynthesis.com (Boris Kolpackov) Date: Tue Feb 19 02:24:18 2013 Subject: [odb-users] How to change name of relationship table? In-Reply-To: <512323F7.9010606@commandus.com> References: <512323F7.9010606@commandus.com> Message-ID: Hi Andrei, ?????? ?????? writes: > #pragma db object table("dbo.user_addr") > class useraddress { > public: > #pragma db id > int id_addr_; > }; > > typedef std::vector> useraddress_ptrs; > > #pragma db object table("dbo.webusers") > class webuser { > ... So far so good. > useraddress_ptrs addresses_; > #pragma db object(useraddress) table("dbo.user_addr") This pragma is not necessary; you have already assigned the table name to the useraddress persistent object. > #pragma db value(useraddress_ptrs) value_not_null unordered > id_column("webuser_id") value_column("id_addr") table("dbo.user_addr") You cannot assign table name to a container value type, only to a container member (each member gets its own table). I would rewrite the webuser class like this (i.e., apply the pragma to the member, not the type): #pragma db object table("dbo.webusers") class webuser { ... #pragma db value_not_null unordered \ id_column("webuser_id") value_column("id_addr") \ table("dbo.user_addr") useraddress_ptrs addresses_; }; Boris From boris at codesynthesis.com Tue Feb 19 02:56:03 2013 From: boris at codesynthesis.com (Boris Kolpackov) Date: Tue Feb 19 02:56:09 2013 Subject: [odb-users] Gentoo packages for ODB 2.2.0 Message-ID: Hi, Hugo Mildenberger has packaged the complete ODB 2.2.0 system for Gentoo and submitted the request for inclusion into the official Gentoo repository: https://bugs.gentoo.org/show_bug.cgi?id=458152 If you are interested in using ODB on Gentoo, please consider voting for it (requires login, next to the "Importance" field) and/or report test results. You can download all the packages as one archive via this link: http://www.codesynthesis.com/~boris/tmp/odb/odb-2.2.0-gentoo-ebuilds.tar.gz Hugo's instructions on how to build everything are below. Boris ----- Forwarded message from Hugo.Mildenberger@web.de ----- Not included are other "ebuilds" or modifications to other ebuilds, simply because these were created by other people: 1. a small modification to "oracle-instantclient-sqlplus" for supporting the Oracle runtime on hardened Gentoo. On non- hardened platforms the Oracle backend should work out of the box, because "oracle-instant-client-sqlplus" is already part of the portage tree. 2. "sqlncli" for supporting MS SQL Servers. This package isn't yet included in the portage tree. However, the files/patches needed to create or modify these packages are available from Gentoo's bugzilla: oracle-instantclient-sqlplus: https://bugs.gentoo.org/show_bug.cgi?id=456694 sqlncli: https://bugs.gentoo.org/show_bug.cgi?id=447288 unixODBC: https://bugs.gentoo.org/show_bug.cgi?id=456790 For those who can't wait for the official inclusion of odb, the easiest way is to unpack the tar archive into a directory under the home directory, e.g. into "~/gentoo/". and then add the line PORTDIR_OVERLAY="/home/your-account-name/gentoo/portage" to /etc/make.conf . tar will create a directory tree starting with portage/ while unpacking the archive. Knowing the root password you could then simply run $ sudo USE="postgres doc examples" emerge dev-db/odb for getting the ODB compiler with the PostgreSQL runtime installed. The odb-2.2.0 "ebuild" also supports the "test" option in FEATURES. Except for the SQLite backend, the odb test suite may only complete successfully, if a test database and a test user (+password) were created beforehand and if this information was passed to the installer within the "EXTRA_ECONF" variable. Example: $ sudo FEATURES="test" USE="mssql doc examples"\ EXTRA_ECONF="--with-mysql-db=test --with-mysql-user=test"\ emerge dev-db/odb A bug in Portage (this one: https://bugs.gentoo.org/show_bug.cgi?id=457508) currently prevents the use of single quotes for protecting parameters in EXTRA_ECONF containing blanks. So until the next version of sys-apps/portage is available please don't try to put anything like "--with-mssql-user='I\'m a Micrasaft user'" into EXTRA_ECONF, or else make will fail. The "--with-.*" options are those defined by odb-tests-2.0.0/configure. In the example above, if you had "postgres" in your USE flags (explicitly or implicitly via make.conf) and forgot to mention any "--with-pgsql-.*" options, the installation would abort early and show you a list of expected parameters instead. The mechanic behind this is implemented by a simplistic shell script, so don't expect a wrong or missing user or database name, password or host to be detected. The shell only checks if you mentioned at least one valid "--with-${db}-.*" parameter, with ${db} being determined by the active USE flags. It was implemented as a reminder only, because of the time needed to finally reach the state when the particular test suite gets runnable. From boris at codesynthesis.com Tue Feb 19 03:49:20 2013 From: boris at codesynthesis.com (Boris Kolpackov) Date: Tue Feb 19 03:49:28 2013 Subject: [odb-users] HDF5 support? In-Reply-To: <532C594B7920A549A2A91CB4312CC576140D6E8D@ECS-EXG-P-MB01.win.lanl.gov> References: <532C594B7920A549A2A91CB4312CC576140D54FE@ECS-EXG-P-MB01.win.lanl.gov> <532C594B7920A549A2A91CB4312CC576140D6E8D@ECS-EXG-P-MB01.win.lanl.gov> Message-ID: Hi Marcus, Daniels, Marcus G writes: > I'm not aware of anyone that uses HDF5 just as a file format anymore. > I know of some cases of HDF4 being written by multiple independent > clients, but HDF5 is a more complex standard and so I think everyone > uses their libraries. I didn't mean to say that we need to read the HDF5 file format ourselves. Rather, I was referring to the file format vs database distinction on a more conceptual level. I don't think HDF5 will fit into a database model (where we have such notions as database, connection, transaction, statement, etc) very well. Instead, I see it as a much simpler API, something along the lines: "save this object into this HDF5 output stream" and "load this object from this HDF5 input stream". This will also fit other "file formats", such as XML, JSON, etc. > The kind of parallelism I have in mind would be decomposition of very > large arrays. That is, suppose a X/Y/Z 3-d space is physically decomposed > along the Z dimension on large RAID array and a query is made to collect > a subspace of it. Further suppose that several servers were associated > with different parts of the Z dimension (each chunk of Z on a server > and over several hard drives). There would be parallelism collecting > the data for a partial Z chunk. With HDF5, this would be coordinated > over different ranks of a MPI process. Hm, not sure we want to get into all this MPI business with ODB. How is this handled in HDF5? Is it the HDF5 library that controls processes so that you basically give it the "memory regions" to fill and it does this in parallel. Or does it allow you to open several "parallel streams" and you can then read them from multiple processes that you control? In other words, if ODB provides basic support for object serialization to HDF5 streams, will this be sufficient to support parallelism? Boris From mdaniels at lanl.gov Tue Feb 19 10:28:44 2013 From: mdaniels at lanl.gov (Daniels, Marcus G) Date: Tue Feb 19 10:28:48 2013 Subject: [odb-users] HDF5 support? In-Reply-To: References: <532C594B7920A549A2A91CB4312CC576140D54FE@ECS-EXG-P-MB01.win.lanl.gov> <532C594B7920A549A2A91CB4312CC576140D6E8D@ECS-EXG-P-MB01.win.lanl.gov> Message-ID: <532C594B7920A549A2A91CB4312CC576140D88F3@ECS-EXG-P-MB01.win.lanl.gov> On Feb 19, 2013, at 1:49 AM, Boris Kolpackov wrote: > In other words, if ODB provides basic support for object serialization > to HDF5 streams, will this be sufficient to support parallelism? It's mostly the same. There's are (otherwise optional) arguments for property lists that are added to say what I/O mechanism to use, and various calls for tuning. I'm not sure how partial query and update would work. There's the possibility of using HDF5 in serial or parallel mode to request different slabs of a single multidimensional array. In the parallel case, different processes (MPI ranks) would work with different slabs. That would be analogous to accessing or updating just a part of, say, a Postgres array. Marcus From boris at codesynthesis.com Wed Feb 20 08:50:29 2013 From: boris at codesynthesis.com (Boris Kolpackov) Date: Wed Feb 20 08:50:38 2013 Subject: [odb-users] HDF5 support? In-Reply-To: <532C594B7920A549A2A91CB4312CC576140D88F3@ECS-EXG-P-MB01.win.lanl.gov> References: <532C594B7920A549A2A91CB4312CC576140D54FE@ECS-EXG-P-MB01.win.lanl.gov> <532C594B7920A549A2A91CB4312CC576140D6E8D@ECS-EXG-P-MB01.win.lanl.gov> <532C594B7920A549A2A91CB4312CC576140D88F3@ECS-EXG-P-MB01.win.lanl.gov> Message-ID: Hi Marcus, Daniels, Marcus G writes: > It's mostly the same. There's are (otherwise optional) arguments for > property lists that are added to say what I/O mechanism to use, and > various calls for tuning. I'm not sure how partial query and update > would work. There's the possibility of using HDF5 in serial or > parallel mode to request different slabs of a single multidimensional > array. In the parallel case, different processes (MPI ranks) would > work with different slabs. Yes, I am not clear on this either. I (or someone else who is keen to add HDF5 support to ODB) will need to understand this better. In the meantime, I've added HDF5 to our "potential file formats" list along with XML and JSON. Let's see how much interest there is in this support. Boris From boris at codesynthesis.com Thu Feb 21 05:52:47 2013 From: boris at codesynthesis.com (Boris Kolpackov) Date: Thu Feb 21 05:52:58 2013 Subject: [odb-users] libodb 2.2.2 bugfix released Message-ID: Hi, New bugfix release for the common ODB runtime library (libodb) is now available. It fixes an issue in queries when used with dynamic multi-database support. You can download the new packages from the ODB download page: http://www.codesynthesis.com/products/odb/download.xhtml SHA1 checksums for the files in this release are as follows: a89ee9c56ab3b087925156ab778f42012938d1be libodb-2.2.2.tar.bz2 f53bcbaac2d2fd4eb305eaedff7da4045cd648fe libodb-2.2.2.tar.gz a06d1dcaa880a9f026186cc5d831f572cd33f46f libodb-2.2.2.zip Boris From boris at codesynthesis.com Thu Feb 21 06:00:07 2013 From: boris at codesynthesis.com (Boris Kolpackov) Date: Thu Feb 21 06:00:13 2013 Subject: [odb-users] ODB compiler source 2.2.1 bugfix released Message-ID: Hi, A new bugfix release for the ODB compiler source package is now available. It fixes an issue with the libintl.h header when used together with GCC that was configured with --disable-nls. You only need to upgrade if (1) you are trying to build the ODB compiler from source code yourself (as opposed to using a binary package) and (2) you are experiencing errors pointing to libintl.h. For more information on this issue, refer to the following mailing list thread: http://www.codesynthesis.com/pipermail/odb-users/2013-February/001082.html You can download the new packages from the ODB download page: http://www.codesynthesis.com/products/odb/download.xhtml SHA1 checksums for the files in this release are as follows: 20ca253b22159ec5597d74c85c9a0de7f7d15a73 odb-2.2.1.tar.bz2 1174c6e6d3c1b0cda257d42004d6efdaa671b166 odb-2.2.1.tar.gz 96202b9124feeb561b7fa8fbc607725de216090e odb-2.2.1.zip Boris From boris at codesynthesis.com Thu Feb 21 06:46:36 2013 From: boris at codesynthesis.com (Boris Kolpackov) Date: Thu Feb 21 06:46:42 2013 Subject: [odb-users] [Search of feature] LIKE in the ODB query language In-Reply-To: References: Message-ID: Hi Florian, florian grignon writes: > I would be very glad to have your patch when you're done with it. Ok, I've added the SQL LIKE support for the next release (2.3.0). To try it with 2.2.0, you will need to do the following: 1. Apply the following patch to libodb-2.2.2: http://scm.codesynthesis.com/?p=odb/libodb.git;a=patch;h=4962329eecb716bc2b99810ec1ac4214606fc1e8 2. Apply the following patch to libodb-sqlite-2.2.0 (similar patches for all the other database runtimes are available): http://scm.codesynthesis.com/?p=odb/libodb-sqlite.git;a=patch;h=b580f1548ff335a0e1fa004fc6626486535c94e1 Once, this is done, you can use the new like() function like this: query::name.like ("J%"); Or, with the escape character: query::name.like ("%!_Doe", "!"); Let us know how it works for you. Boris From Hugo.Mildenberger at web.de Thu Feb 21 08:09:43 2013 From: Hugo.Mildenberger at web.de (Hugo.Mildenberger@web.de) Date: Thu Feb 21 09:00:27 2013 Subject: [odb-users] Help, how to generate the hxx files automately by odb In-Reply-To: References: <1360739763.19664.9.camel@localhost.localdomain> Message-ID: <20130221140943.d710c2812e6cb1b558a4a614@zotac.lan> > > I have a database based on mysql, how can i generate all hxx files > > by odb not by myself manually? > > No, this is not yet supported. We do have plans for an SQL-to-C++ > compiler, thought. I'd appreciate it very much if this functionality became integrated with ODB (and PostgreSQL). Such a program will foster a server-centric development style which in turn may result in a lean and consistent client - server interface, in enhanced maintainability, but also in a reduced network load if data processing is mainly done inside of stored procedures. Even updatable views spanning several tables are possible with a server-centric approach. But there would be also a great reduction of the effort required for the evaluation of a database design alternative (just run make once more to regenerate the client plugin), and unit-testing covering the whole client-server communication could be easily automated. In short, the integration of such a tool would mean a big relief to all those who have ever been forced to develop or maintain a poorly designed graphical user interface. Best From davejohansen at gmail.com Thu Feb 21 22:45:53 2013 From: davejohansen at gmail.com (Dave Johansen) Date: Thu Feb 21 22:45:59 2013 Subject: [odb-users] Build error on CentOS 6 In-Reply-To: References: Message-ID: On Mon, Feb 18, 2013 at 10:59 PM, Boris Kolpackov wrote: > > Hi Dave, > > Boris Kolpackov writes: > > > I am trying to confirm this on FC17 right now. > > I tried it on FC17 and everything builds fine, no undefined > pthread_cancel symbol. I also read that mailing list thread > further and it seems that they finally realized it is a bug > in the toolchain. See this post: > > http://lists.fedoraproject.org/pipermail/devel/2010-January/129131.html > > So I guess it has been fixed in later FC versions. Can you > confirm that everything builds fine on CentOS 6 if you pass > the --disable-threads option to libcutl configure? It did build just fine with the --disable-threads option, but I have two questions: 1) Does this disable any features or change any functionality? 2) Why wasn't this necessary with 1.7.0? It seems like a point release shouldn't have such big changes in the build behavior. From boris at codesynthesis.com Fri Feb 22 03:35:35 2013 From: boris at codesynthesis.com (Boris Kolpackov) Date: Fri Feb 22 03:35:43 2013 Subject: [odb-users] Build error on CentOS 6 In-Reply-To: References: Message-ID: Hi Dave, Dave Johansen writes: > It did build just fine with the --disable-threads option, but I have > two questions: > 1) Does this disable any features or change any functionality? No, the ODB compiler does not use threads so building libcutl with --disable-threads is actually an optimization. > 2) Why wasn't this necessary with 1.7.0? It seems like a point release > shouldn't have such big changes in the build behavior. The internal Boost subset that is part of libcutl uses threads by default. So the fact that libcutl wasn't linking to -lpthreads explicitly was actually a bug. Accidently, this fix triggered a bug in RH ld that we have discussed earlier. Boris From boris at codesynthesis.com Fri Feb 22 07:59:47 2013 From: boris at codesynthesis.com (Boris Kolpackov) Date: Fri Feb 22 07:59:55 2013 Subject: [odb-users] ODB compiler .deb and .rpm packages available Message-ID: Hi, ODB compiler packages for Debian/Ubuntu and RedHat(Fedora, RHEL, CentOS) are now available. These are essentially the binary packages of the ODB compiler re- packaged as .deb and .rpm to ease installation and maintenance. Just like the binary packages, they also include a private copy of the GCC binaries that are used internally by the ODB compiler. Note that you still need to build the ODB runtime libraries from source. As a result, these new packages are not meant to be a "final" solution to ODB packaging for Debian/Ubuntu and RedHat, which would also include .deb/.rpm packages for all the runtimes and use the stock GCC instead of distributing a private copy. Rather, these packages can be used while the proper packages are not yet available. They can also be used for legacy distributions for which proper packaging is not planned. You can download the new packages from the ODB download page: http://www.codesynthesis.com/products/odb/download.xhtml SHA1 checksums for the files in this release are as follows: f92f94d81a2a094c4be2f38d1d2bf8dd860f4074 odb_2.2.0-1_i386.deb 742edcf4cc1bf054ec2bc8bfa586d667c7093941 odb_2.2.0-1_amd64.deb a22cc1e2169619d9f70f40e1f0448445ba0784e0 odb-2.2.0-1.i686.rpm fe78b03fcc6cddb79651304d0d9f4d11154663c5 odb-2.2.0-1.x86_64.rpm Enjoy, Boris From boris at codesynthesis.com Fri Feb 22 14:52:56 2013 From: boris at codesynthesis.com (Boris Kolpackov) Date: Fri Feb 22 14:53:03 2013 Subject: [odb-users] Build error on CentOS 6 In-Reply-To: References: Message-ID: Hi Dave, Dave Johansen writes: > It did build just fine with the --disable-threads option, but I have > two questions: Just for completeness, if you don't want to build libcutl with threads disabled (e.g., because you plan to package it as well, instead of just linking it to ODB statically), then the other way to work around this issue would be to pass LIBS="-lpthread" to the ODB configure. Boris