From matthew at borgernet.com Thu May 1 20:46:34 2014 From: matthew at borgernet.com (Matthew Borger) Date: Fri May 2 11:32:15 2014 Subject: [odb-users] Bug Report: Multiple database command line arguments Message-ID: <5362EAEA.3040303@borgernet.com> Just wanted to report an interesting bug I found with the command line arguments to the odb executable. Given the following simple file, let's call it Foo.hpp: #pragma db object class Foo { public: #pragma db id long id; }; Now I want to make dynamic multiple database support for common and sqlite to simplify things. $> odb -d common -d sqlite --multi-database dynamic Foo.hpp This works as expected resulting in the following files. Foo-odb.cxx Foo-odb.ixx Foo-odb-sqlite.hxx Foo-odb.hxx Foo-odb-sqlite.cxx Foo-odb-sqlite.ixx But if I use the full argument for database, then odb seems to only create the files for the first database specified. $> odb --database common --database sqlite --multi-database dynamic Foo.hpp Generated files: Foo-odb.cxx Foo-odb.hxx Foo-odb.ixx $> odb --database sqlite --database common --multi-database dynamic Foo.hpp Generated files: Foo-odb-sqlite.cxx Foo-odb-sqlite.hxx Foo-odb-sqlite.ixx This was done on Ubuntu 14.04 using odb 2.3.0. The multi-database setting doesn't matter, the results are the same. Odb is a great product. Thank you for your efforts on it. Matt Borger -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3916 bytes Desc: S/MIME Cryptographic Signature Url : http://codesynthesis.com/pipermail/odb-users/attachments/20140501/82edccdb/smime.bin From boris at codesynthesis.com Fri May 2 11:50:40 2014 From: boris at codesynthesis.com (Boris Kolpackov) Date: Fri May 2 11:48:10 2014 Subject: [odb-users] Bug Report: Multiple database command line arguments In-Reply-To: <5362EAEA.3040303@borgernet.com> References: <5362EAEA.3040303@borgernet.com> Message-ID: Hi Matthew, Matthew Borger writes: > Just wanted to report an interesting bug I found with the command > line arguments to the odb executable. Indeed, thanks for the report! I've fixed it for the next release of ODB: http://scm.codesynthesis.com/?p=odb/odb.git;a=commit;h=e8c365d6d0ba4c969819b4c6aacab54ad7461a00 > Odb is a great product. Thank you for your efforts on it. Thanks, I am glad you are enjoying it. Boris From yo at miguelrevilla.com Mon May 5 06:01:03 2014 From: yo at miguelrevilla.com (=?UTF-8?Q?Miguel_Revilla_Rodr=C3=ADguez?=) Date: Mon May 5 06:01:10 2014 Subject: [odb-users] odb 2.3.0 can't compile with gcc 4.9.0 Message-ID: Hi, My distro has updated gcc to 4.9.0 and odb has stopped both working and compiling. We probably need a new release here. Anyway, thanks for the great work. Regards The compile errors: libtool: compile: g++ -DHAVE_CONFIG_H -I.. -I.. -D_FORTIFY_SOURCE=2 -I/usr/lib/gcc/x86_64-unknown-linux-gnu/4.9.0/plugin/include -march=x86-64 -mtune=generic -O2 -pipe -fstack-protector --param=ssp-buffer-size=4 -MT common.lo -MD -MP -MF .deps/common.Tpo -c common.cxx -fPIC -DPIC -o .libs/common.o In file included from ../odb/gcc-fwd.hxx:10:0, from ../odb/gcc.hxx:8, from cxx-lexer.cxx:5: /usr/lib/gcc/x86_64-unknown-linux-gnu/4.9.0/plugin/include/coretypes.h:46:9: error: 'HOST_WIDEST_INT' does not name a type typedef HOST_WIDEST_INT gcov_type; ^ /usr/lib/gcc/x86_64-unknown-linux-gnu/4.9.0/plugin/include/coretypes.h:47:34: error: expected initializer before 'gcov_type_unsigned' typedef unsigned HOST_WIDEST_INT gcov_type_unsigned; ^ cxx-lexer.cxx: In member function 'virtual cpp_ttype cxx_string_lexer::next(std::string&, tree_node**)': cxx-lexer.cxx:266:36: error: 'get_identifier' was not declared in this scope tree id (get_identifier (name)); ^ Makefile:947: recipe for target 'cxx-lexer.lo' failed make[2]: *** [cxx-lexer.lo] Error 1 make[2]: *** Se espera a que terminen otras tareas.... In file included from ../odb/gcc-fwd.hxx:10:0, from ../odb/gcc.hxx:8, from context.cxx:5: /usr/lib/gcc/x86_64-unknown-linux-gnu/4.9.0/plugin/include/coretypes.h:46:9: error: 'HOST_WIDEST_INT' does not name a type typedef HOST_WIDEST_INT gcov_type; ^ /usr/lib/gcc/x86_64-unknown-linux-gnu/4.9.0/plugin/include/coretypes.h:47:34: error: expected initializer before 'gcov_type_unsigned' typedef unsigned HOST_WIDEST_INT gcov_type_unsigned; ^ In file included from ../odb/gcc-fwd.hxx:10:0, from ../odb/context.hxx:8, from ../odb/common.hxx:13, from common.cxx:5: /usr/lib/gcc/x86_64-unknown-linux-gnu/4.9.0/plugin/include/coretypes.h:46:9: error: 'HOST_WIDEST_INT' does not name a type typedef HOST_WIDEST_INT gcov_type; ^ /usr/lib/gcc/x86_64-unknown-linux-gnu/4.9.0/plugin/include/coretypes.h:47:34: error: expected initializer before 'gcov_type_unsigned' typedef unsigned HOST_WIDEST_INT gcov_type_unsigned; ^ Makefile:947: recipe for target 'common.lo' failed make[2]: *** [common.lo] Error 1 Makefile:947: recipe for target 'context.lo' failed make[2]: *** [context.lo] Error 1 make[2]: Leaving directory '/home/tmp/yaourt-tmp-root/aur-odb/src/odb-2.3.0/odb' Makefile:426: recipe for target 'all' failed make[1]: *** [all] Error 2 make[1]: Leaving directory '/home/tmp/yaourt-tmp-root/aur-odb/src/odb-2.3.0/odb' Makefile:373: recipe for target 'all-recursive' failed make: *** [all-recursive] Error 1 From boris at codesynthesis.com Tue May 6 20:27:20 2014 From: boris at codesynthesis.com (Boris Kolpackov) Date: Tue May 6 20:24:51 2014 Subject: [odb-users] odb 2.3.0 can't compile with gcc 4.9.0 In-Reply-To: References: Message-ID: <20140507002720.GA5942@codesynthesis.com> Hi Miguel, Miguel Revilla Rodr?guez writes: > My distro has updated gcc to 4.9.0 and odb has stopped both working and > compiling. I actually tried to avoid this by testing each ODB release with the latest GCC snapshot. That didn't help much. Oh, well... In any case, I've updated the source code to work with GCC 4.9.0. The patch for ODB 2.3.0 is here: http://codesynthesis.com/~boris/tmp/odb/odb-2.3.0-gcc-4.9.0.patch Thanks for the bug report and let me know if you run into any other problems. Boris From yo at miguelrevilla.com Tue May 6 20:48:48 2014 From: yo at miguelrevilla.com (=?UTF-8?Q?Miguel_Revilla_Rodr=C3=ADguez?=) Date: Tue May 6 20:48:55 2014 Subject: [odb-users] odb 2.3.0 can't compile with gcc 4.9.0 In-Reply-To: <20140507002720.GA5942@codesynthesis.com> References: <20140507002720.GA5942@codesynthesis.com> Message-ID: Hi Boris, Thanks for the patch. Now I'm getting this, but I'm not really sure if it is related to your code (this is the second try to compile, hence a lot of compiler output is not here, just the error): # make -j1 Making all in odb make[1]: Entering directory '/usr/local/install/packages/aur/odb/src/odb-2.3.0/odb' make all-am make[2]: Entering directory '/usr/local/install/packages/aur/odb/src/odb-2.3.0/odb' depbase=`echo validator.lo | sed 's|[^/]*$|.deps/&|;s|\.lo$||'`;\ /bin/sh ../libtool --tag=CXX --mode=compile g++ -DHAVE_CONFIG_H -I'..' -I'..' -D_FORTIFY_SOURCE=2 -I/usr/lib/gcc/x86_64-unknown-linux-gnu/4.9.0/plugin/include -march=x86-64 -mtune=generic -O2 -pipe -fstack-protector --param=ssp-buffer-size=4 -MT validator.lo -MD -MP -MF $depbase.Tpo -c -o validator.lo validator.cxx &&\ mv -f $depbase.Tpo $depbase.Plo libtool: compile: g++ -DHAVE_CONFIG_H -I.. -I.. -D_FORTIFY_SOURCE=2 -I/usr/lib/gcc/x86_64-unknown-linux-gnu/4.9.0/plugin/include -march=x86-64 -mtune=generic -O2 -pipe -fstack-protector --param=ssp-buffer-size=4 -MT validator.lo -MD -MP -MF .deps/validator.Tpo -c validator.cxx -fPIC -DPIC -o .libs/validator.o validator.cxx:1575:1: internal compiler error: in possible_polymorphic_call_targets, at ipa-devirt.c:1539 } ^ Please submit a full bug report, with preprocessed source if appropriate. See for instructions. Makefile:947: recipe for target 'validator.lo' failed make[2]: *** [validator.lo] Error 1 make[2]: Leaving directory '/usr/local/install/packages/aur/odb/src/odb-2.3.0/odb' Makefile:426: recipe for target 'all' failed make[1]: *** [all] Error 2 make[1]: Leaving directory '/usr/local/install/packages/aur/odb/src/odb-2.3.0/odb' Makefile:373: recipe for target 'all-recursive' failed make: *** [all-recursive] Error 1 2014-05-07 2:27 GMT+02:00 Boris Kolpackov : > Hi Miguel, > > Miguel Revilla Rodr?guez writes: > > > My distro has updated gcc to 4.9.0 and odb has stopped both working and > > compiling. > > I actually tried to avoid this by testing each ODB release with the > latest GCC snapshot. That didn't help much. Oh, well... > > In any case, I've updated the source code to work with GCC 4.9.0. The > patch for ODB 2.3.0 is here: > > http://codesynthesis.com/~boris/tmp/odb/odb-2.3.0-gcc-4.9.0.patch > > Thanks for the bug report and let me know if you run into any other > problems. > > Boris > From boris at codesynthesis.com Tue May 6 20:58:23 2014 From: boris at codesynthesis.com (Boris Kolpackov) Date: Tue May 6 20:55:53 2014 Subject: [odb-users] odb 2.3.0 can't compile with gcc 4.9.0 In-Reply-To: References: <20140507002720.GA5942@codesynthesis.com> Message-ID: Hi Miguel, Miguel Revilla Rodr?guez writes: > g++ -DHAVE_CONFIG_H -I.. -I.. -D_FORTIFY_SOURCE=2 > -I/usr/lib/gcc/x86_64-unknown-linux-gnu/4.9.0/plugin/include -march=x86-64 > -mtune=generic -O2 -pipe -fstack-protector --param=ssp-buffer-size=4 -MT > validator.lo -MD -MP -MF .deps/validator.Tpo -c validator.cxx -fPIC -DPIC > -o .libs/validator.o > validator.cxx:1575:1: internal compiler error: in > possible_polymorphic_call_targets, at ipa-devirt.c:1539 This looks like a bug in GCC 4.9.0. The two things that you would want to do: 1. Submit the bug report to GCC. 2. Disable validation when building ODB. I built it without optimization and haven't hit this issue which appears to in the inter-procedure optimization (ipa) code. Boris From yo at miguelrevilla.com Tue May 6 21:04:16 2014 From: yo at miguelrevilla.com (=?UTF-8?Q?Miguel_Revilla_Rodr=C3=ADguez?=) Date: Tue May 6 21:04:23 2014 Subject: [odb-users] odb 2.3.0 can't compile with gcc 4.9.0 In-Reply-To: References: <20140507002720.GA5942@codesynthesis.com> Message-ID: Hi again, I just found that the bug is already reported and scheduled for fix in 4.9.1. Thanks for your help, Miguel 2014-05-07 2:58 GMT+02:00 Boris Kolpackov : > Hi Miguel, > > Miguel Revilla Rodr?guez writes: > > > g++ -DHAVE_CONFIG_H -I.. -I.. -D_FORTIFY_SOURCE=2 > > -I/usr/lib/gcc/x86_64-unknown-linux-gnu/4.9.0/plugin/include > -march=x86-64 > > -mtune=generic -O2 -pipe -fstack-protector --param=ssp-buffer-size=4 -MT > > validator.lo -MD -MP -MF .deps/validator.Tpo -c validator.cxx -fPIC > -DPIC > > -o .libs/validator.o > > validator.cxx:1575:1: internal compiler error: in > > possible_polymorphic_call_targets, at ipa-devirt.c:1539 > > This looks like a bug in GCC 4.9.0. The two things that you would > want to do: > > 1. Submit the bug report to GCC. > > 2. Disable validation when building ODB. I built it without optimization > and haven't hit this issue which appears to in the inter-procedure > optimization (ipa) code. > > Boris > From axel50397 at gmail.com Thu May 8 19:01:47 2014 From: axel50397 at gmail.com (Adnan RIHAN) Date: Thu May 8 19:02:11 2014 Subject: [odb-users] Build libodbc-qt on OSX with Qt5.2.1 Message-ID: Hello everybody ! I?ve discovered libodb few days ago and I?m really excited to try it instead of writing my own ORM (what I was doing when I told myself there?s too much to do in a short time?). Anyway, I?m on a freshly installed OSX + Qt5.2.1 I?m trying to build the Qt?s profile but QtCore isn?t found and I can?t make it find Qt with CPP/LDFLAGS. Can anyone tell me what should I type or do to make ??configure?? find Qt please? Thanks. -- Regards, Adnan RIHAN. From boris at codesynthesis.com Thu May 8 22:40:59 2014 From: boris at codesynthesis.com (Boris Kolpackov) Date: Thu May 8 22:38:28 2014 Subject: [odb-users] Build libodbc-qt on OSX with Qt5.2.1 In-Reply-To: References: Message-ID: Hi Adnan, Adnan RIHAN writes: > I?m trying to build the Qt?s profile but QtCore isn?t found > and I can?t make it find Qt with CPP/LDFLAGS. Can anyone tell > me what should I type or do to make configure find Qt please? First, do you know where your Qt headers and libraries are installed? For headers you need to find the directory that contains the QtCore sub-directory and inside it files such as QString, QList, etc. Let's say this directory is called /test/Qt/include/ so you have /test/Qt/include/QtCore/QString. For libraries, you need to find the directory containing libQtCore.dylib* or libQtCore.a. Let's say this directory is called /test/Qt/lib/ so you have /test/Qt/lib/libQtCore.dylib. Once you determined these directories, run configure like this: ./configure CPPFLAGS=-I/test/Qt/include LDFLAGS=-L/test/Qt/lib If this still doesn't work, look into the config.log file created by configure. It contains more detailed information on why configure still cannot find Qt. Search for 'QtCore' to find the relevant part in this file. If you see some error messages in config.log that you cannot figure out how to fix, send them to the mailing list and we will try to help. Boris From axel50397 at gmail.com Fri May 9 04:46:47 2014 From: axel50397 at gmail.com (Adnan RIHAN) Date: Fri May 9 04:47:12 2014 Subject: [odb-users] Build libodbc-qt on OSX with Qt5.2.1 In-Reply-To: References: Message-ID: Hi Boris, Le 9 mai 2014 ? 04:38:27, Boris Kolpackov (boris@codesynthesis.com) a ?crit: > ./configure CPPFLAGS=-I/test/Qt/include LDFLAGS=-L/test/Qt/lib Thanks for your answer but I forgot to mention that on OSX, Qt5.2 is shipped by default compiled as framework, so I don?t have files in /include (some folders [3], but not Qt?s includes) and I have *.framework/ folders in /lib. A .framework is structured as this: QtCore.framework |-- Contents/ (Contains only a .plist) |-- @Headers/ (Points to Versions/Current/Headers) |-- @QtCore (Points to Versions/Current/QtCore) |-- @QtCore_debug (Points to Versions/Current/QtCore_debug) |-- QtCore_debug.prl |-- QtCore.prl |-- Versions/ ? ? |-- 5/ ? ? ? ? |-- Headers (Contains the headers) ? ? ? ? |-- QtCore (Binary, certainly the lib) ? ? ? ? |-- QtCore_debug (Same as QtCore) ? ? |-- @Current/ (Points to 5/) So I think that due to this structure, the CPPFLAGS/LDFLAGS may be less simple that /include and /lib, but I can?t find. Even that failed: >?./configure CPPFLAGS=-I/Users/Max13/Qt/5.2.1/clang_64/lib/QtCore.framework/Headers LDFLAGS=-L/Users/Max13/Qt/5.2.1/clang_64/lib/QtCore.framework In case of, this is the config.log:?http://pastebin.com/PKZDGS7F It says is can?t find "", but with Frameworks we directly have access to "" and I don?t know how (if possible) to tell ./configure to include directly the header without the QtCore prefix, instead of removing it by hand... -- Regards, Adnan RIHAN. From boris at codesynthesis.com Fri May 9 15:15:39 2014 From: boris at codesynthesis.com (Boris Kolpackov) Date: Fri May 9 15:13:08 2014 Subject: [odb-users] Build libodbc-qt on OSX with Qt5.2.1 In-Reply-To: References: Message-ID: Hi Adnan, Adnan RIHAN writes: > It says is can?t find "", but with Frameworks we > directly have access to "" ODB actually knows about frameworks and configure tries to use the -framework option. This works with Qt 4.x packaged as a framework and the main reason we include Qt headers with the QtCore/ prefix is because that's the only way to make it work with Qt 4.x as a framework. And it seems they have changed that in Qt 5.x to be completely opposite. Can you confirm this for me by trying to build the following two sample programs: // sample1.cxx #include int main () {} // sample2.cxx #include int main () {} Can you try the following compiler invocations and tell me which work for you? clang++ -c sample1.cxx clang++ -framework QtCore sample1.o clang++ -framework QtCore -c sample1.cxx clang++ -framework QtCore sample1.o clang++ -c sample2.cxx clang++ -framework QtCore sample2.o clang++ -framework QtCore -c sample2.cxx clang++ -framework QtCore sample2.o Boris From axel50397 at gmail.com Fri May 9 20:39:30 2014 From: axel50397 at gmail.com (Adnan RIHAN) Date: Fri May 9 20:39:57 2014 Subject: [odb-users] Build libodbc-qt on OSX with Qt5.2.1 In-Reply-To: References: Message-ID: Qt is not installed in system directories (/usr/include | /usr/lib) by default (At least on OSX and Windows), so I have to precise my lib dir when using clang++ (Without -F, all return errors). Le 9 mai 2014 ? 21:13:07, Boris Kolpackov (boris@codesynthesis.com) a ?crit: > clang++ -F/Users/Max13/Qt/5.2.1/clang_64/lib -c sample1.cxx > clang++ -F/Users/Max13/Qt/5.2.1/clang_64/lib -framework QtCore sample1.o OK > clang++ -F/Users/Max13/Qt/5.2.1/clang_64/lib -framework QtCore -c sample1.cxx clang: warning: -framework QtCore: 'linker' input unused > clang++ -F/Users/Max13/Qt/5.2.1/clang_64/lib -framework QtCore sample1.o OK > clang++ -F/Users/Max13/Qt/5.2.1/clang_64/lib -c sample2.cxx sample2.cxx:1:10: fatal error: 'QString' file not found > clang++ -F/Users/Max13/Qt/5.2.1/clang_64/lib -framework QtCore -c sample2.cxx clang: warning: -framework QtCore: 'linker' input unused sample2.cxx:1:10: fatal error: 'QString' file not found It seems to be the same after all. I wonder why I don?t have to prefix ??QtCore?? when including ??QString?? for example, and I noticed that QtCreator automatically adds every framework's headers directory. -- Regards, Adnan RIHAN. From boris at codesynthesis.com Fri May 9 21:53:55 2014 From: boris at codesynthesis.com (Boris Kolpackov) Date: Fri May 9 21:51:26 2014 Subject: [odb-users] Build libodbc-qt on OSX with Qt5.2.1 In-Reply-To: References: Message-ID: Hi Adnan, Adnan RIHAN writes: > Qt is not installed in system directories (/usr/include | /usr/lib) by > default (At least on OSX and Windows), so I have to precise my lib dir > when using clang++ (Without -F, all return errors). > > > clang++ -F/Users/Max13/Qt/5.2.1/clang_64/lib -c sample1.cxx > > clang++ -F/Users/Max13/Qt/5.2.1/clang_64/lib -framework QtCore sample1.o > OK Then this should work for libodb-qt: ./configure CPPFLAGS=-F/Users/Max13/Qt/5.2.1/clang_64/lib The only reason I can think of why this might not work is if libtool doesn't pass the -F option through to clang. > It seems to be the same after all. I wonder why I don?t have to > prefix QtCore when including QString for example, and I > noticed that QtCreator automatically adds every framework's headers > directory. Well, remember, you asked for it: ;-) If you look around in the documentation, Qt folks tell you to include it as . But if you look into Qt's own code, they include everything as (do as I say, not as I do). If we follow their advise, to make the whole thing work, we have to add two -I options: one that goes all the way to .../QtCore (so that our includes compile) and one to one level up (so that the Qt's includes compile). Except that Qt 4.x packaged as a framework only added one -I option, the "level up" one. That's why ODB includes all the Qt headers with the prefix. They seem to have fixed this in Qt 5.x. To sum it all up in one word: mess. Boris From axel50397 at gmail.com Sat May 10 08:53:27 2014 From: axel50397 at gmail.com (Adnan RIHAN) Date: Sat May 10 08:53:54 2014 Subject: [odb-users] Build libodbc-qt on OSX with Qt5.2.1 In-Reply-To: References: Message-ID: Le 10 mai 2014 ? 03:51:25, Boris Kolpackov (boris@codesynthesis.com) a ?crit: > Then this should work for libodb-qt: > > ./configure CPPFLAGS=-F/Users/Max13/Qt/5.2.1/clang_64/lib Unfortunately, it doesn?t work :( Do you have a workaround or is it a bug that can be fixed by codesynthesis? Thanks for the info about the ??mess?? ;) PS: My current was to download the sources by the maintainer tools, and to compile/link to precompiled Qt (in sources, the libs are not as frameworks) but I didn?t test it yet, I?m just beginning reading the doc. -- Regards, Adnan RIHAN. From boris at codesynthesis.com Sat May 10 12:24:39 2014 From: boris at codesynthesis.com (Boris Kolpackov) Date: Sat May 10 12:22:07 2014 Subject: [odb-users] Build libodbc-qt on OSX with Qt5.2.1 In-Reply-To: References: Message-ID: Hi Adnan, Adnan RIHAN writes: > > ./configure CPPFLAGS=-F/Users/Max13/Qt/5.2.1/clang_64/lib > > Unfortunately, it doesn?t work :( Can you send the config.log file for this invocation of configure? Boris From axel50397 at gmail.com Sat May 10 12:26:49 2014 From: axel50397 at gmail.com (Adnan RIHAN) Date: Sat May 10 12:27:16 2014 Subject: [odb-users] Build libodbc-qt on OSX with Qt5.2.1 In-Reply-To: References: Message-ID: Hi, Le 10 mai 2014 ? 18:22:06, Boris Kolpackov (boris@codesynthesis.com) a ?crit: > Hi Adnan, > > ./configure CPPFLAGS=-F/Users/Max13/Qt/5.2.1/clang_64/lib > Can you send the config.log file for this invocation of configure? > > Boris > http://pastebin.com/0Dwzaq5a -- Regards, Adnan RIHAN. From boris at codesynthesis.com Sat May 10 12:47:41 2014 From: boris at codesynthesis.com (Boris Kolpackov) Date: Sat May 10 12:45:10 2014 Subject: [odb-users] Build libodbc-qt on OSX with Qt5.2.1 In-Reply-To: References: Message-ID: Hi Adnan, Ok, I think we are getting close. Here is the configure test that I expect to succeed: configure:17847: g++ -c -g -O2 -D_THREAD_SAFE -F/Users/Max13/Qt/5.2.1/clang_64/lib conftest.cpp >&5 configure:17847: $? = 0 configure:17854: ./libtool --tag=CXX --mode=link g++ -no-install -g -O2 -D_THREAD_SAFE -o conftest conftest.o -framework QtCore -lpthread >&5 libtool: link: g++ -g -O2 -D_THREAD_SAFE -o conftest conftest.o -Wl,-bind_at_load -framework QtCore -lpthread ld: framework not found QtCore The only difference between these command lines and your tests is the lack of the -F option in the linker invocation. So let's try to add that: ./configure CPPFLAGS=-F/Users/Max13/Qt/5.2.1/clang_64/lib LDFLAGS=-F/Users/Max13/Qt/5.2.1/clang_64/lib Boris From axel50397 at gmail.com Sat May 10 12:50:15 2014 From: axel50397 at gmail.com (Adnan RIHAN) Date: Sat May 10 12:50:41 2014 Subject: [odb-users] Build libodbc-qt on OSX with Qt5.2.1 In-Reply-To: References: Message-ID: \o/ Le 10 mai 2014 ? 18:45:09, Boris Kolpackov (boris@codesynthesis.com) a ?crit: > ./configure CPPFLAGS=-F/Users/Max13/Qt/5.2.1/clang_64/lib LDFLAGS=-F/Users/Max13/Qt/5.2.1/clang_64/lib It works, thank you ! It?s not really hard to do, but do you think I can send a feature request to codesynthesis to add an option ???with-qtdir= ? (which expects the clang_64 dir) and/or make it use the $QTDIR env variable? -- Regards, Adnan RIHAN. From boris at codesynthesis.com Sun May 11 00:01:47 2014 From: boris at codesynthesis.com (Boris Kolpackov) Date: Sat May 10 23:59:15 2014 Subject: [odb-users] Build libodbc-qt on OSX with Qt5.2.1 In-Reply-To: References: Message-ID: Hi Adnan, Adnan RIHAN writes: > It?s not really hard to do, but do you think I can send a feature > request to codesynthesis to add an option ?with-qtdir= (which expects > the clang_64 dir) and/or make it use the $QTDIR env variable? The code already passes all the necessary options (i.e., -framework) to make everything work by default in the "normal" situation. And by normal I mean the compiler can find the Qt framework without any extra -F options. In your case you have installed the framework or the compiler, or both (or there is something else broken, who knows) so that things are not found by default. It is easy to take care by passing the -F option and adding a special configure option just for this situation and just for OS X (the whole framework stuff is OS X-specific) doesn't seem like a good idea to me. Boris From axel50397 at gmail.com Sun May 11 08:05:50 2014 From: axel50397 at gmail.com (Adnan RIHAN) Date: Sun May 11 08:06:16 2014 Subject: [odb-users] Build libodbc-qt on OSX with Qt5.2.1 In-Reply-To: References: Message-ID: Hello, Le 11 mai 2014 ? 05:59:14, Boris Kolpackov (boris@codesynthesis.com) a ?crit: > In your case you have installed the framework or the compiler, or > both (or there is something else broken, who knows) so that things > are not found by default. I understand but currently, it will be the default behavior and directory structure on OSX. Qt (Qt installer) doesn?t install itself in system directories anymore, and unless you compile it yourself, you _will_ have to add CPPFLAGS/LDFLAGS to your Qt?s lib directory every time. I understand that adding something for OSX doesn?t seem legitimate, but as for windows (which doesn?t have /usr/include or /usr/lib) and requires a special treatment, I think that because ??adding CPPFLAGS/LDFLAGS by hand?? will be mandatory for OSX users, it should be something cared by the tool. Anyway, it?s your choice but at least, please add a note for OSX users in the INSTALL file. Thanks for your help. I will now get my hands in it :D -- Regards, Adnan RIHAN. From andrew at nelless.net Sun May 11 10:01:39 2014 From: andrew at nelless.net (Andrew) Date: Sun May 11 10:05:09 2014 Subject: [odb-users] Re: odb 2.3.0 can't compile with gcc 4.9.0 References: <20140507002720.GA5942@codesynthesis.com> Message-ID: -fno-devirtualize in CXXFLAGS will work around this issue until it's fixed. Tested with a patched PKGBUILD on Arch. From ogaro at unileon.es Mon May 12 05:30:32 2014 From: ogaro at unileon.es (=?windows-1252?Q?Oscar_Garc=EDa-Olalla_Olivera?=) Date: Mon May 12 05:30:40 2014 Subject: [odb-users] Ignore an attribute Message-ID: Hi, there is any possibility of not persist an attribute. I have an abstract class which needs a concrete attribute but I don?t want that this one appear in the sons table because it is just an auxiliary attribute. how can I do it? Thanks a lot. Oscar From feisal.ahmad at ps-tech.com Mon May 12 08:59:43 2014 From: feisal.ahmad at ps-tech.com (Feisal Ahmad) Date: Mon May 12 08:59:54 2014 Subject: [odb-users] Ignore an attribute In-Reply-To: References: Message-ID: <5370C5BF.3000805@ps-tech.com> Hi, Just use the following pragma to mark it as non-persistent #pragma db transient Greetings, Feisal On 5/12/2014 4:30, Oscar Garc?a-Olalla Olivera wrote: > Hi, there is any possibility of not persist an attribute. I have an abstract class which needs a concrete attribute but I don?t want that this one appear in the sons table because it is just an auxiliary attribute. how can I do it? > > Thanks a lot. > > Oscar > From finjulhich at gmail.com Thu May 15 09:29:06 2014 From: finjulhich at gmail.com (MM) Date: Thu May 15 09:29:14 2014 Subject: [odb-users] design questions: c++ / python / sqlite Message-ID: Hello, I currently have a C++ application with a number of objects ( plain structs with primitive types, classes with the 2 types of polymorphism mentioned in the odb manual, smart pointers (std and boost), containers std and boost::containers ) and I need to store all these objects in sqlite. Part of the application is code in python as well that would read/write the sqlite db with the native python sqlite package. The members of my classes change occasionally, so I would use the schema evolution feature of generating the tables from the odb compiler. Typically, the python code can read/write a number of the above classes. The question is general in itself: What should the order of things be? 1. Step by step addition of odb pragmas to the C++ code to generate the sql tables? 2. Use of these tables from python, perhaps through some c++/python adapter like swig or some layer like that? I am looking really for general thoughts rather than specifics here. Thanks MM From boris at codesynthesis.com Fri May 16 00:09:37 2014 From: boris at codesynthesis.com (Boris Kolpackov) Date: Fri May 16 00:07:04 2014 Subject: [odb-users] design questions: c++ / python / sqlite In-Reply-To: References: Message-ID: Hi, MM writes: > The question is general in itself: What should the order of things be? > > 1. Step by step addition of odb pragmas to the C++ code to generate the sql > tables? > 2. Use of these tables from python, perhaps through some c++/python adapter > like swig or some layer like that? If you want ODB schema evolution support then ODB will have to generate and maintain the database schema. Or, to put it another way, your C++ classes will have to be the "primary specification" of your data model. The good news is that ODB generates pretty idiomatic SQL (in other words, something that a database administrator would normally write by hand). You can also customize the resulting schema with the various pragmas, if you wish. Regarding the Python part, I would suggest that you use one of the Python database access packages (I have heard there are some good ones) rather than try to access the C++ classes or the ODB API via something like Swig, etc. Unless you for some reason need to modify the C++ class state in the application's memory rather than in the database. And in that case I would probably look into Boost.Python first. Boris From finjulhich at gmail.com Thu May 22 12:49:16 2014 From: finjulhich at gmail.com (MM) Date: Thu May 22 12:49:24 2014 Subject: [odb-users] design questions: c++ / python / sqlite In-Reply-To: References: Message-ID: On 16 May 2014 05:09, Boris Kolpackov wrote: > Hi, > > MM writes: > > > The question is general in itself: What should the order of things be? > > > > 1. Step by step addition of odb pragmas to the C++ code to generate the > sql > > tables? > > 2. Use of these tables from python, perhaps through some c++/python > adapter > > like swig or some layer like that? > > If you want ODB schema evolution support then ODB will have to generate > and maintain the database schema. Or, to put it another way, your C++ > classes will have to be the "primary specification" of your data model. > The good news is that ODB generates pretty idiomatic SQL (in other words, > something that a database administrator would normally write by hand). > You can also customize the resulting schema with the various pragmas, > if you wish. > Ok, so ODB will master the db generation. Regarding the Python part, I would suggest that you use one of the > Python database access packages (I have heard there are some good > ones) rather than try to access the C++ classes or the ODB API via > something like Swig, etc. Unless you for some reason need to modify > the C++ class state in the application's memory rather than in the > database. And in that case I would probably look into Boost.Python > first. > I just meant that a given class is defined in C++. I would expose that class in python with boost.python perhaps, and then use those classes in python to access the sqlite db through python.sqlite > > Boris > Another question: I have ABClass (with pure virtual fcts, and protected data members: name and other things.) -> Derived1 : public ABClass -> Derived2: public ABClass ... -> Derived10: public ABClass In practise, I have only singletons of Derived1...Derived10. One instance of each. They implement the base's virtual fcts and use the proctected data members for that. Is there a way to make this map to a single table that holds 10 rows where the primary key is name, and the other things are other columns, and yet on loading back from the table, that the correct concrete instances are created? If not, how to change my simple class hierarchy? Thanks From boris at codesynthesis.com Thu May 22 14:47:52 2014 From: boris at codesynthesis.com (Boris Kolpackov) Date: Thu May 22 14:45:18 2014 Subject: [odb-users] design questions: c++ / python / sqlite In-Reply-To: References: Message-ID: Hi, MM writes: > I just meant that a given class is defined in C++. I would expose that > class in python with boost.python perhaps, and then use those classes in > python to access the sqlite db through python.sqlite This doesn't make much sense to me. You have C++ classes that you can persist in the database with ODB. You expose them to python via Boost.Python. You then use these classes and SQLite support in Python to access their state in database? Why? That is already handled by ODB on the C++ side. > Is there a way to make this map to a single table that holds 10 rows where > the primary key is name, and the other things are other columns, and yet on > loading back from the table, that the correct concrete instances are > created? What you are looking for is the table-per-hierarchy mapping for inheritance. This is currently not supported by ODB. See Section 8.2, "Polymorphism Inheritance" in the ODB manual for details. > If not, how to change my simple class hierarchy? You don't really have to change anything. Just use the table-per- difference mapping supported by ODB. You will end up with some extra tables that (seemingly) are not necessary, but other than that, everything will work as expected. In fact, the root table will look as if you were using the table-per-hierarchy mapping so if your Python code only needs to read the data, then you can treat it in Python as such. Boris From finjulhich at gmail.com Thu May 22 17:31:09 2014 From: finjulhich at gmail.com (MM) Date: Thu May 22 17:31:15 2014 Subject: [odb-users] design questions: c++ / python / sqlite In-Reply-To: References: Message-ID: On 22 May 2014 19:47, Boris Kolpackov wrote: > > I just meant that a given class is defined in C++. I would expose that > > class in python with boost.python perhaps, and then use those classes in > > python to access the sqlite db through python.sqlite > > This doesn't make much sense to me. You have C++ classes that you > can persist in the database with ODB. You expose them to python via > Boost.Python. You then use these classes and SQLite support in Python > to access their state in database? Why? That is already handled by ODB > on the C++ side. > I'm sorry, I may have made a mistake in what I said before. The python code would fill up the existing tables that have been generated from ODB, with data. I write the sqlite also from python. To do that, I would need to know the columns of the tables. Having the C++ class that odb used to generate the table, exposed as a python class, should help for my python code to write to the tables? The C++ part then reads and writes the data too. If it can't be done, then I could duplicate the members of each table in the python code as well. > > Is there a way to make this map to a single table that holds 10 rows > where > > the primary key is name, and the other things are other columns, and yet > on > > loading back from the table, that the correct concrete instances are > > created? > > What you are looking for is the table-per-hierarchy mapping for > inheritance. This is currently not supported by ODB. See Section > 8.2, "Polymorphism Inheritance" in the ODB manual for details. > > > > If not, how to change my simple class hierarchy? > > You don't really have to change anything. Just use the table-per- > difference mapping supported by ODB. You will end up with some > extra tables that (seemingly) are not necessary, but other than > that, everything will work as expected. In fact, the root table > will look as if you were using the table-per-hierarchy mapping > so if your Python code only needs to read the data, then you > can treat it in Python as such. > All right. I'll see what pragmas for the ABC if any, and what pragmas for the derived classes. > Boris > Thanks From boris at codesynthesis.com Fri May 23 12:58:36 2014 From: boris at codesynthesis.com (Boris Kolpackov) Date: Fri May 23 12:56:02 2014 Subject: [odb-users] design questions: c++ / python / sqlite In-Reply-To: References: Message-ID: Hi, MM writes: > The python code would fill up the existing tables that have been generated > from ODB, with data. I write the sqlite also from python. To do that, I > would need to know the columns of the tables. Having the C++ class that > odb used to generate the table, exposed as a python class, should help for > my python code to write to the tables? Hm, that sounds like a very complicated way to get a list of columns in Python. Instead, you could query the database to get the list of columns for a table, their datatypes, etc. All the databases that ODB currently supports have the ability to retrieve this meta-data. Boris From finjulhich at gmail.com Fri May 23 14:47:21 2014 From: finjulhich at gmail.com (MM) Date: Fri May 23 14:47:29 2014 Subject: [odb-users] design questions: c++ / python / sqlite In-Reply-To: References: Message-ID: ok, that's perhaps easier than using boost.python... I was thinking of consistency. indeed if I change the c++ class, the odb will handle that for the tables too, and so the python will get these changes next time it runs the meta data checks. Thanks, On 23 May 2014 17:58, Boris Kolpackov wrote: > Hi, > > MM writes: > > > The python code would fill up the existing tables that have been > generated > > from ODB, with data. I write the sqlite also from python. To do that, I > > would need to know the columns of the tables. Having the C++ class that > > odb used to generate the table, exposed as a python class, should help > for > > my python code to write to the tables? > > Hm, that sounds like a very complicated way to get a list of columns in > Python. Instead, you could query the database to get the list of columns > for a table, their datatypes, etc. All the databases that ODB currently > supports have the ability to retrieve this meta-data. > > Boris > From finjulhich at gmail.com Wed May 28 08:56:12 2014 From: finjulhich at gmail.com (MM) Date: Wed May 28 08:56:21 2014 Subject: [odb-users] raw pointer to application's global array Message-ID: Hi, My struct has a const std::string* member. This points to an element in a global array of const std::string initialized before main. What can be the repr of that field as a column in the sql table? This global array is small and fairly will never change. I don't need it in the database. Loading would load the row from the table and somehow make the pointer point to right element of the static global array. Storing would store the persistent object in the table. I assume the pointee (string) could be stored in the table but i'm not sure how to implement that? Thanks, From boris at codesynthesis.com Wed May 28 09:45:14 2014 From: boris at codesynthesis.com (Boris Kolpackov) Date: Wed May 28 09:42:34 2014 Subject: [odb-users] raw pointer to application's global array In-Reply-To: References: Message-ID: Hi, MM writes: > What can be the repr of that field as a column in the sql table? Storing the value itself is probably the most straightforward option. But if the array does not change, or if you will only add new elements at the end, then you could store the index into this array instead. > Loading would load the row from the table and somehow make the pointer > point to right element of the static global array. > Storing would store the persistent object in the table. > > I assume the pointee (string) could be stored in the table but i'm > not sure how to implement that? The best way to handle such cases (i.e., storing something other that the value of the data member) is to use virtual data members (see Section 14.4.13, "virtual" in the ODB manual). With the virtual data member you can specify your own accessors/modifiers that will do the translation that you want. For example: #pragma db object class object { ... #pragma db transient std::string* foo_; #pragma db member(foo) virtual(std::string) get(*this.foo_) set(set_foo) void set_foo (const std::string& str) { // Find str in the array and set foo_ to point to that element. } }; If you would rather store the array index, then the same class would look along these lines: extern std::string array[N]; // Global array. #pragma db object class object { ... #pragma db transient std::string* foo_; #pragma db member(foo) virtual(std::size_t) \ get(this.foo_ - array) \ set(this.foo_ = array + (?)) }; Here we don't even need any functions since the accessor and modifier expressions are really simple and we can just write them inline. Boris From cowerss at gmail.com Wed May 28 09:58:44 2014 From: cowerss at gmail.com (lz) Date: Wed May 28 10:00:58 2014 Subject: [odb-users] Does ODB support some function like limit of sql or page Message-ID: Mr odb-devloper: Recently ,I have used the odb orm project ,and i think it?s very nice. So,i used it in my project. But?there is a problem make me confused.Does the odb support page function (like the limit of sql)? Because there is a lot of data in my databases ,and i want get few of object per query. So,i wonder is there any interface of odb like this? Thank you for reading this email.And Looking forward to your reply. Jared Liu 2014-05-13 From boris at codesynthesis.com Wed May 28 11:00:40 2014 From: boris at codesynthesis.com (Boris Kolpackov) Date: Wed May 28 10:58:01 2014 Subject: [odb-users] Does ODB support some function like limit of sql or page In-Reply-To: References: Message-ID: Hi, Sorry for the delay in replying to your email. For some reason it got caught up in the spam filter. lz writes: > Recently ,I have used the odb orm project ,and i think it?s very nice. Thanks, I am glad you enjoyed it. > But?there is a problem make me confused. Does the odb support page > function (like the limit of sql)? Not directly, but it is quite easy to implement for databases that support LIMIT/OFFSET. This earlier post has more information and sample code: http://www.codesynthesis.com/pipermail/odb-users/2012-January/000429.html Boris From finjulhich at gmail.com Thu May 29 06:28:13 2014 From: finjulhich at gmail.com (MM) Date: Thu May 29 06:28:22 2014 Subject: [odb-users] raw pointer to application's global array In-Reply-To: References: Message-ID: On 28 May 2014 14:45, Boris Kolpackov wrote: > Hi, > > > Loading would load the row from the table and somehow make the pointer > > point to right element of the static global array. > > Storing would store the persistent object in the table. > > > > I assume the pointee (string) could be stored in the table but i'm > > not sure how to implement that? > > The best way to handle such cases (i.e., storing something other that > the value of the data member) is to use virtual data members (see > Section 14.4.13, "virtual" in the ODB manual). With the virtual data > member you can specify your own accessors/modifiers that will do > the translation that you want. For example: > > #pragma db object > class object > { > ... > > #pragma db transient > std::string* foo_; > > #pragma db member(foo) virtual(std::string) get(*this.foo_) set(set_foo) > > void set_foo (const std::string& str) > { > // Find str in the array and set foo_ to point to that element. > } > }; > > > Boris > This is very very good. I'll go with this solution. Thanks Boris for great explanations. object actually has a couple of other members, 1 of which is std::string code The combination (foo_, code) is the unique identifier. Is it possible, non-intrusively, to have a auto-generated id? MM From boris at codesynthesis.com Thu May 29 07:23:45 2014 From: boris at codesynthesis.com (Boris Kolpackov) Date: Thu May 29 07:21:04 2014 Subject: [odb-users] raw pointer to application's global array In-Reply-To: References: Message-ID: Hi, MM writes: > object actually has a couple of other members, 1 of which is > std::string code > > The combination (foo_, code) is the unique identifier. > > Is it possible, non-intrusively, to have a auto-generated id? ODB only supports auto-generated ids for integers (by using the corresponding underlying database's functionality). One way to achieve the same for a string would be to generate UUIDs on the application side. For example, you could use the Boost.Uuid library. In that case it might even make sense to use boost::uuids::uuid type instead of std::string (Section 23.6 in the ODB manual). Boris From finjulhich at gmail.com Thu May 29 07:40:25 2014 From: finjulhich at gmail.com (MM) Date: Thu May 29 07:40:33 2014 Subject: [odb-users] raw pointer to application's global array In-Reply-To: References: Message-ID: On 29 May 2014 12:23, Boris Kolpackov wrote: > Hi, > > MM writes: > > > object actually has a couple of other members, 1 of which is > > std::string code > > > > The combination (foo_, code) is the unique identifier. > > > > Is it possible, non-intrusively, to have a auto-generated id? > > ODB only supports auto-generated ids for integers (by using the > corresponding underlying database's functionality). One way to > achieve the same for a string would be to generate UUIDs on the > application side. For example, you could use the Boost.Uuid > library. In that case it might even make sense to use > boost::uuids::uuid type instead of std::string (Section 23.6 in > the ODB manual). > > Boris > Ok, but can I have a virtual member integer that stands for auto generated id? If not, I'll just add a integer (std::uintx_t) as a member of that struct, and use that as the auto id. Thanks From finjulhich at gmail.com Thu May 29 08:26:37 2014 From: finjulhich at gmail.com (MM) Date: Thu May 29 08:26:45 2014 Subject: [odb-users] raw pointer to application's global array In-Reply-To: References: Message-ID: also, in the virt member pragma #pragma db member(foo) virtual(std::string) get(*this.foo_) set(set_foo) My foo_ is actually public. Can the setter be declared in the non intrusive header for the pragmas, as a non member function? On 29 May 2014 12:40, MM wrote: > On 29 May 2014 12:23, Boris Kolpackov wrote: > >> Hi, >> >> MM writes: >> >> > object actually has a couple of other members, 1 of which is >> > std::string code >> > >> > The combination (foo_, code) is the unique identifier. >> > >> > Is it possible, non-intrusively, to have a auto-generated id? >> >> ODB only supports auto-generated ids for integers (by using the >> corresponding underlying database's functionality). One way to >> achieve the same for a string would be to generate UUIDs on the >> application side. For example, you could use the Boost.Uuid >> library. In that case it might even make sense to use >> boost::uuids::uuid type instead of std::string (Section 23.6 in >> the ODB manual). >> >> Boris >> > Ok, but can I have a virtual member integer that stands for auto generated > id? > If not, I'll just add a integer (std::uintx_t) as a member of that struct, > and use that as the auto id. > > Thanks > > From boris at codesynthesis.com Thu May 29 09:40:05 2014 From: boris at codesynthesis.com (Boris Kolpackov) Date: Thu May 29 09:37:25 2014 Subject: [odb-users] raw pointer to application's global array In-Reply-To: References: Message-ID: Hi, MM writes: > Ok, but can I have a virtual member integer that stands for auto generated > id? If not, I'll just add a integer (std::uintx_t) as a member of that > struct, and use that as the auto id. ODB-supported auto-id can only be a single data member of an integer type. It cannot be a member of a struct. It can be a virtual data member: #pragma db member(my_id) virtual(unsigned long) id > also, in the virt member pragma > > #pragma db member(foo) virtual(std::string) get(*this.foo_) set(set_foo) > > My foo_ is actually public. > > Can the setter be declared in the non intrusive header for the pragmas, as > a non member function? Yes, but then you will need to spell out the call expression explicitly: class object { #pragma db member(foo) virtual(std::string) set(set_foo (this, (?))) }; void set_foo (object& o, const std::string foo) { ... } For more detail see the describtion of the accessor and modifier expressions in the ODB manual (Section 14.4.5, "get/set/access"). Boris From finjulhich at gmail.com Thu May 29 09:49:11 2014 From: finjulhich at gmail.com (MM) Date: Thu May 29 09:49:19 2014 Subject: [odb-users] raw pointer to application's global array In-Reply-To: References: Message-ID: On 29 May 2014 14:40, Boris Kolpackov wrote: > Hi, > > MM writes: > > > Ok, but can I have a virtual member integer that stands for auto > generated > > id? If not, I'll just add a integer (std::uintx_t) as a member of that > > struct, and use that as the auto id. > > ODB-supported auto-id can only be a single data member of an integer > type. It cannot be a member of a struct. It can be a virtual data > member: > > #pragma db member(my_id) virtual(unsigned long) id > I am very confused. In this pragma, there is nothing that links the my_id to the C++ class/struct ('object') the instances of which will be persisted and use this auto generated id? I restate everything here from start, for my own understanding. I have a struct 'object'. I will have instances of object. These instances I want to store them as rows in some table in sqlite. The auto id is the unique identifier of each different persistence instance of 'object' > > also, in the virt member pragma > > > > #pragma db member(foo) virtual(std::string) get(*this.foo_) set(set_foo) > > > > My foo_ is actually public. > > > > Can the setter be declared in the non intrusive header for the pragmas, > as > > a non member function? > > Yes, but then you will need to spell out the call expression explicitly: > > class object > { > #pragma db member(foo) virtual(std::string) set(set_foo (this, (?))) > }; > > void set_foo (object& o, const std::string foo) > { > ... > } > > For more detail see the describtion of the accessor and modifier > expressions in the ODB manual (Section 14.4.5, "get/set/access"). > > Boris > Ok great, this is exactly what I was looking for. Thanks again, From boris at codesynthesis.com Thu May 29 10:06:36 2014 From: boris at codesynthesis.com (Boris Kolpackov) Date: Thu May 29 10:03:56 2014 Subject: [odb-users] raw pointer to application's global array In-Reply-To: References: Message-ID: Hi, MM writes: > > #pragma db member(my_id) virtual(unsigned long) id > > > I am very confused. In this pragma, there is nothing that links the my_id > to the C++ class/struct ('object') the instances of which will be persisted > and use this auto generated id? Yes, I should have added ellipsis at the end of this pragma to highlight that it is incomplete (and I forgot auto): #pragma db member(my_id) virtual(unsigned long) id auto ... What you still need to specify is the get/set expressions that interface with the underlying storage. Here is an example: class object { #pragma db transient unsigned long my_id_; #pragma db member(my_id) virtual(unsigned long) id auto get(my_id_) set(my_id_) }; Of course, this specific example does not make much sense since you can achieve the same result by simply making my_id_ the id member directly, without any virtual data members: class object { #pragma db id auto unsigned long my_id_; }; Perhaps that's what you are looking for? Boris From finjulhich at gmail.com Thu May 29 10:45:10 2014 From: finjulhich at gmail.com (MM) Date: Thu May 29 10:45:19 2014 Subject: [odb-users] raw pointer to application's global array In-Reply-To: References: Message-ID: yes adding a private member std::uint32_t to my object will work. I'll specify the pragma outside of the class definition though #pragma db member(object::my_id_) id auto do i still need get/set ? On 29 May 2014 15:06, Boris Kolpackov wrote: > Hi, > > MM writes: > > > > #pragma db member(my_id) virtual(unsigned long) id > > > > > I am very confused. In this pragma, there is nothing that links the my_id > > to the C++ class/struct ('object') the instances of which will be > persisted > > and use this auto generated id? > > Yes, I should have added ellipsis at the end of this pragma to > highlight that it is incomplete (and I forgot auto): > > #pragma db member(my_id) virtual(unsigned long) id auto ... > > What you still need to specify is the get/set expressions that > interface with the underlying storage. Here is an example: > > class object > { > #pragma db transient > unsigned long my_id_; > > #pragma db member(my_id) virtual(unsigned long) id auto get(my_id_) > set(my_id_) > }; > > Of course, this specific example does not make much sense since > you can achieve the same result by simply making my_id_ the id > member directly, without any virtual data members: > > class object > { > #pragma db id auto > unsigned long my_id_; > }; > > Perhaps that's what you are looking for? > > Boris > From boris at codesynthesis.com Fri May 30 04:01:25 2014 From: boris at codesynthesis.com (Boris Kolpackov) Date: Fri May 30 03:58:45 2014 Subject: [odb-users] raw pointer to application's global array In-Reply-To: References: Message-ID: Hi, MM writes: > #pragma db member(object::my_id_) id auto > > do i still need get/set ? That depends on whether ODB can access the member directly or if it can find suitable accessor/modifier automatically. Again, I send you to the ODB manual, this time Section 3.2, "Declaring Persistent Objects and Values". Boris From finjulhich at gmail.com Fri May 30 07:48:18 2014 From: finjulhich at gmail.com (MM) Date: Fri May 30 07:48:26 2014 Subject: [odb-users] raw pointer to application's global array In-Reply-To: References: Message-ID: right in the setter expression you gave before set(set_foo (this, (?))) with set_foo( object&, const std::string& ) The pragma expression really should be: set(set_foo (*this, (?))) and i assume the (?) gets translated to the virtual member here the std::string Thanks, On 30 May 2014 09:01, Boris Kolpackov wrote: > Hi, > > MM writes: > > > #pragma db member(object::my_id_) id auto > > > > do i still need get/set ? > > That depends on whether ODB can access the member directly or if > it can find suitable accessor/modifier automatically. Again, I > send you to the ODB manual, this time Section 3.2, "Declaring > Persistent Objects and Values". > > Boris > From finjulhich at gmail.com Fri May 30 07:56:42 2014 From: finjulhich at gmail.com (MM) Date: Fri May 30 07:56:50 2014 Subject: [odb-users] raw pointer to application's global array In-Reply-To: References: Message-ID: sorry I just read the manual section about this. both this and (?) clarified, thanks On 30 May 2014 12:48, MM wrote: > right > in the setter expression you gave before > set(set_foo (this, (?))) > with > set_foo( object&, const std::string& ) > > > The pragma expression really should be: set(set_foo (*this, (?))) > > and i assume the (?) gets translated to the virtual member here the > std::string > > Thanks, > > > On 30 May 2014 09:01, Boris Kolpackov wrote: > >> Hi, >> >> MM writes: >> >> > #pragma db member(object::my_id_) id auto >> > >> > do i still need get/set ? >> >> That depends on whether ODB can access the member directly or if >> it can find suitable accessor/modifier automatically. Again, I >> send you to the ODB manual, this time Section 3.2, "Declaring >> Persistent Objects and Values". >> >> Boris >> > > From finjulhich at gmail.com Fri May 30 09:24:12 2014 From: finjulhich at gmail.com (MM) Date: Fri May 30 09:24:19 2014 Subject: [odb-users] private data members, accessors, and transient Message-ID: Hi, Just to confirm. If i am given: class C { ... m1() const; void m1(...); /// with the right signatures ... m2() const; void m2(...); /// with the right signatures private: ... }; // non instrusive #pragma db value(C) definition transient #pragma db member(C::m1) #pragma db member(C::m2) This will make all the internal data members transient, but will store m1 and m2 in the database when C is persisted? From boris at codesynthesis.com Fri May 30 11:38:15 2014 From: boris at codesynthesis.com (Boris Kolpackov) Date: Fri May 30 11:35:35 2014 Subject: [odb-users] private data members, accessors, and transient In-Reply-To: References: Message-ID: Hi, MM writes: > class C { > ... m1() const; > void m1(...); /// with the right signatures > > ... m2() const; > void m2(...); /// with the right signatures > private: > ... > }; > > // non instrusive > #pragma db value(C) definition transient > #pragma db member(C::m1) > #pragma db member(C::m2) > > This will make all the internal data members transient, but will store m1 > and m2 in the database when C is persisted? No, if you mark an object of composite value transient, then this is equivalent to marking all real (that is, no-virtual) data members as transient. And none of them will be stored in the database. Only virtual data members will be stored. This feature is primarily useful for supporting things like the pimpl idiom (see the 'pimpl' example in the odb-examples package). You seem to be over-thinking things. In your case, normally, all you need to do is this: #pragma db value(C) The ODB compiler will then discover and use the m1() and m2() accessors and modifiers to store the data members. Boris From finjulhich at gmail.com Fri May 30 11:56:31 2014 From: finjulhich at gmail.com (MM) Date: Fri May 30 11:56:38 2014 Subject: [odb-users] private data members, accessors, and transient In-Reply-To: References: Message-ID: i see, indeed the solution is simple:-) thanks On 30 May 2014 16:38, Boris Kolpackov wrote: > Hi, > > MM writes: > > > class C { > > ... m1() const; > > void m1(...); /// with the right signatures > > > > ... m2() const; > > void m2(...); /// with the right signatures > > private: > > ... > > }; > > > > // non instrusive > > #pragma db value(C) definition transient > > #pragma db member(C::m1) > > #pragma db member(C::m2) > > > > This will make all the internal data members transient, but will store m1 > > and m2 in the database when C is persisted? > > No, if you mark an object of composite value transient, then this is > equivalent to marking all real (that is, no-virtual) data members as > transient. And none of them will be stored in the database. Only > virtual data members will be stored. This feature is primarily useful > for supporting things like the pimpl idiom (see the 'pimpl' example > in the odb-examples package). > > You seem to be over-thinking things. In your case, normally, all you > need to do is this: > > #pragma db value(C) > > The ODB compiler will then discover and use the m1() and m2() accessors > and modifiers to store the data members. > > Boris > From finjulhich at gmail.com Fri May 30 12:06:35 2014 From: finjulhich at gmail.com (MM) Date: Fri May 30 12:06:42 2014 Subject: [odb-users] schema generation w sqlite? Message-ID: Hello, I fail to generate a sql file with this command: odb --std c++11 -d sqlite --generate-query --generate-schema Aodb.h which returns without error message, on win7/32bit Aodb.h includes A.h which is the definition of class A, untouched by any odb. Aodb.h has: #ifndef A_ODB_H #define A_ODB_H #include #include "A.h" /// class A and struct A_stat defined here #pragma db object(A) #pragma db member(A::id_) id auto #pragma db view(A_stat) object(A) #pragma db member(A_stat::count) column("count(" + A::id_ + ")") #pragma db member(A_stat::min_age) column("min(" + A::age_ + ")") #pragma db member(A_stat::max_age) column("max(" + A::age_ + ")") #endif // A_ODB_H Rds, From finjulhich at gmail.com Fri May 30 12:25:47 2014 From: finjulhich at gmail.com (MM) Date: Fri May 30 12:25:55 2014 Subject: [odb-users] Re: schema generation w sqlite? In-Reply-To: References: Message-ID: On 30 May 2014 17:06, MM wrote: > Hello, > > I fail to generate a sql file with this command: > > odb --std c++11 -d sqlite --generate-query --generate-schema Aodb.h > > which returns without error message, on win7/32bit > > > Aodb.h includes A.h which is the definition of class A, untouched by any > odb. > Aodb.h has: > > #ifndef A_ODB_H > #define A_ODB_H > > #include > #include "A.h" /// class A and struct A_stat defined here > > #pragma db object(A) > #pragma db member(A::id_) id auto > > #pragma db view(A_stat) object(A) > #pragma db member(A_stat::count) column("count(" + A::id_ + ")") > #pragma db member(A_stat::min_age) column("min(" + A::age_ + ")") > #pragma db member(A_stat::max_age) column("max(" + A::age_ + ")") > > #endif // A_ODB_H > > Rds, > > An update is I added --schema-format sql . I also added the "definition" to the pragma which generated Aodb.sql. Rds, From finjulhich at gmail.com Fri May 30 13:47:29 2014 From: finjulhich at gmail.com (MM) Date: Fri May 30 13:47:37 2014 Subject: [odb-users] private data members, accessors, and transient In-Reply-To: References: Message-ID: but what about if C doesn't contain just m1 and m2 accessors, but also m3 and m4 which I don't want odb to store? On 30 May 2014 16:56, MM wrote: > i see, indeed the solution is simple:-) thanks > > > On 30 May 2014 16:38, Boris Kolpackov wrote: > >> Hi, >> >> MM writes: >> >> > class C { >> > ... m1() const; >> > void m1(...); /// with the right signatures >> > >> > ... m2() const; >> > void m2(...); /// with the right signatures >> > private: >> > ... >> > }; >> > >> > // non instrusive >> > #pragma db value(C) definition transient >> > #pragma db member(C::m1) >> > #pragma db member(C::m2) >> > >> > This will make all the internal data members transient, but will store >> m1 >> > and m2 in the database when C is persisted? >> >> No, if you mark an object of composite value transient, then this is >> equivalent to marking all real (that is, no-virtual) data members as >> transient. And none of them will be stored in the database. Only >> virtual data members will be stored. This feature is primarily useful >> for supporting things like the pimpl idiom (see the 'pimpl' example >> in the odb-examples package). >> >> You seem to be over-thinking things. In your case, normally, all you >> need to do is this: >> >> #pragma db value(C) >> >> The ODB compiler will then discover and use the m1() and m2() accessors >> and modifiers to store the data members. >> >> Boris >> > > From boris at codesynthesis.com Fri May 30 15:18:03 2014 From: boris at codesynthesis.com (Boris Kolpackov) Date: Fri May 30 15:15:24 2014 Subject: [odb-users] private data members, accessors, and transient In-Reply-To: References: Message-ID: Hi, MM writes: > but what about if C doesn't contain just m1 and m2 accessors, but also m3 > and m4 which I don't want odb to store? Then you mark them as transient: #pragma db member(C::m3) transient #pragma db member(C::m4) transient Boris