From boris at codesynthesis.com Mon Feb 2 06:50:37 2015 From: boris at codesynthesis.com (Boris Kolpackov) Date: Mon Feb 2 07:00:17 2015 Subject: [odb-users] how to change generated include paths In-Reply-To: References: Message-ID: Hi Diego, In the future, when asking a different question, please don't reply to the existing thread but rather create a new email with proper subject, etc. See posting guidelines for details: http://codesynthesis.com/support/posting-guidelines.xhtml Diego Fernando writes: > The problem is every time I compile the project I have to changed the > include in -odb.h Use can use the --include-regex ODB compiler option to transform the generated include paths to suit your projects' structure. See the ODB compiler command line manual (man pages) for details and examples. Boris From lordvampyre at gmail.com Tue Feb 3 04:22:37 2015 From: lordvampyre at gmail.com (Diego Fernando) Date: Tue Feb 3 04:22:46 2015 Subject: [odb-users] how to change generated include paths In-Reply-To: References: Message-ID: Hi Boris, Sorry for the email. I'll try the command on the qt creator... Thank you 2015-02-02 9:50 GMT-02:00 Boris Kolpackov : > Hi Diego, > > In the future, when asking a different question, please don't reply > to the existing thread but rather create a new email with proper > subject, etc. See posting guidelines for details: > > http://codesynthesis.com/support/posting-guidelines.xhtml > > > Diego Fernando writes: > > > The problem is every time I compile the project I have to changed the > > include in -odb.h > > Use can use the --include-regex ODB compiler option to transform the > generated include paths to suit your projects' structure. See the > ODB compiler command line manual (man pages) for details and examples. > > Boris > From lordvampyre at gmail.com Tue Feb 3 07:26:28 2015 From: lordvampyre at gmail.com (Diego Fernando) Date: Tue Feb 3 07:26:35 2015 Subject: [odb-users] Qt and classes derived from QObject Message-ID: Hi Boris, Employee and Person class class Person : public QObject class Employee : public OQbject { Person *person; } It's compile output: error: invalid cast from type 'odb::object_traits::pointer_type {aka QSharedPointer}' to type 'odb::pointer_traits::pointer_type {aka Person*}' obj_traits::object_type > (id)); Show this line on code // If a compiler error points to the line below, then // it most likely means that a pointer used in a member // cannot be initialized from an object pointer. // v = ptr_traits::pointer_type ( static_cast (db)->load< obj_traits::object_type > (id)); } I am using Qt and QML and exists some way to make this works without duplicate the code where one class is derived from QObject and another no. Thank you From boris at codesynthesis.com Tue Feb 3 10:14:58 2015 From: boris at codesynthesis.com (Boris Kolpackov) Date: Tue Feb 3 10:24:40 2015 Subject: [odb-users] Qt and classes derived from QObject In-Reply-To: References: Message-ID: Hi Diego, Diego Fernando writes: > class Person : public QObject > > class Employee : public OQbject > { > Person *person; > } > > It's compile output: > error: invalid cast from type 'odb::object_traits::pointer_type > {aka QSharedPointer}' to type > 'odb::pointer_traits::pointer_type {aka Person*}' > obj_traits::object_type > (id)); > > Show this line on code > > // If a compiler error points to the line below, then > // it most likely means that a pointer used in a member > // cannot be initialized from an object pointer. > // > > > } > > I am using Qt and QML and exists some way to make this works without > duplicate the code where one class is derived from QObject and another > no. This has nothing to do with deriving (or not) from QObject. You are using the Qt profile which makes QSharedPointer the default object pointer. This is probably the right choice for most situations, including yours. So simply change: Person *person; To: QSharedPointer person; Boris From lordvampyre at gmail.com Tue Feb 3 14:57:58 2015 From: lordvampyre at gmail.com (Diego Fernando) Date: Tue Feb 3 14:58:05 2015 Subject: [odb-users] Qt and classes derived from QObject In-Reply-To: References: Message-ID: Thank you I change and now it's working. 2015-02-03 13:14 GMT-02:00 Boris Kolpackov : > Hi Diego, > > Diego Fernando writes: > > > class Person : public QObject > > > > class Employee : public OQbject > > { > > Person *person; > > } > > > > It's compile output: > > error: invalid cast from type 'odb::object_traits::pointer_type > > {aka QSharedPointer}' to type > > 'odb::pointer_traits::pointer_type {aka Person*}' > > obj_traits::object_type > (id)); > > > > Show this line on code > > > > // If a compiler error points to the line below, then > > // it most likely means that a pointer used in a member > > // cannot be initialized from an object pointer. > > // > > > > > > } > > > > I am using Qt and QML and exists some way to make this works without > > duplicate the code where one class is derived from QObject and another > > no. > > This has nothing to do with deriving (or not) from QObject. You are > using the Qt profile which makes QSharedPointer the default object > pointer. This is probably the right choice for most situations, > including yours. So simply change: > > Person *person; > > To: > > QSharedPointer person; > > Boris > > From lordvampyre at gmail.com Tue Feb 3 15:25:43 2015 From: lordvampyre at gmail.com (Diego Fernando) Date: Tue Feb 3 15:25:50 2015 Subject: [odb-users] how to change generated include paths In-Reply-To: References: Message-ID: Hi Boris I saw the odb manual. I just try put in .pro this regex '%./include/entity/(.+)-odb.h%$1-odb.h%' And the compiled returns is /bin/sh: -c: line 0: syntax error near unexpected token `(' Thank you 2015-02-03 7:22 GMT-02:00 Diego Fernando : > Hi Boris, > > Sorry for the email. > > I'll try the command on the qt creator... > > > Thank you > > 2015-02-02 9:50 GMT-02:00 Boris Kolpackov : > > Hi Diego, >> >> In the future, when asking a different question, please don't reply >> to the existing thread but rather create a new email with proper >> subject, etc. See posting guidelines for details: >> >> http://codesynthesis.com/support/posting-guidelines.xhtml >> >> >> Diego Fernando writes: >> >> > The problem is every time I compile the project I have to changed the >> > include in -odb.h >> >> Use can use the --include-regex ODB compiler option to transform the >> generated include paths to suit your projects' structure. See the >> ODB compiler command line manual (man pages) for details and examples. >> >> Boris >> > > From boris at codesynthesis.com Wed Feb 4 05:19:38 2015 From: boris at codesynthesis.com (Boris Kolpackov) Date: Wed Feb 4 05:15:58 2015 Subject: [odb-users] how to change generated include paths In-Reply-To: References: Message-ID: Hi Diego, Diego Fernando writes: > I just try put in .pro this regex > '%./include/entity/(.+)-odb.h%$1-odb.h%' > > And the compiled returns is > /bin/sh: -c: line 0: syntax error near unexpected token `(' It appears qmake (or whatever is processing .pro files these days) strips the quotes ('') from the value. So you will need to play a bit with various quoting styles to find a way that works. Some candidates to try are: "'%./include/entity/(.+)-odb.h%$1-odb.h%'" \'%./include/entity/(.+)-odb.h%$1-odb.h%\' If you still can't make it work, I suggest that you ask for help on the relevant Qt mailing list/forum. Boris From lordvampyre at gmail.com Wed Feb 4 05:28:58 2015 From: lordvampyre at gmail.com (Diego Fernando) Date: Wed Feb 4 05:29:06 2015 Subject: [odb-users] how to change generated include paths In-Reply-To: References: Message-ID: Hi Boris, Thank you. I go ask Qt forum... %./include/entity/(.+)-odb.h%-odb.h%: error: unable to open in read mode When they answer me I'll put the answer here 2015-02-04 8:19 GMT-02:00 Boris Kolpackov : > Hi Diego, > > Diego Fernando writes: > > > I just try put in .pro this regex > > '%./include/entity/(.+)-odb.h%$1-odb.h%' > > > > And the compiled returns is > > /bin/sh: -c: line 0: syntax error near unexpected token `(' > > It appears qmake (or whatever is processing .pro files these > days) strips the quotes ('') from the value. So you will need > to play a bit with various quoting styles to find a way that > works. Some candidates to try are: > > "'%./include/entity/(.+)-odb.h%$1-odb.h%'" > \'%./include/entity/(.+)-odb.h%$1-odb.h%\' > > If you still can't make it work, I suggest that you ask for > help on the relevant Qt mailing list/forum. > > Boris > From boris at codesynthesis.com Wed Feb 4 10:58:09 2015 From: boris at codesynthesis.com (Boris Kolpackov) Date: Wed Feb 4 11:08:08 2015 Subject: [odb-users] how to change generated include paths In-Reply-To: References: Message-ID: Hi Diego, Diego Fernando writes: > %./include/entity/(.+)-odb.h%-odb.h%: error: unable to open in read mode This is actually the argument that you want ODB to see. I think you just forgot to add --include-regex before it. Boris From lordvampyre at gmail.com Wed Feb 4 19:52:04 2015 From: lordvampyre at gmail.com (Diego Fernando) Date: Wed Feb 4 19:52:12 2015 Subject: [odb-users] how to change generated include paths In-Reply-To: References: Message-ID: Hi Boris, The problem was in my regex I change that $$re_escape( %./include/entity/(.+)-odb.h%$1-odb.h%) to this $$re_escape( %./include/entity/(.+)-odb.h%\1-odb.h%) https://qt-project.org/forums/viewthread/52772/ Thank you. 2015-02-04 13:58 GMT-02:00 Boris Kolpackov : > Hi Diego, > > Diego Fernando writes: > > > %./include/entity/(.+)-odb.h%-odb.h%: error: unable to open in read mode > > This is actually the argument that you want ODB to see. I think you > just forgot to add --include-regex before it. > > Boris > From alex-beimler at web.de Fri Feb 6 04:58:23 2015 From: alex-beimler at web.de (Alex Beimler) Date: Fri Feb 6 07:13:23 2015 Subject: [odb-users] Fwd: Re: ODB and C++11 Chrono In-Reply-To: References: Message-ID: <54D4903F.8010408@web.de> -------- Weitergeleitete Nachricht -------- Betreff: Re: ODB and C++11 Chrono Datum: Fri, 6 Feb 2015 10:09:52 +0200 Von: Boris Kolpackov Organisation: Code Synthesis Tools CC An: Alex Beimler Hi Alex, Thanks for the email. Could I ask you to re-send it to odb-users@codesynthesis.com mailing list where I would be happy to reply. I want others who might be interested in the same thing to be aware of what's going on. Best regards, Boris ----- Original Message ----- From: "Alex Beimler" Subject: ODB and C++11 Chrono Date: Thu, 05 Feb, 2015 14:53 +0100 Hello Mr Kolpackov, First thanks for odb its a great Lib for lightweight Webapps (in compilation with cppcms). But i have a Question, is there a traits type support for std::chrono::duration,time_point,... by default or in the future Versions? Are your planning other traits type by default, maybe std::deque, boost::posix_time::time_duration? I have start to write own traits-types for std::chrono::duration but i thought maybe they are already done (in future Version). ps. Greate talk at cppcon, thanks for that. From nicholas.cremonesi at elicat.net Fri Feb 6 10:22:56 2015 From: nicholas.cremonesi at elicat.net (Nicholas Cremonesi) Date: Fri Feb 6 10:23:04 2015 Subject: [odb-users] Generate C++ classes from sqlite database schema Message-ID: Hello everyone, I have to handle a huge SQLite database, I already have the database schema and I would to know if it's possible, with ODB, to generate the corresponding C++ classes, instead of generate the schema from the classes as usual. From davejohansen at gmail.com Fri Feb 6 22:42:35 2015 From: davejohansen at gmail.com (Dave Johansen) Date: Fri Feb 6 22:42:41 2015 Subject: [odb-users] ODB and gcc 5.0? Message-ID: Fedora 22 (rawhide) recently updated to gcc 5.0.0. I tried building ODB with it and it ran into some problems. The build.log can be found here: https://kojipkgs.fedoraproject.org//work/tasks/4242/8854242/build.log Is this something that can be resolved relatively easily? Or is gcc 5.0 support going to require a new release? Thanks, Dave From dieter.govaerts at bricsys.com Sat Feb 7 04:56:30 2015 From: dieter.govaerts at bricsys.com (dieter.govaerts@bricsys.com) Date: Sat Feb 7 06:24:07 2015 Subject: [odb-users] virtual data member and odb::nullable Message-ID: <1423302990.0910992@apps.rackspace.com> Hallo, It seems that I can't declare a virtual datamember that is an odb::nullable. The odb compiler shows the following error: error: name 'odb::nullable' in db pragma virtual does not refer to a type I'm using a 'pimpl' design with virtual datamembers. The virtual datamember declaration is as follows: #pragma db member(variable_layer) virtual(odb::nullable) access(this.impl_->m_variable_layer) How can I solve this? I need to be able to determine the NULL value. Thanks. Dieter Govaerts From boris at codesynthesis.com Sat Feb 7 06:18:04 2015 From: boris at codesynthesis.com (Boris Kolpackov) Date: Sat Feb 7 06:28:06 2015 Subject: [odb-users] ODB and gcc 5.0? In-Reply-To: References: Message-ID: Hi Dave, Dave Johansen writes: > Fedora 22 (rawhide) recently updated to gcc 5.0.0. I tried building ODB > with it and it ran into some problems. Funny you must write about this. I spent half a day yesterday making ODB work with GCC 5. > Is this something that can be resolved relatively easily? Or is gcc 5.0 > support going to require a new release? It is not a trivial patch but I think it should apply to 2.3.0 relatively easily: http://scm.codesynthesis.com/?p=odb/odb.git;a=commit;h=ee9c9f3db3eb4b689e565c282345b1f49bba5042 Alternatively, you can wait for 2.4.0, which is imminent. And thanks for staying on top of this, much appreciated! Boris From boris at codesynthesis.com Sat Feb 7 08:36:53 2015 From: boris at codesynthesis.com (Boris Kolpackov) Date: Sat Feb 7 08:47:00 2015 Subject: [odb-users] Generate C++ classes from sqlite database schema In-Reply-To: References: Message-ID: Hi Nicholas, Nicholas Cremonesi writes: > I have to handle a huge SQLite database, I already have the database schema > and I would to know if it's possible, with ODB, to generate the > corresponding C++ classes, instead of generate the schema from the classes > as usual. This feature is asked for from time to time and there are some ideas floating around, but nothing has been implemented yet. It is a big and not very well defined problem. Here is some further reading if you are interested: http://codesynthesis.com/pipermail/odb-users/2014-January/001769.html In the meantime, with a bit of effort it should be possible to read the SQLite schema (from the database) and generate ODB-persistent C++ classes. Since you only need to generate classes that fit your specific requirements, you can sidestep a lot of the issues that are described above and that a generic solution would face. Boris From boris at codesynthesis.com Sat Feb 7 09:00:51 2015 From: boris at codesynthesis.com (Boris Kolpackov) Date: Sat Feb 7 09:10:57 2015 Subject: [odb-users] virtual data member and odb::nullable In-Reply-To: <1423302990.0910992@apps.rackspace.com> References: <1423302990.0910992@apps.rackspace.com> Message-ID: Hi Dieter, dieter.govaerts@bricsys.com writes: > It seems that I can't declare a virtual datamember that is an > odb::nullable. The odb compiler shows the following error: > > error: name 'odb::nullable' in db pragma virtual does not refer to a type > > #pragma db member(variable_layer) virtual(odb::nullable) ... You can do this, you just need to give odb::nullable a name: typedef odb::nullable variable_layer_type; #pragma db member(variable_layer) virtual(variable_layer_type) ... It is an annoying limitation (and I've added an item to our TODO list) but fairly hard to resolve, technically. Boris From boris at codesynthesis.com Sat Feb 7 09:11:48 2015 From: boris at codesynthesis.com (Boris Kolpackov) Date: Sat Feb 7 09:21:54 2015 Subject: [odb-users] Fwd: Re: ODB and C++11 Chrono In-Reply-To: <54D4903F.8010408@web.de> References: <54D4903F.8010408@web.de> Message-ID: Hi Alex, Alex Beimler writes: > First thanks for odb its a great Lib for lightweight Webapps (in > compilation with cppcms). Thanks, I am glad you like it! > But i have a Question, is there a traits type support for > std::chrono::duration,time_point,... by default or in the future > Versions? Not yet, but I agree they are needed. > Are your planning other traits type by default, maybe std::deque, I've managed to sneak std::deque in for the upcoming release. > boost::posix_time::time_duration? Yes, that's supported. See the Boost profile (Chapter 23 in the manual). I've found the trickiest part with implementing the Boost date-time support is figuring out which database types to map to and how to convert to/from the corresponding image types. So, hopefully, we will be able to use the code from the Boost (and Qt) profiles as a guide/reference to implement std::chrono. > Greate talk at cppcon, thanks for that. It was 3am "my time" and I was quite jetlagged... Still afraid to go watch that video... ;-) Boris From davejohansen at gmail.com Sat Feb 7 11:26:22 2015 From: davejohansen at gmail.com (Dave Johansen) Date: Sat Feb 7 11:26:29 2015 Subject: [odb-users] ODB and gcc 5.0? In-Reply-To: References: Message-ID: On Sat, Feb 7, 2015 at 4:18 AM, Boris Kolpackov wrote: > > Is this something that can be resolved relatively easily? Or is gcc 5.0 > > support going to require a new release? > > It is not a trivial patch but I think it should apply to 2.3.0 relatively > easily: > > > http://scm.codesynthesis.com/?p=odb/odb.git;a=commit;h=ee9c9f3db3eb4b689e565c282345b1f49bba5042 > I can't get the patch to apply. If I apply it by itself, then it fails: https://kojipkgs.fedoraproject.org//work/tasks/9017/8859017/build.log And applying it after the 4.9.0 patch, also fails: https://kojipkgs.fedoraproject.org//work/tasks/8878/8858878/build.log Alternatively, you can wait for 2.4.0, which is imminent. > What is the definition of imminent? I would like to get this working relatively soon, but it sounds like waiting for 2.4.0 is the best solution and so if it's not too long, then I'll wait til then. Thanks, Dave From davejohansen at gmail.com Sat Feb 7 16:11:10 2015 From: davejohansen at gmail.com (Dave Johansen) Date: Sat Feb 7 16:11:17 2015 Subject: [odb-users] ODB and gcc 5.0? In-Reply-To: References: Message-ID: On Sat, Feb 7, 2015 at 9:26 AM, Dave Johansen wrote: > > On Sat, Feb 7, 2015 at 4:18 AM, Boris Kolpackov > wrote: > >> > Is this something that can be resolved relatively easily? Or is gcc 5.0 >> > support going to require a new release? >> >> It is not a trivial patch but I think it should apply to 2.3.0 relatively >> easily: >> >> >> http://scm.codesynthesis.com/?p=odb/odb.git;a=commit;h=ee9c9f3db3eb4b689e565c282345b1f49bba5042 >> > > I can't get the patch to apply. If I apply it by itself, then it fails: > https://kojipkgs.fedoraproject.org//work/tasks/9017/8859017/build.log > > And applying it after the 4.9.0 patch, also fails: > https://kojipkgs.fedoraproject.org//work/tasks/8878/8858878/build.log > Sorry for the multiple emails. I took a look at the issue with applying the patch and it was pretty simple to resolve. The patch applies now and hopefully wouldn't run into any issues, but now I'm running into an issue with gcc on ARM ( https://bugzilla.redhat.com/show_bug.cgi?id=1190243 ). It looks like someone is looking into it, so hopefully that will be able to be resolved soon. From lordvampyre at gmail.com Sun Feb 8 12:40:03 2015 From: lordvampyre at gmail.com (Diego Fernando) Date: Sun Feb 8 12:40:11 2015 Subject: [odb-users] How generate *-odb. files first Message-ID: How generate *-odb.* files first in qmake. To compile the project I need comment the code in the dao classes that need the -odb files? Thank you From boris at codesynthesis.com Tue Feb 10 12:11:01 2015 From: boris at codesynthesis.com (Boris Kolpackov) Date: Tue Feb 10 12:21:06 2015 Subject: [odb-users] How generate *-odb. files first In-Reply-To: References: Message-ID: Hi Diego, Diego Fernando writes: > How generate *-odb.* files first in qmake. To compile the project I need > comment the code in the dao classes that need the -odb files? The setup described on the Wiki is supposed to achieve exactly that. That is, if the headers have changed, then the -odb files are regenerated first before anything else gets compiled. Note though that they are not regenerated by qmake but rather by the Makefile that it generates. http://wiki.codesynthesis.com/Using_ODB_with_Qt_Creator_on_Linux Boris From boris at codesynthesis.com Wed Feb 11 06:58:40 2015 From: boris at codesynthesis.com (Boris Kolpackov) Date: Wed Feb 11 07:08:45 2015 Subject: [odb-users] ODB 2.4.0 released Message-ID: Hi, We have released ODB 2.4.0. The NEWS file entries for this release are as follows: * Support for bulk operations in Oracle and SQL Server. Bulk operations persist, update, or erase a range of objects using a single database statement execution which often translates to a significantly better performance. For details, refer to Section 15.3, "Bulk Database Operations" in the ODB manual. * Support for object loading views. Object loading views allow loading of one or more complete objects instead of, or in addition to, a subset of data members and with a single SELECT statement execution. For details, refer to Section 10.2, "Object Loading Views" in the ODB manual. * New database class functions, query_one() and query_value(), provide convenient shortcuts for situations where the query is known to return at most one element (query_one) or exactly one element (query_value). Corresponding execute_one() and execute_value() functions for prepared queries are also provided. For details, refer to Sections 4.3, "Executing a Query" and 4.5, "Prepared Queries" in the ODB manual. * Support for defining persistent objects as instantiations of C++ class templates, similar to composite value types. For details, refer to Section 15.2, "Persistent Class Template Instantiations" in the ODB manual. * Support for object and table join types in views. Supported join type are left, right, full, inner, and cross with left being the default. For details, refer to Sections 10.1, "Object Views" and 10.3, "Table Views" in the ODB manual. * Support for result modifiers in view query conditions. Currently supported result modifiers are 'distinct' (which is translated to SELECT DISTINCT) and 'for_update' (which is translated to FOR UPDATE or equivalent for database systems that support it). For details, refer to Section 10.5, "View Query Conditions" in the ODB manual. * Support for persisting std::deque containers. * New pragma, on_delete, allows the specification of an on-delete semantics (translated to the ON DELETE SQL clause) for an object pointer. For more information, refer to Section 14.4.15, "on_delete" in the ODB manual. * Besides odb::stderr_tracer there is now odb::stderr_full_tracer that traces statement preparations and deallocations in addition to their executions. This new implementation can be useful when you want to see the text of a statement that contains a syntax error and therefore will not actually be executed. For more information, refer to Section 3.13, "Tracing SQL Statement Execution" in the ODB manual. * ODB can now compile headers that use #pragma once instead of include guards. * User-supplied prologues and epilogues are now generated outside the pre.hxx/post.hxx includes. This allows the use of precompiled headers with the generated files. * Support for calling MySQL stored procedures. For details and limitations refer to Section 17.7, "MySQL Stored Procedures" in the ODB manual. * Support for calling SQL Server stored procedures. For details and limitations refer to Section 21.7, "SQL Server Stored Procedures" in the ODB manual. * New option, --oracle-warn-truncation, makes ODB warn about SQL names that are longer than 30 characters and are therefore truncated. ODB now also detects when such truncations lead to Oracle name conflicts and issues diagnostics even without this option specified. * For MySQL, PostgreSQL, and SQL Server, ODB now warns when an SQL name exceeds the database limit (64, 63, and 128 characters, respectively). SQLite has no limitation on name lengths. For Oracle, which has a limit that is much more likely to be reached in normal circumstances (30 characters), a more comprehensive detection is implemented (see the item above). * New option, --statement-regex, can be used to process prepared statement names that are used by PostgreSQL. This can be useful, for example, to shorten names that exceed the PostgreSQL name limit. * The --std option now accepts the 'c++14' value. This release also adds support for Visual Studio 2013 (VC++ 12.0), including project/solution files for all the runtimes, tests, and examples. We have also upgraded the private copy of GCC that is used by the ODB compiler binary packages to 4.9.2 (actually, 4.9.3 pre-release) on all the platforms except Solaris (there it remains at 4.7.3). In particular, this should make a difference to projects wishing to use more C++11/C++14 features. A more detailed discussion of the major new features can be found in the following blog post: http://www.codesynthesis.com/~boris/blog/2015/02/11/odb-2-4-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-5.0 C++98,11 x86 32/64 4,5 Y All GNU/Linux Clang 3.5 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 Mac OS X Clang 3.5 C++11 x86 32/64 - - All ex MS SQL Windows VC++ 8.0 C++98 x86 32/64 - Y All 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 Windows VC++ 12.0 C++11 x86 32/64 5 Y All MinGW-W64 GCC 4.9 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, a big thanks goes to Dave Johansen who is maintaining ODB packages for RHEL/CentOS and Timo Rothenpieler who is doing the same for Gentoo. If you are packaging ODB for another distribution, please speak up so that I can announce/acknowledge your work. If you plan to use ODB on Mac OS X or MinGW/MinGW64, there are new installation guides with additional information for these platforms: http://www.codesynthesis.com/products/odb/doc/install-macosx.xhtml http://www.codesynthesis.com/products/odb/doc/install-mingw.xhtml 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: 42bd2a8023e338e004711e755eb30bd122b844a6 libodb-2.4.0.tar.bz2 10ecc193b883e198e4b4c678f1561f280784d629 libodb-2.4.0.tar.gz c6b0486ed4168668e1691dec34d61bddccafa1dc libodb-2.4.0.zip f813702b2856732e199ae34e3393b8cecff878ef libodb-boost-2.4.0.tar.bz2 9fd462c3dc9f0529d78b6301223a28e3b805799c libodb-boost-2.4.0.tar.gz e58b7295ec2319e03afb67d8fa0ac0d16b6eff8d libodb-boost-2.4.0.zip e10174185222e102d63b48eed0d632aad1608512 libodb-mssql-2.4.0.tar.bz2 e5dada5228971cc3eb4ce21a8208e973bb73f2a2 libodb-mssql-2.4.0.tar.gz a476d7fff656792c9e00b2253cc3733086cb6f30 libodb-mssql-2.4.0.zip 2021a67577354f1d6bed50c0b257c1920760eda7 libodb-mysql-2.4.0.tar.bz2 ff146deb9d31158688146ef2be4efa2d567c0574 libodb-mysql-2.4.0.tar.gz 50de4e581d61185ed230255959732617a6f97b08 libodb-mysql-2.4.0.zip dd22ae9f3606e37a25ed8f9a3e9eec81c163fadd libodb-oracle-2.4.0.tar.bz2 56691751e1960b5290fa4c3453fec66ce34b21fe libodb-oracle-2.4.0.tar.gz a8beaa5c0f506f413d3d9fb09a87cbaece870874 libodb-oracle-2.4.0.zip 4628d5e296da01dbaf8658fd402b4f709f30ea2d libodb-pgsql-2.4.0.tar.bz2 3a4414958de7f6d862b444a9895605d501452978 libodb-pgsql-2.4.0.tar.gz a5741062322ad63b9f80c433bb601de6bb705eb9 libodb-pgsql-2.4.0.zip e68b6614cf4f471792979f7f97a8279fdba77527 libodb-qt-2.4.0.tar.bz2 0e5c8f007810285d54df67c6251f5c28fd83c955 libodb-qt-2.4.0.tar.gz 0d9bebf911ca8761b8b3647015398741bed68ee6 libodb-qt-2.4.0.zip 3be07e7702abf8adcbe7736f372ef9980cec1003 libodb-sqlite-2.4.0.tar.bz2 c5cdb8a63dc1b395f03be9551beb4e58733a4b83 libodb-sqlite-2.4.0.tar.gz c95ab4d9f4c7e2828ab2786d9f29e6c55d52f77d libodb-sqlite-2.4.0.zip d000bf71e86dc4d84b56ac40e76f2152acc8e164 odb_2.4.0-1_amd64.deb 68ff71b2e3e7f9dfe3e7426058d5f8b57c6070d3 odb_2.4.0-1_i386.deb 57e7db623ea8c5d43a7fcfdb92e0a58e6adcae96 odb-2.4.0-1.i686.rpm bcba62632c382fd082d41b8366a4578421cb3b4d odb-2.4.0-1.x86_64.rpm f8b5797af1ce185db6adfa1d91ba5c90584d220f odb-2.4.0-i686-linux-gnu.tar.bz2 14d4972b43278b12479950b4a12affe4e4e500c1 odb-2.4.0-i686-macosx.tar.bz2 eca6c124ba4c90d3478049d0b5b43ef5375612fd odb-2.4.0-i686-solaris.tar.bz2 386ae3dd284c20acfcb5a49ed42c2ff5c598e401 odb-2.4.0-i686-windows.zip 83ff71ec663b318cdb95ef0ebd7feefff3123a21 odb-2.4.0-sparc-solaris.tar.bz2 810fc02e591429ed19f5a2699d144fb611fb121b odb-2.4.0.tar.bz2 ad39f381cd2ebc07fa08e3464a44a6ef31ccd2d1 odb-2.4.0.tar.gz 630882a3461a8aa6349fd5b4e5ef20ec9afae09d odb-2.4.0-x86_64-linux-gnu.tar.bz2 22d565fcafa0bd8ff20e11dfd394d3efb52fd8a5 odb-2.4.0.zip 3a9c7c3bee71c069e621c3b14b46dc48e5e1b3c9 odb-examples-2.4.0.tar.bz2 2e9e9629db99311e088e252940e6f604f0646710 odb-examples-2.4.0.tar.gz b0b0b03a8bd274d1bd1aa3c1cb6b177f6b650490 odb-examples-2.4.0.zip 6b8959e58001e165d972ef2057321d6f1ab215f4 odb-tests-2.4.0.tar.bz2 7e6b66a28e70964426b94221c2a324bf2bfa0112 odb-tests-2.4.0.tar.gz aa08204cc0de44f9e502eb9ee3f59818b661808d odb-tests-2.4.0.zip Enjoy, Boris From timo at rothenpieler.org Wed Feb 11 08:10:34 2015 From: timo at rothenpieler.org (Timo Rothenpieler) Date: Wed Feb 11 08:10:42 2015 Subject: [odb-users] odb-2.4.0 fails to compile with internal compiler error Message-ID: <54DB54CA.7050501@rothenpieler.org> Hello, I updated the Gentoo odb overlay to the new 2.4.0 release. While testing, i got the following error while building odb: libtool: compile: x86_64-pc-linux-gnu-g++ -DHAVE_CONFIG_H -I.. -I/var/tmp/portage/dev-db/odb-2.4.0/work/odb-2.4.0 -I/usr/lib/gcc/x86_64-pc-linux-gnu/4.9.2/plugin/include -O2 -pipe -march=native -c /var/tmp/portage/dev-db/odb-2.4.0/work/odb-2.4.0/odb/validator.cxx -fPIC -DPIC -o .libs/validator.o /var/tmp/portage/dev-db/odb-2.4.0/work/odb-2.4.0/odb/validator.cxx:1589:1: internal compiler error: in possible_polymorphic_call_targets, at ipa-devirt.c:1557 } ^ A full buildlog is available here: https://gist.github.com/BtbN/90247d2b7f12bd1b1096 I am using gcc 4.9.2, installed via portage. I was able to track this down to the -O2 option. Building with -O1 or without an -O option works fine. Building with -O2 (even without -pipe and -march=native) makes it fail with above error. Timo -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: OpenPGP digital signature Url : http://codesynthesis.com/pipermail/odb-users/attachments/20150211/265786c6/signature.pgp From boris at codesynthesis.com Wed Feb 11 08:09:35 2015 From: boris at codesynthesis.com (Boris Kolpackov) Date: Wed Feb 11 08:19:39 2015 Subject: [odb-users] odb-2.4.0 fails to compile with internal compiler error In-Reply-To: <54DB54CA.7050501@rothenpieler.org> References: <54DB54CA.7050501@rothenpieler.org> Message-ID: Hi Timo, Timo Rothenpieler writes: > internal compiler error: in possible_polymorphic_call_targets [...] Yes, that's a bug in GCC 4.9 that they took forever to fix. I was promised it will be fixed in 4.9.3 (and 5.0.0): https://bugzilla.redhat.com/show_bug.cgi?id=908577 In the meantime, pass -fno-devirtualize Boris From CWeiguan at dso.org.sg Wed Feb 11 21:29:33 2015 From: CWeiguan at dso.org.sg (Chen Weiguang) Date: Thu Feb 12 04:19:12 2015 Subject: [odb-users] Bidirectional Many-to-Many Relationship Problem Message-ID: <8E85ACDDE5971D40B7BDFE2D3BB399C10138CC15@Gawain.dsonet.corp.root> Hi, I was trying out the bidirectional many-to-many relationship example, as seen in the ODB documentation section 6.2.3. Initially I tried out using std::shared_ptr and std::weak_ptr, and ODB is able to generate the .cxx, .hxx and .ixx files. However when I tried to compile the .cxx file in Visual Studio 2013 (x64), I got a compile error that says: error 2440: '' : cannot convert from 'X *' to 'std::weak_ptr' No constructor could take the source type, or constructor overload resolution was ambiguous. For my example, 'X' and 'Y' are the table/struct names. I took the same example and changed the smart pointers to odb::lazy_shared_ptr and odb::lazy_weak_ptr, and similarly ODB-compiler is able to compile. In this case, the generated .cxx file can be compiled, but when I tried calling .load() method of either the odb::lazy_shared_ptr or odb::lazy_weak_ptr, I would get compile error in my main.cpp that says: ...\odb\include\odb/lazy-ptr.ixx (1153): error C2679: binary '=' : no operator found which takes a right-hand operand of type 'Y *' (or there is no acceptable conversion) ... May I ask if there is any other special requirement/pragma tags that I need to insert into my header files, or any thing that I need to specially note in order to make my example work? I have attached both sets of my example header files (one for std smart pointers, one for odb lazy pointers), and I am using Windows 7 (x64), Visual Studio 2013 (x64) for this example. Thank you. Regards, Weiguang -------------- next part -------------- A non-text attachment was scrubbed... Name: XY-Src.zip Type: application/x-zip-compressed Size: 707 bytes Desc: XY-Src.zip Url : http://codesynthesis.com/pipermail/odb-users/attachments/20150212/70443d0e/XY-Src.bin From aheadgoon at gmail.com Thu Feb 12 03:50:49 2015 From: aheadgoon at gmail.com (=?UTF-8?B?0J3QuNC60L7Qu9Cw0Lkg0KHRgtC+0YDQvtC20LXQvdC60L4=?=) Date: Thu Feb 12 04:19:12 2015 Subject: [odb-users] odb c++ and data preprocessing before persist Message-ID: Good day! I am writing in connection with the problem, that i cant resolve. I want to use your great system (odb c++) in my project. I learned documentation, different webpages and i tried to use it. I have little server that receiving binary data (different c structs and classes) from different nodes. I am checking byte order of binary data that i recieved, and if it need i must run hton/ntoh functions for c struct members and than run persist function. I have no opportunity to convert byte order of data to network byte order before it transmitting to me. Callbacks cant help me, and i cant reload persist or other functions for dynamic byte order checks. Can u help me? Your system is salvation for my project... Kind regards, Nick From boris at codesynthesis.com Thu Feb 12 04:19:08 2015 From: boris at codesynthesis.com (Boris Kolpackov) Date: Thu Feb 12 04:29:12 2015 Subject: [odb-users] Bidirectional Many-to-Many Relationship Problem In-Reply-To: <8E85ACDDE5971D40B7BDFE2D3BB399C10138CC15@Gawain.dsonet.corp.root> References: <8E85ACDDE5971D40B7BDFE2D3BB399C10138CC15@Gawain.dsonet.corp.root> Message-ID: Hi Chen, Chen Weiguang writes: > error 2440: '' : cannot convert from 'X *' to > 'std::weak_ptr' No constructor could take the source type, or > constructor overload resolution was ambiguous. If you look at the line where this error points to, just above it there is a nice comment that explains why you are getting this error. Also, in the first paragraph of Chapter 6, "Relationships", we read: "Any supported smart pointer can be used in a data member as long as it can be explicitly constructed from the canonical object pointer (Section 3.3, "Object and View Pointers")." So I suggest that you read about "canonical object pointer" in Section 3.3 and see if it will all make sense. Boris From boris at codesynthesis.com Thu Feb 12 04:23:13 2015 From: boris at codesynthesis.com (Boris Kolpackov) Date: Thu Feb 12 04:33:17 2015 Subject: [odb-users] odb c++ and data preprocessing before persist In-Reply-To: References: Message-ID: Hi Nick, ??????? ?????????? writes: > I am checking byte order of binary data that i recieved, and if it > need i must run hton/ntoh functions for c struct members and than run > persist function. I have no opportunity to convert byte order of data to > network byte order before it transmitting to me. Callbacks cant help me, > and i cant reload persist or other functions for dynamic byte order checks. Check out virtual data members (Section 14.4.13, "virtual"). The idea is to provide accessors and modifiers that will do the conversion. In fact, you probably don't even need the virtual data member. You can just specify special accessors/modifiers that (only) ODB should use (see Section 14.4.5, "get/set/access"). Boris From aheadgoon at gmail.com Thu Feb 12 09:15:14 2015 From: aheadgoon at gmail.com (=?UTF-8?B?0J3QuNC60L7Qu9Cw0Lkg0KHRgtC+0YDQvtC20LXQvdC60L4=?=) Date: Thu Feb 12 09:39:41 2015 Subject: [odb-users] odb c++ and data preprocessing before persist In-Reply-To: References: Message-ID: 2015-02-12 13:23 GMT+04:00 Boris Kolpackov : > Hi Nick, > > ??????? ?????????? writes: > > > I am checking byte order of binary data that i recieved, and if it > > need i must run hton/ntoh functions for c struct members and than run > > persist function. I have no opportunity to convert byte order of data to > > network byte order before it transmitting to me. Callbacks cant help me, > > and i cant reload persist or other functions for dynamic byte order > checks. > > Check out virtual data members (Section 14.4.13, "virtual"). The idea > is to provide accessors and modifiers that will do the conversion. In > fact, you probably don't even need the virtual data member. You can > just specify special accessors/modifiers that (only) ODB should use > (see Section 14.4.5, "get/set/access"). > > Boris > Great! Thank you! Its work for me! May i ask you a bit more questions? Or it will be better to write in something other place? P.S. do you speak russian? =) From boris at codesynthesis.com Thu Feb 12 09:32:21 2015 From: boris at codesynthesis.com (Boris Kolpackov) Date: Thu Feb 12 09:42:26 2015 Subject: [odb-users] odb c++ and data preprocessing before persist In-Reply-To: References: Message-ID: Hi, ??????? ?????????? writes: > May i ask you a bit more questions? Sure, just follow posting guidelines: http://codesynthesis.com/support/posting-guidelines.xhtml In particular, start a new email thread with a descriptive subject for each questions. > P.S. do you speak russian? =) Yes, I do. Though English should be used for mailing list questions so that other can benefit from the discussion/archives. Boris From eldlistmailingz at tropicsoft.com Thu Feb 12 19:01:19 2015 From: eldlistmailingz at tropicsoft.com (Edward Diener) Date: Thu Feb 12 19:01:25 2015 Subject: [odb-users] Building ODB compiler on Windows using VC++ Message-ID: <54DD3ECF.1020601@tropicsoft.com> I have cloned the git repository for the ODB compiler and have Visual Studio 2013. How can I build the ODB compiler on Windows using Visual Studio ? Although I have mingw and mingw64 I do not want to fool around with MSYS, but if using MSYS is the only way to build odb on Windows I will use that. In the online instruction page for building odb on Windows it says: "Building the ODB compiler from source code on Windows involves a custom build procedure. If you absolutely must build the ODB compiler yourself, write to the odb-users@codesynthesis.com mailing list for more information." Although I do not absolutely have to build the ODB compiler from source code I would like to keep up with source code changes using git and build the compiler from source code myself rather than install it. From eldlistmailingz at tropicsoft.com Thu Feb 12 18:47:42 2015 From: eldlistmailingz at tropicsoft.com (Edward Diener) Date: Thu Feb 12 19:25:08 2015 Subject: [odb-users] Building ODB compiler on Windows using VC++ Message-ID: I have cloned the git repository for the ODB compiler and have Visual Studio 2013. How can I build the ODB compiler on Windows using Visual Studio ? Although I have mingw and mingw64 I do not want to fool around with MSYS, but if using MSYS is the only way to build odb on Windows I will use that. In the online instruction page for building odb on Windows it says: "Building the ODB compiler from source code on Windows involves a custom build procedure. If you absolutely must build the ODB compiler yourself, write to the odb-users@codesynthesis.com mailing list for more information." Although I do not absolutely have to build the ODB compiler from source code I would like to keep up with source code changes using git and build the compiler from source code myself rather than install it. From eldlistmailingz at tropicsoft.com Thu Feb 12 19:30:58 2015 From: eldlistmailingz at tropicsoft.com (Edward Diener) Date: Thu Feb 12 19:31:15 2015 Subject: [odb-users] Re: Building ODB compiler on Windows using VC++ In-Reply-To: References: Message-ID: On 2/12/2015 6:47 PM, Edward Diener wrote: > I have cloned the git repository for the ODB compiler and have Visual > Studio 2013. > > How can I build the ODB compiler on Windows using Visual Studio ? > > Although I have mingw and mingw64 I do not want to fool around with > MSYS, but if using MSYS is the only way to build odb on Windows I will > use that. > > In the online instruction page for building odb on Windows it says: > > "Building the ODB compiler from source code on Windows involves a custom > build procedure. If you absolutely must build the ODB compiler yourself, > write to the odb-users@codesynthesis.com > mailing list for more information." > > Although I do not absolutely have to build the ODB compiler from source > code I would like to keep up with source code changes using git and > build the compiler from source code myself rather than install it. Apologies for the double message. It was done unintentionally. From davejohansen at gmail.com Thu Feb 12 21:21:45 2015 From: davejohansen at gmail.com (Dave Johansen) Date: Thu Feb 12 21:21:51 2015 Subject: [odb-users] ODB 2.4.0 released In-Reply-To: References: Message-ID: On Wed, Feb 11, 2015 at 4:58 AM, Boris Kolpackov wrote: > Hi, > > We have released ODB 2.4.0. The NEWS file entries for this release are > as follows: > For the Fedora users out there, it has been updated in rawhide and will be available when Fedora 22 is released. From CWeiguan at dso.org.sg Thu Feb 12 21:53:51 2015 From: CWeiguan at dso.org.sg (Chen Weiguang) Date: Fri Feb 13 04:55:23 2015 Subject: [odb-users] Bidirectional Relationship Primary Key Message-ID: <8E85ACDDE5971D40B7BDFE2D3BB399C10138DCA8@Gawain.dsonet.corp.root> Hi Boris, I have tables 'X' and 'Y with a bidirectional many-to-many relationship with each other, i.e. 'X' has vector of shared_ptr to 'Y' and 'Y' has vector of weak_ptr to 'X', similar to the example in ODB manual section 6.2.3 Many-to-Many Relationships. Currently I am able to generate the schema for X_Y relationship table (X_id, Y_id), but with no primary key when compiling with ODB compiler. I would like the schema to have either a composite primary key, or unique index across the two fields when compiling with ODB compiler, so as to prevent multiple addition of same relationship. Is there a way to do this? For your information, I am compiling for SQL Server 2008. Thank you for your time and also for your previous help. Regards, Weiguang From boris at codesynthesis.com Fri Feb 13 04:58:56 2015 From: boris at codesynthesis.com (Boris Kolpackov) Date: Fri Feb 13 05:09:00 2015 Subject: [odb-users] ODB 2.4.0 released In-Reply-To: References: Message-ID: Hi Dave, Dave Johansen writes: > For the Fedora users out there, it has been updated in rawhide and will be > available when Fedora 22 is released. That was fast, thanks, Dave! I guess the hard question is what to do with RHELs. I.e., how can we provide 2.4.0 packages for them. Any chance we con convince them to let us upgrade them in EPEL under the pretext that it is still a young and rapidly developing project ;-)? Boris From boris at codesynthesis.com Fri Feb 13 05:16:33 2015 From: boris at codesynthesis.com (Boris Kolpackov) Date: Fri Feb 13 05:26:38 2015 Subject: [odb-users] Building ODB compiler on Windows using VC++ In-Reply-To: References: Message-ID: Hi Edward, Edward Diener writes: > How can I build the ODB compiler on Windows using Visual Studio ? As soon as you can build GCC with Visual Studio ;-). I bet that won't happen any time soon. (any why?) > Although I have mingw and mingw64 I do not want to fool around with > MSYS, but if using MSYS is the only way to build odb on Windows I > will use that. Yes, that's probably the most straightforward way to do it. The way we do it is via a cross compiler from Linux, but that's quite involved. > Although I do not absolutely have to build the ODB compiler from > source code I would like to keep up with source code changes using > git and build the compiler from source code myself rather than > install it. First, a bit of background: Internally, ODB is implemented as a GCC plugin. So, when you run 'odb', underneath it runs GCC which in turn runs a plugin which does most of the work. This all works very smoothly on UNIX-like platforms (e.g., Linux, Mac OS, Solaris) which have a sane dynamic library/loading models. On Windows, however, GCC does not support plugins since nobody managed to implement the dynamic loading part yet. So what we do is apply a patch (a relatively small one, considering what it does) to GCC to support a statically-linked plugin. We then go ahead and link the ODB plugin statically into GCC. All the scripts, patches, and instructions for doing this are publicly available, so with enough determination you could probably build ODB for Windows yourself: http://scm.codesynthesis.com/?p=odb/odb-etc.git;a=tree;f=binary/mingw-w64 The question is, of course, if it is worth the trouble. If you want to use some feature that is only available in the repository, just shout and I will gladly build you a pre-release pack of ODB. I do this all the time: http://codesynthesis.com/~boris/tmp/odb/pre-release/ Boris From boris at codesynthesis.com Fri Feb 13 05:26:27 2015 From: boris at codesynthesis.com (Boris Kolpackov) Date: Fri Feb 13 05:36:31 2015 Subject: [odb-users] Bidirectional Relationship Primary Key In-Reply-To: <8E85ACDDE5971D40B7BDFE2D3BB399C10138DCA8@Gawain.dsonet.corp.root> References: <8E85ACDDE5971D40B7BDFE2D3BB399C10138DCA8@Gawain.dsonet.corp.root> Message-ID: Hi Chen, Chen Weiguang writes: > Currently I am able to generate the schema for X_Y relationship table > (X_id, Y_id), but with no primary key when compiling with ODB compiler. > > I would like the schema to have either a composite primary key, or > unique index across the two fields when compiling with ODB compiler, > so as to prevent multiple addition of same relationship. Is there a > way to do this? The only way to do this currently is by executing a piece of SQL that adds the index (or the primary key) manually, after the schema creation. I.e., ALTER TABLE ADD CONSTRAINT... I've also added a TODO item to support this better. I think the clean way would be the 'unique' pragma that tells ODB there are no duplicate pointers: #pragma db unique // No multiple pointers to the same object. std::vector> objs_; Then ODB can generate the primary key, which I believe is the idiomatic way. Boris From eldlistmailingz at tropicsoft.com Fri Feb 13 11:54:53 2015 From: eldlistmailingz at tropicsoft.com (Edward Diener) Date: Fri Feb 13 11:55:19 2015 Subject: [odb-users] Re: Building ODB compiler on Windows using VC++ In-Reply-To: References: Message-ID: On 2/13/2015 5:16 AM, Boris Kolpackov wrote: > Hi Edward, > > Edward Diener writes: > >> How can I build the ODB compiler on Windows using Visual Studio ? > > As soon as you can build GCC with Visual Studio ;-). I bet that > won't happen any time soon. (any why?) > > >> Although I have mingw and mingw64 I do not want to fool around with >> MSYS, but if using MSYS is the only way to build odb on Windows I >> will use that. > > Yes, that's probably the most straightforward way to do it. The way > we do it is via a cross compiler from Linux, but that's quite > involved. I will follow the path of trying to build ODB using mingw/mingw64 and MSYS. if I cannot I will use pre-built binaries. > > >> Although I do not absolutely have to build the ODB compiler from >> source code I would like to keep up with source code changes using >> git and build the compiler from source code myself rather than >> install it. > > First, a bit of background: > > Internally, ODB is implemented as a GCC plugin. So, when you run > 'odb', underneath it runs GCC which in turn runs a plugin which > does most of the work. This all works very smoothly on UNIX-like > platforms (e.g., Linux, Mac OS, Solaris) which have a sane dynamic > library/loading models. On Windows, however, GCC does not support > plugins since nobody managed to implement the dynamic loading > part yet. So what we do is apply a patch (a relatively small one, > considering what it does) to GCC to support a statically-linked > plugin. We then go ahead and link the ODB plugin statically into > GCC. Thanks for the information. > > All the scripts, patches, and instructions for doing this are publicly > available, so with enough determination you could probably build ODB > for Windows yourself: > > http://scm.codesynthesis.com/?p=odb/odb-etc.git;a=tree;f=binary/mingw-w64 > > The question is, of course, if it is worth the trouble. If you want > to use some feature that is only available in the repository, just > shout and I will gladly build you a pre-release pack of ODB. I do > this all the time: > > http://codesynthesis.com/~boris/tmp/odb/pre-release/ Appreciated. if you have not done so already you might want to think about letting ODB compiler and other parts of ODB be built with CMake. I know that CMake/Ninja works fine on Windows, since I build the latest clang with it all the time. It should equally be useful for building the latest ODB, but maybe there are gotchas there I cannot imagine. That way no one has to play around with MingW/MSYS on Windows, which is always difficult, to build ODB and tools. From boris at codesynthesis.com Mon Feb 16 06:26:52 2015 From: boris at codesynthesis.com (Boris Kolpackov) Date: Mon Feb 16 06:36:57 2015 Subject: [odb-users] Re: Building ODB compiler on Windows using VC++ In-Reply-To: References: Message-ID: Hi Edward, Edward Diener writes: > if you have not done so already you might want to think about > letting ODB compiler and other parts of ODB be built with CMake. I > know that CMake/Ninja works fine on Windows, since I build the > latest clang with it all the time. It should equally be useful for > building the latest ODB, but maybe there are gotchas there I cannot > imagine. Yes, the biggest "gotcha" is the fact that GCC itself cannot be built with CMake. Boris From quentindeldycke at gmail.com Tue Feb 17 06:04:55 2015 From: quentindeldycke at gmail.com (Quentin Deldycke) Date: Tue Feb 17 06:05:03 2015 Subject: [odb-users] 2.4.0: Object loading views with std::map container Message-ID: Hi, I don't understand how to create the view for an object having a map on it. I have a structure like this: class B { int x; int y; int z; } class A { int a; int b; int c; std::map example; } I manage to create the view for other relation (1-1) without any problem for the rest of the data. By the way, using this feature, to dump (threw network) the database, we manage to be 300% faster. And i think we can reach even more increase because there is still 2 queries for ~10 B class for each A class which are run at each iteration. -- Deldycke Quentin From davejohansen at gmail.com Tue Feb 17 09:51:59 2015 From: davejohansen at gmail.com (Dave Johansen) Date: Tue Feb 17 09:52:07 2015 Subject: [odb-users] ODB 2.4.0 released In-Reply-To: References: Message-ID: On Fri, Feb 13, 2015 at 2:58 AM, Boris Kolpackov wrote: > Hi Dave, > > Dave Johansen writes: > > > For the Fedora users out there, it has been updated in rawhide and will > be > > available when Fedora 22 is released. > > That was fast, thanks, Dave! > > I guess the hard question is what to do with RHELs. I.e., how can we > provide 2.4.0 packages for them. Any chance we con convince them to > let us upgrade them in EPEL under the pretext that it is still a young > and rapidly developing project ;-)? > Right now the update policy for EPEL seems to be "whatever the packager is willing to maintain", so I could probably get away with it, but I think the better solution is to just use a "Fedorapeople Repo" ( http://fedoraproject.org/wiki/Fedorapeople_Repos ). I hard started working on this but just never got around to finishing it. Hopefully, I'll be able to wrap it up here in the not too distant future. From boris at codesynthesis.com Tue Feb 17 10:06:53 2015 From: boris at codesynthesis.com (Boris Kolpackov) Date: Tue Feb 17 10:16:57 2015 Subject: [odb-users] ODB 2.4.0 released In-Reply-To: References: Message-ID: Hi Dave, Dave Johansen writes: > Right now the update policy for EPEL seems to be "whatever the packager is > willing to maintain", so I could probably get away with it, Cool, that's pretty flexible. > but I think the better solution is to just use a "Fedorapeople Repo" ( > http://fedoraproject.org/wiki/Fedorapeople_Repos ). Hm, if I understood it correctly, this will be your personal repository of packages. I would imagine some people (and especially companies) might be reluctant to depend on that (rather than the "official" EPEL). Boris From davejohansen at gmail.com Tue Feb 17 10:37:20 2015 From: davejohansen at gmail.com (Dave Johansen) Date: Tue Feb 17 10:37:26 2015 Subject: [odb-users] ODB 2.4.0 released In-Reply-To: References: Message-ID: On Tue, Feb 17, 2015 at 8:06 AM, Boris Kolpackov wrote: > Hi Dave, > > Dave Johansen writes: > > > Right now the update policy for EPEL seems to be "whatever the packager > is > > willing to maintain", so I could probably get away with it, > > Cool, that's pretty flexible. > Yes, it's good and bad. I understand the desired to use the latest and greatest but I personally lean toward the current lackness in the policy to being on the "bad" end of things. The whole point of RHEL is a "stable platform" and updating versions of components kind of throws that idea out the window, so that's why I'm a little hesitant with it updating in EPEL like that. > > but I think the better solution is to just use a "Fedorapeople Repo" ( > > http://fedoraproject.org/wiki/Fedorapeople_Repos ). > > Hm, if I understood it correctly, this will be your personal repository > of packages. I would imagine some people (and especially companies) might > be reluctant to depend on that (rather than the "official" EPEL). > One of the reasons that the "Fedorapeople Repos" were created to address this exact problem. It allows "semi-official" maintenance of newer releases for older releases of Fedora and for RHEL. It definitely doesn't have the same "official" blessing of EPEL, but it is maintained on Fedora servers and the software will be built from the exact same packages that are used for Fedora. So, it could all be auditted or even easily re-built for those that want to get a bit more of an "official" flavor or that have other such concerns. From boris at codesynthesis.com Tue Feb 17 10:35:36 2015 From: boris at codesynthesis.com (Boris Kolpackov) Date: Tue Feb 17 10:52:16 2015 Subject: [odb-users] 2.4.0: Object loading views with std::map container In-Reply-To: References: Message-ID: Hi Quentin, Quentin Deldycke writes: > I don't understand how to create the view for an object having a map on it. > I have a structure like this: > > class B > { > int x; > int y; > int z; > } > > class A > { > int a; > int b; > int c; > std::map example; > } What's the purpose of the view you are trying to create? If it is to efficiently loading an object with a map (or any other container), then there is not much you can do. Containers are "heavy". If you try to load it with a single SELECT statement, then, for each A object, you will get a row for each B object that it contains in a map. All the A data will be simply duplicated. Probably not very efficient. If you don't do it with a single SELECT, then you will have to execute a separate SELECT for the container and then one to load each B object that it points to. I think the most efficient way to load a large number of A objects will be as follows: 1. First load all the B objects that the A objects will point to into the cache. 2. Then load all the A objects you are interested in. So, something like this: #pragma db view object(B) object(A inner) query(distinct) struct B_for_A { shared_ptr b; }; session s; for (auto& b: db.query (odb::query::A::a < 10)) ; // All we need is to get B's into the cache. for (auto& a: db.query (odb::query::a < 10)) { // All the B's come from the cache. } > By the way, using this feature, to dump (threw network) the database, we > manage to be 300% faster. And i think we can reach even more increase > because there is still 2 queries for ~10 B class for each A class which are > run at each iteration. That's an impressive speedup. Let me know how the above approach compares to a straight load, I am very interested. Boris From boris at codesynthesis.com Tue Feb 17 10:43:04 2015 From: boris at codesynthesis.com (Boris Kolpackov) Date: Tue Feb 17 10:53:07 2015 Subject: [odb-users] ODB 2.4.0 released In-Reply-To: References: Message-ID: Hi Dave, Dave Johansen writes: > Yes, it's good and bad. I understand the desired to use the latest and > greatest but I personally lean toward the current lackness in the policy to > being on the "bad" end of things. The whole point of RHEL is a "stable > platform" and updating versions of components kind of throws that idea out > the window, so that's why I'm a little hesitant with it updating in EPEL > like that. I always thought that the "initial" RHEL release is the conservative, stable platforms. If, however, someone wants something more recent, EPEL is the place to look. If not, what's the EPEL's purpose then? But since you are doing the work, you have the final say ;-). I personally always feel hesitant installing anything from personal repositories. You never know if the stuff will still be there tomorrow. Boris From quentindeldycke at gmail.com Tue Feb 17 11:21:27 2015 From: quentindeldycke at gmail.com (Quentin Deldycke) Date: Tue Feb 17 11:21:35 2015 Subject: [odb-users] 2.4.0: Object loading views with std::map container In-Reply-To: References: Message-ID: Boris, The purpose of this is a compatibility layer with an old application. Where i don't want to enter the high-level code. I want only to operate at low level. Mainly, the old system disable: - optimized views - lazy loading For new code, we use lazy loading. With it we can achieve really good performance also. With the old code, for one object, we had ~15 SELECT queries (at each iteration of loop) + 2 SELECT for maps for object under it (1-1 relations). This switch from 16 queries to 1 (+ 2 at iteration for maps) give us this performance bump. I wanted to see if to continue this and switch to 1 unique SELECT would be better for my usage. I am implementing this evolution to my solution, (with maps still loading at iteration). I will send you the performance improvement across all system. We have some treatments > 1h where we would be happy to see such improvements. Then i will see how i can impement the maps improvement. As i am not sure of the improvement it will be. -- Deldycke Quentin On 17 February 2015 at 16:35, Boris Kolpackov wrote: > Hi Quentin, > > Quentin Deldycke writes: > > > I don't understand how to create the view for an object having a map on > it. > > I have a structure like this: > > > > class B > > { > > int x; > > int y; > > int z; > > } > > > > class A > > { > > int a; > > int b; > > int c; > > std::map example; > > } > > What's the purpose of the view you are trying to create? If it is > to efficiently loading an object with a map (or any other container), > then there is not much you can do. Containers are "heavy". > > If you try to load it with a single SELECT statement, then, for each > A object, you will get a row for each B object that it contains in > a map. All the A data will be simply duplicated. Probably not very > efficient. > > If you don't do it with a single SELECT, then you will have to execute > a separate SELECT for the container and then one to load each B object > that it points to. > > I think the most efficient way to load a large number of A objects > will be as follows: > > 1. First load all the B objects that the A objects will point to into > the cache. > > 2. Then load all the A objects you are interested in. > > So, something like this: > > #pragma db view object(B) object(A inner) query(distinct) > struct B_for_A > { > shared_ptr b; > }; > > session s; > for (auto& b: db.query (odb::query::A::a < 10)) > ; // All we need is to get B's into the cache. > > for (auto& a: db.query (odb::query::a < 10)) > { > // All the B's come from the cache. > } > > > > By the way, using this feature, to dump (threw network) the database, we > > manage to be 300% faster. And i think we can reach even more increase > > because there is still 2 queries for ~10 B class for each A class which > are > > run at each iteration. > > That's an impressive speedup. Let me know how the above approach compares > to a straight load, I am very interested. > > Boris > From davejohansen at gmail.com Tue Feb 17 12:07:44 2015 From: davejohansen at gmail.com (Dave Johansen) Date: Tue Feb 17 12:07:51 2015 Subject: [odb-users] ODB 2.4.0 released In-Reply-To: References: Message-ID: On Tue, Feb 17, 2015 at 8:43 AM, Boris Kolpackov wrote: > Hi Dave, > > Dave Johansen writes: > > > Yes, it's good and bad. I understand the desired to use the latest and > > greatest but I personally lean toward the current lackness in the policy > to > > being on the "bad" end of things. The whole point of RHEL is a "stable > > platform" and updating versions of components kind of throws that idea > out > > the window, so that's why I'm a little hesitant with it updating in EPEL > > like that. > > I always thought that the "initial" RHEL release is the conservative, > stable platforms. If, however, someone wants something more recent, > EPEL is the place to look. If not, what's the EPEL's purpose then? > The EPEL's purpose is to provide additional packages beyond what RedHat included in RHEL and not "newer ones". It cannot provide a package that is already in RHEL. For examples, occasionally a later point release of RHEL will add a package that is already in EPEL and at that point the package must be removed from EPEL, even if it's a different version than what was added by RHEL. If you're interested, you can see all the details here ( https://fedoraproject.org/wiki/EPEL ). > But since you are doing the work, you have the final say ;-). I > personally always feel hesitant installing anything from personal > repositories. You never know if the stuff will still be there > tomorrow. > That's part of what the "Fedorapeople Repos" is trying to address. It's at least hosted on a "trusted" server and was created by a "proven packager" so it won't just disappear and should have the same (or at least similar) level of trust as what you'd have in Fedora. From mne at qosmotec.com Wed Feb 18 08:25:32 2015 From: mne at qosmotec.com (Marcel Nehring) Date: Wed Feb 18 08:26:57 2015 Subject: [odb-users] Storing files in an oracle database Message-ID: Hello all, I want to use Oracle's BFILE column type to store a binary file in the database. ODB does not come with a mapping for this DB type and I don't want to have the possibly large file floating around in memory anyway. My first idea was to use something like a virtual data member without having any representation of it in my persistent class. I want ODB to generate an additional column of type BFILE in my table but I don't want to have a member representing this column in my class. Instead I thought of loading the corresponding file manually in chunks and store it locally on disk. However, ODB does not support such virtual data members and I don't have any idea on how to manually load the file from the database using only ODB. Custom mapping functions would require to have a data member in my class representing the file which I would like to avoid. Anyone already used ODB with BFILE columns? Any suggestions how to handle BFILE columns with ODB? A completely different approach might also be an option. Regards, Marcel From boris at codesynthesis.com Wed Feb 18 10:19:14 2015 From: boris at codesynthesis.com (Boris Kolpackov) Date: Wed Feb 18 10:29:18 2015 Subject: [odb-users] Storing files in an oracle database In-Reply-To: References: Message-ID: Hi Marcel, Marcel Nehring writes: > I want to use Oracle's BFILE column type to store a binary file in the > database. ODB does not come with a mapping for this DB type and I don't > want to have the possibly large file floating around in memory anyway. ODB can be smarter than that. For example, for LOBs we use locators and pump the data in/out in chunks via a callback mechanism. > My first idea was to use something like a virtual data member without > having any representation of it in my persistent class. I want ODB to > generate an additional column of type BFILE in my table but I don't > want to have a member representing this column in my class. Instead > I thought of loading the corresponding file manually in chunks and > store it locally on disk. Skimming through the OCI docs, BFILE appears to be special in that on INSERT or UPDATE you specify the file name, not its data. Not sure what SELECT returns... I wonder if there is a way to cast BFILE to BLOB? If this were possible then you could map BFILE to BLOB and use the BFILENAME function for INSERT and UPDATE (the 'to' expression) and cast to BLOB for SELECT (the 'from' expression). See Section 14.8, "Database Type Mapping Pragmas". Boris From alex-beimler at web.de Tue Feb 17 21:33:52 2015 From: alex-beimler at web.de (Alex Beimler) Date: Thu Feb 19 09:57:35 2015 Subject: [odb-users] libodb with cmake Message-ID: <54E3FA10.1080809@web.de> Hello, Is there a Full Support of cmake for libodb, libodb-sqlite, libodb-... I mean not the odb-Compiler (already solved this Problem) or the FindPackage-Modul. Actually i use the ExternProject Module of cmake to build libodb. ExternalProject_Add(libodb SOURCE_DIR ${THRIDPARTY_DIR}/libodb PREFIX ${CMAKE_CURRENT_BINARY_DIR} CONFIGURE_COMMAND ./configure --prefix=${CMAKE_CURRENT_BINARY_DIR} BUILD_COMMAND make install INSTALL_COMMAND "" INSTALL_DIR ${CMAKE_CURRENT_BINARY_DIR} BUILD_IN_SOURCE 1) ExternalProject_Add(libodb-sqlite DEPENDS libodb sqlite3 SOURCE_DIR ${THRIDPARTY_DIR}/libodb-sqlite PREFIX ${CMAKE_CURRENT_BINARY_DIR} CONFIGURE_COMMAND ./configure --with-libodb=${ODB_LIBRARY_DIR} --prefix=${CMAKE_CURRENT_BINARY_DIR} BUILD_COMMAND make install INSTALL_DIR ${CMAKE_CURRENT_BINARY_DIR} INSTALL_COMMAND "" BUILD_IN_SOURCE 1) or (in older Projects) use FindPackage-Module, compile libodb manually (./configure, make install into /usr/local) (Not really Cross-platform) Its works but i have same Problems. 1. the obj-Files are make into the SourceCode-Dir not in the ${CMAKE_CURRENT_BINARY_DIR}. The Libs just "install" into the ${CMAKE_CURRENT_BINARY_DIR}. 2. Not sure what Variables/Configures are set. 3. Whats about the (Cross)Compiler(Flags), System-include/lib path, BuildType, ... 4. Dependency Hell, libodb-.. needs libodb, (profile) needs boost, Qt, ... needs DB-lib 5. Switch from shared-lib to static-lib (build only static-lib), libodb-sqlite.a vs libodb.so 6. Switch/Enable/Disable libodb-DB MySQL vs. PGSQL, SQLite only for Tests, Develop vs. Productive (separate sql-Statements) Most of the configurations were so easy to maintain with cmake. (Variables, Settings, if-statements, cmake-gui, ...) From boris at codesynthesis.com Thu Feb 19 09:55:08 2015 From: boris at codesynthesis.com (Boris Kolpackov) Date: Thu Feb 19 10:05:34 2015 Subject: [odb-users] libodb with cmake In-Reply-To: <54E3FA10.1080809@web.de> References: <54E3FA10.1080809@web.de> Message-ID: Hi Alex, Alex Beimler writes: > Is there a Full Support of cmake for libodb, libodb-sqlite, libodb-... > I mean not the odb-Compiler (already solved this Problem) or the > FindPackage-Modul. Ok, you mean building the ODB runtimes with CMake. No, there is no such support and I have no immediate plans to implement it (really don't like CMake). But if someone is prepared to implement this and maintain it afterwards, then I can consider adding them to the package. In fact, the VC++ projects/solutions and the autotools-based build system are all automatically generated by the 'build', our own make-based development build system. Nothing will prevent us from doing the same for CMake. So the main effort will be to come up with the initial implementation. Boris From beimler at jaeschke.de Thu Feb 19 13:43:37 2015 From: beimler at jaeschke.de (Alex Beimler) Date: Fri Feb 20 07:35:45 2015 Subject: [odb-users] libodb with cmake In-Reply-To: References: <54E3FA10.1080809@web.de> Message-ID: <54E62ED9.50107@jaeschke.de> Hmmm ok, Is there a option to setup the build-dir for the obj-Files? I have the Problem to build libodb and libodb-sqlite as static lib. I think the Problem is the linker chooses the shared lib instead of the static lib. There is a Linker-Error of undefined reference to odb::statments::.. (and other odb-functions): lib/libodb-sqlite.a(statement.o): In Funktion `odb::sqlite::statement::~statement()': ./thirdparty/libodb-sqlite/odb/sqlite/statement.cxx:25: undefined reference to `odb::statement::~statement()' lib/libodb-sqlite.a(statement.o): In Funktion `odb::sqlite::statement::init(char const*, unsigned long, odb::sqlite::statement_kind, odb::sqlite::binding const*, bool)': ./thirdparty/libodb-sqlite/odb/sqlite/statement.cxx:73: undefined reference to `odb::statement::process_update(char const*, void const* const*, unsigned long, unsigned long, char, std::string&)' ..... lib/libodb-sqlite.a(connection-factory.o):(.rodata._ZTVN3odb6sqlite25single_connection_factory17single_connectionE[_ZTVN3odb6sqlite25single_connection_factory17single_connectionE]+0x30): undefined reference to `odb::connection::cache_query_(odb::prepared_query_impl*, std::type_info const&, void*, std::type_info const*, void (*)(void*))' lib/libodb-sqlite.a(connection-factory.o):(.rodata._ZTVN3odb6sqlite23connection_pool_factory17pooled_connectionE[_ZTVN3odb6sqlite23connection_pool_factory17pooled_connectionE]+0x30): undefined reference tof `odb::connection::cache_query_(odb::prepared_query_impl*, std::type_info const&, void*, std::type_info const*, void (*)(void*))' My application links: g++ ... -std=c++14 ... -g -Wall .......cpp.o ... ...-odb.cxx.o ... -o application ... libodb.a libodb-sqlite.a thirdparty/sqlite3/libsqlite3-static.a -lpthread -ldl I use the --with-libodb=${OUT_BUILD_DIR} to set libpath, but it does not work if i have already a shared lib (maybe in /usr/local/lib or /usr/lib): libodb-sqlite is build with: gcc ... -L${OUT_BUILD_DIR} -lodb -lsqlite3 -lpthread What if i have build sqlite3 as static lib and use this in my project but libodb-sqlite chooses the shared librarys from systempath (/use/shared/lib). But if i link my application this way: g++ ... -std=c++14 ... -g -Wall .......cpp.o ... ...-odb.cxx.o ... -o application ... libodb.so libodb-sqlite.a thirdparty/sqlite3/libsqlite3-static.a -lpthread -ldl it works, but dont feel right. Am 19.02.2015 um 15:55 schrieb Boris Kolpackov: > Hi Alex, > > Alex Beimler writes: > >> Is there a Full Support of cmake for libodb, libodb-sqlite, libodb-... >> I mean not the odb-Compiler (already solved this Problem) or the >> FindPackage-Modul. > Ok, you mean building the ODB runtimes with CMake. No, there is > no such support and I have no immediate plans to implement it > (really don't like CMake). > > But if someone is prepared to implement this and maintain it > afterwards, then I can consider adding them to the package. > > In fact, the VC++ projects/solutions and the autotools-based > build system are all automatically generated by the 'build', > our own make-based development build system. Nothing will > prevent us from doing the same for CMake. So the main effort > will be to come up with the initial implementation. > > Boris From lordvampyre at gmail.com Thu Feb 19 19:05:06 2015 From: lordvampyre at gmail.com (Diego Fernando) Date: Fri Feb 20 07:35:45 2015 Subject: [odb-users] How generate *-odb. files first In-Reply-To: References: Message-ID: Hi Boris... Sorry for not having answered before.... This is my .pro #------------------------------------------------- # # Project created by QtCreator 2015-01-27T14:55:16 # #------------------------------------------------- QT -= gui TARGET = DRM TEMPLATE = lib DEFINES += DRM_LIBRARY CONFIG += dll c++14 CONFIG += debug_and_release DESTDIR += "lib" LIBS += -L"lib" CONFIG(debug, debug|release) { } else { } # CONFIG(debug, debug|release) SOURCES += \ src/validator/validatorrct.cpp \ src/validator/validatorsiac.cpp \ src/validator/validatorsial.cpp \ src/validator/validatorsiam.cpp \ src/validator/validatorsiap.cpp \ src/validator/validatorsiba.cpp \ src/validator/validatorsice.cpp \ src/validator/validatorsidf.cpp \ src/validator/validatorsies.cpp \ src/validator/validatorsigo.cpp \ src/validator/validatorsima.cpp \ src/validator/validatorsimg.cpp \ src/validator/validatorsims.cpp \ src/validator/validatorsimt.cpp \ src/validator/validatorsipa.cpp \ src/validator/validatorsipb.cpp \ src/validator/validatorsipe.cpp \ src/validator/validatorsipi.cpp \ src/validator/validatorsipr.cpp \ src/validator/validatorsirj.cpp \ src/validator/validatorsirn.cpp \ src/entity/branch.cpp \ src/entity/city.cpp \ src/entity/country.cpp \ src/entity/paymentform.cpp \ src/entity/employee.cpp \ src/entity/account.cpp \ src/entity/carrier.cpp \ src/entity/supplier.cpp \ src/entity/customer.cpp \ src/entity/cfop.cpp \ src/entity/product.cpp \ src/entity/group.cpp \ src/entity/brand.cpp \ src/entity/chartsaccount.cpp \ src/entity/service.cpp \ src/dao/citydao.cpp HEADERS +=\ include/drm_global.h \ include/validator/validatorsiac.h \ include/validator/validatorsial.h \ include/validator/validatorsiam.h \ include/validator/validatorsiap.h \ include/validator/validatorsiba.h \ include/validator/validatorsice.h \ include/validator/validatorsidf.h \ include/validator/validatorsies.h \ include/validator/validatorsigo.h \ include/validator/validatorsima.h \ include/validator/validatorsimg.h \ include/validator/validatorsims.h \ include/validator/validatorsimt.h \ include/validator/validatorsipa.h \ include/validator/validatorsipb.h \ include/validator/validatorsipe.h \ include/validator/validatorsipi.h \ include/validator/validatorsipr.h \ include/validator/validatorsirj.h \ include/validator/validatorsirn.h \ include/validator/validatorrct.h \ include/entity/branch.h \ include/entity/city.h \ include/entity/country.h \ include/entity/paymentform.h \ include/entity/employee.h \ include/entity/account.h \ include/entity/carrier.h \ include/entity/cfop.h \ include/entity/customer.h \ include/entity/product.h \ include/entity/supplier.h \ include/entity/group.h \ include/entity/brand.h \ include/entity/chartsaccount.h \ include/entity/service.h \ include/dao/databasehelper.h \ include/dao/icitydao.h \ include/dao/citydao.h unix { target.path = /usr/lib INSTALLS += target } # List of header files that should be compiled with the ODB compiler. # ODB_FILES +=\ include/entity/city.h \ include/entity/account.h \ include/entity/branch.h \ include/entity/brand.h \ include/entity/carrier.h \ include/entity/cfop.h \ include/entity/chartsaccount.h \ include/entity/country.h \ include/entity/customer.h \ include/entity/employee.h \ include/entity/group.h \ include/entity/paymentform.h \ include/entity/product.h \ include/entity/service.h \ include/entity/supplier.h # ODB compiler flags. # ODB_FLAGS = --database pgsql --profile qt --generate-schema --generate-query --generate-session --std c++14 --hxx-suffix .h --schema-format embedded --include-prefix ./include/entity/ --include-regex $$re_escape(%./include/entity/(.+)-odb.h%\1-odb.h%) --include-regex $$re_escape(%./include/entity/(.+)-odb.ixx%\1-odb.ixx%) --include-regex $$re_escape(%../entity/(.+)-odb.h%\1-odb.h%) # Select the database we are going to use. # #DEFINES += DATABASE_PGSQL # Suppress unknown pragmas GCC warnings. # QMAKE_CXXFLAGS_WARN_ON = $$QMAKE_CXXFLAGS_WARN_ON -Wno-unknown-pragmas # Link to the ODB runtime libraries. # LIBS += -L"/usr/local/lib" LIBS += -lodb-pgsql LIBS += -lodb-qt LIBS += -lodb # ODB compilation rules. Normally you don't need to change anything here. # # Add the Qt headers directory to the ODB include directory list. # ODB_FLAGS += -I$$[QT_INSTALL_HEADERS] # Newer versions of QtCreator do builds in a separate directory. As a # result, we need to append the source directory to ODB files. # for(dir, ODB_FILES) { ODB_PWD_FILES += $$PWD/$${dir} } odb.name = odb ${QMAKE_FILE_IN} odb.input = ODB_PWD_FILES odb.output = ${QMAKE_FILE_BASE}-odb.cxx odb.commands = odb $$ODB_FLAGS ${QMAKE_FILE_IN} odb.depends = $$ODB_PWD_FILES odb.variable_out = SOURCES odb.clean = ${QMAKE_FILE_BASE}-odb.cxx ${QMAKE_FILE_BASE}-odb.hxx ${QMAKE_FILE_BASE}-odb.ixx ${QMAKE_FILE_BASE}.sql ${QMAKE_FILE_BASE}-odb.h QMAKE_EXTRA_COMPILERS += odb odbh.name = odb ${QMAKE_FILE_IN} odbh.input = ODB_PWD_FILES odbh.output = ${QMAKE_FILE_BASE}-odb.hxx odbh.commands = @true odbh.CONFIG = no_link odbh.depends = ${QMAKE_FILE_BASE}-odb.cxx QMAKE_EXTRA_COMPILERS += odbh It doesn't generate -odb.** first Thank you 2015-02-10 15:11 GMT-02:00 Boris Kolpackov : > Hi Diego, > > Diego Fernando writes: > > > How generate *-odb.* files first in qmake. To compile the project I need > > comment the code in the dao classes that need the -odb files? > > The setup described on the Wiki is supposed to achieve exactly that. > That is, if the headers have changed, then the -odb files are > regenerated first before anything else gets compiled. Note though > that they are not regenerated by qmake but rather by the Makefile > that it generates. > > http://wiki.codesynthesis.com/Using_ODB_with_Qt_Creator_on_Linux > > Boris > From boris at codesynthesis.com Fri Feb 20 07:31:19 2015 From: boris at codesynthesis.com (Boris Kolpackov) Date: Fri Feb 20 07:41:44 2015 Subject: [odb-users] How generate *-odb. files first In-Reply-To: References: Message-ID: Hi Diego, Diego Fernando writes: > This is my .pro > > [...] > > It doesn't generate -odb.** first Then you will have to figure out why. I suggest you do the following: 1. Follow the steps described on the Wiki precisely and create a simple project. 2. Verify that it does generate the -odb files first. 3. Compare that project to yours and see if you can spot what is causing yours not to work. 4. If you can't, start adding parts of your project to the simple one bit by bit, verifying that after each step everything works as expected. Boris From boris at codesynthesis.com Fri Feb 20 07:39:18 2015 From: boris at codesynthesis.com (Boris Kolpackov) Date: Fri Feb 20 07:49:44 2015 Subject: [odb-users] libodb with cmake In-Reply-To: <54E62ED9.50107@jaeschke.de> References: <54E3FA10.1080809@web.de> <54E62ED9.50107@jaeschke.de> Message-ID: Hi Alex, Alex Beimler writes: > Is there a option to setup the build-dir for the obj-Files? This is a standard autotools build system. You can build out-of-tree. > My application links: > g++ ... -std=c++14 ... -g -Wall .......cpp.o ... ...-odb.cxx.o ... > -o application ... libodb.a libodb-sqlite.a When linking statically, the order in which you list libraries is important. You need to go from the most specific to the most generic. So it should be libodb-sqlite.a libodb.a. Note also that you can disable building of shared/static libraries with the --disable-shared/--disable-static configure options. Finally, for completeness, if you have both shared and static libraries, then the linker will prefer the shared. To change this, you can use the -Wl,-Bstatic and -Wl,-Bdynamic options on the g++ command line, e.g., g++ ... -Wl,-Bstatic -lodb-sqlite -lodb -Wl,-Bdynamic ... Boris From lordvampyre at gmail.com Sat Feb 21 06:29:45 2015 From: lordvampyre at gmail.com (Diego Fernando) Date: Sat Feb 21 06:29:53 2015 Subject: [odb-users] How generate *-odb. files first In-Reply-To: References: Message-ID: Hi Boris Thank you... In .pro file was odbh.output = ${QMAKE_FILE_BASE}-odb.hxx I change to odbh.output = ${QMAKE_FILE_BASE}-odb.h And now apparently the problem is solved. Thank you Diego Fernando 2015-02-20 10:31 GMT-02:00 Boris Kolpackov : > Hi Diego, > > Diego Fernando writes: > > > This is my .pro > > > > [...] > > > > It doesn't generate -odb.** first > > Then you will have to figure out why. I suggest you do the following: > > 1. Follow the steps described on the Wiki precisely and create a > simple project. > > 2. Verify that it does generate the -odb files first. > > 3. Compare that project to yours and see if you can spot what is > causing yours not to work. > > 4. If you can't, start adding parts of your project to the simple > one bit by bit, verifying that after each step everything works > as expected. > > Boris > From alex-beimler at web.de Fri Feb 20 10:13:06 2015 From: alex-beimler at web.de (Alex Beimler) Date: Mon Feb 23 08:00:59 2015 Subject: [odb-users] libodb with cmake In-Reply-To: References: <54E3FA10.1080809@web.de> <54E62ED9.50107@jaeschke.de> Message-ID: <54E74F02.8010105@web.de> thx it works in this order, libodb-sqlite.a libodb.a libsqlite3-static.a also change my cmake-script for the out-of-tree build: ExternalProject_Add(libodb PREFIX ${CMAKE_CURRENT_BINARY_DIR} SOURCE_DIR ${THRIDPARTY_DIR}/libodb CONFIGURE_COMMAND ${THRIDPARTY_DIR}/libodb/configure --prefix=${CMAKE_CURRENT_BINARY_DIR} BINARY_DIR ${CMAKE_CURRENT_BINARY_DIR}/libodb BUILD_COMMAND make install INSTALL_COMMAND "" INSTALL_DIR ${CMAKE_CURRENT_BINARY_DIR}) ExternalProject_Add(libodb-sqlite DEPENDS libodb sqlite3 PREFIX ${CMAKE_CURRENT_BINARY_DIR} SOURCE_DIR ${THRIDPARTY_DIR}/libodb-sqlite CONFIGURE_COMMAND ${THRIDPARTY_DIR}/libodb-sqlite/configure --with-libodb=${ODB_LIBRARY_DIR} --prefix=${CMAKE_CURRENT_BINARY_DIR} BINARY_DIR ${CMAKE_CURRENT_BINARY_DIR}/libodb-sqlite BUILD_COMMAND make install INSTALL_DIR ${CMAKE_CURRENT_BINARY_DIR} INSTALL_COMMAND "") Am 20.02.2015 um 13:39 schrieb Boris Kolpackov: > Hi Alex, > > Alex Beimler writes: > >> Is there a option to setup the build-dir for the obj-Files? > This is a standard autotools build system. You can build out-of-tree. > > >> My application links: >> g++ ... -std=c++14 ... -g -Wall .......cpp.o ... ...-odb.cxx.o ... >> -o application ... libodb.a libodb-sqlite.a > When linking statically, the order in which you list libraries is > important. You need to go from the most specific to the most > generic. So it should be libodb-sqlite.a libodb.a. > > Note also that you can disable building of shared/static libraries > with the --disable-shared/--disable-static configure options. > > Finally, for completeness, if you have both shared and static > libraries, then the linker will prefer the shared. To change > this, you can use the -Wl,-Bstatic and -Wl,-Bdynamic options > on the g++ command line, e.g., > > g++ ... -Wl,-Bstatic -lodb-sqlite -lodb -Wl,-Bdynamic ... > > Boris From jnw at xs4all.nl Thu Feb 26 12:37:38 2015 From: jnw at xs4all.nl (Jeroen N. Witmond [Bahco]) Date: Thu Feb 26 12:37:47 2015 Subject: [odb-users] odb::result does not contain members "const_iterator" and "end () const". Message-ID: <57104e618f4c282fda0f9f214e502ca3.squirrel@webmail.xs4all.nl> Greetings, As far as I can see this has not yet been discussed on this mailing list. While experimenting with ODB I noticed that odb::result does not contain members "const_iterator" and "end () const". The compiler noticed it, anyway. :-) Is this a bug or a feature? Full source to demonstrate this is available on request. Regards, Jeroen. From jnw at xs4all.nl Thu Feb 26 12:45:47 2015 From: jnw at xs4all.nl (Jeroen N. Witmond [Bahco]) Date: Thu Feb 26 12:45:54 2015 Subject: [odb-users] Compile error when combining query::[member].in_range and query::_ref([var]) Message-ID: <6a2068ce2e5530a25ca973e91cf14ba4.squirrel@webmail.xs4all.nl> Greetings, As far as I can see this has not yet been discussed on this mailing list. While experimenting with ODB I ran into a problem in compiling a query using in_range(), best described by the following code fragment: #if 0 // This does not compile. result r (db->query (query::latitude.in_range(query::_ref(lat_min), query::_ref(lat_max)) && query::longitude.in_range(query::_ref(lon_min), query::_ref(lon_max)))); #else // and this does. result r (db->query (query::latitude > query::_ref(lat_min) && query::latitude < query::_ref(lat_max) && query::longitude > query::_ref(lon_min) && query::longitude < query::_ref(lon_max) ) ); #endif The compiler I'm using is $ g++ -v Using built-in specs. COLLECT_GCC=g++ COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.7/lto-wrapper Target: x86_64-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Debian 4.7.2-5' --with-bugurl=file:///usr/share/doc/gcc-4.7/README. Bugs --enable-languages=c,c++,go,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-4.7 --enable-shared --enable-linker-bui ld-id --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/ include/c++/4.7 --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstd cxx-time=yes --enable-gnu-unique-object --enable-plugin --enable-objc-gc --with-arch-32=i586 --with-tune=generic --enable-che cking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu Thread model: posix gcc version 4.7.2 (Debian 4.7.2-5) The messages it produces are beyond my comprehension. Full source to demonstrate this problem is available on request. Regards, Jeroen. From jnw at xs4all.nl Thu Feb 26 12:51:25 2015 From: jnw at xs4all.nl (Jeroen N. Witmond [Bahco]) Date: Thu Feb 26 12:51:32 2015 Subject: [odb-users] ODB used is version 2.4.0 downloaded on Feb 20, 2015 Message-ID: <4f0a1d43d6058858cbda31595cb28cbd.squirrel@webmail.xs4all.nl> In my previous two mails I should have mentioned that the ODB used is version 2.4.0 downloaded on Feb 20, 2015. Regards, Jeroen. From boris at codesynthesis.com Fri Feb 27 06:08:31 2015 From: boris at codesynthesis.com (Boris Kolpackov) Date: Fri Feb 27 06:19:00 2015 Subject: [odb-users] odb::result does not contain members "const_iterator" and "end () const". In-Reply-To: <57104e618f4c282fda0f9f214e502ca3.squirrel@webmail.xs4all.nl> References: <57104e618f4c282fda0f9f214e502ca3.squirrel@webmail.xs4all.nl> Message-ID: Hi Jeroen, Jeroen N. Witmond [Bahco] writes: > While experimenting with ODB I noticed that odb::result does not > contain members "const_iterator" and "end () const". Result is a stream-like object and result::iterator is an input iterator. In this light, it doesn't make much sense to have a const_iterator since advancing the iterator changes the result. > The compiler noticed it, anyway. :-) Can you show the code fragment that triggered it? Boris From boris at codesynthesis.com Fri Feb 27 06:12:28 2015 From: boris at codesynthesis.com (Boris Kolpackov) Date: Fri Feb 27 06:22:58 2015 Subject: [odb-users] Compile error when combining query::[member].in_range and query::_ref([var]) In-Reply-To: <6a2068ce2e5530a25ca973e91cf14ba4.squirrel@webmail.xs4all.nl> References: <6a2068ce2e5530a25ca973e91cf14ba4.squirrel@webmail.xs4all.nl> Message-ID: Hi Jeroen, Jeroen N. Witmond [Bahco] writes: > result r (db->query > (query::latitude.in_range(query::_ref(lat_min), > query::_ref(lat_max)) && > query::longitude.in_range(query::_ref(lon_min), > query::_ref(lon_max)))); in_range() expects a pair of iterators. What you want is in(). Boris From jnw at xs4all.nl Fri Feb 27 12:47:25 2015 From: jnw at xs4all.nl (Jeroen N. Witmond [Bahco]) Date: Fri Feb 27 12:47:33 2015 Subject: [odb-users] odb::result does not contain members "const_iterator" and "end () const". In-Reply-To: References: <57104e618f4c282fda0f9f214e502ca3.squirrel@webmail.xs4all.nl> Message-ID: Hi Boris, Boris Kolpackov wrote: > Hi Jeroen, > > Jeroen N. Witmond [Bahco] writes: > >> While experimenting with ODB I noticed that odb::result does not >> contain members "const_iterator" and "end () const". > > Result is a stream-like object and result::iterator is an input > iterator. In this light, it doesn't make much sense to have a > const_iterator since advancing the iterator changes the result. > > >> The compiler noticed it, anyway. :-) > > Can you show the code fragment that triggered it? #include #include /* This class should be in a separate .hpp file and contain some * #pragmas. The generated odb.hxx file should be included. However, * the current content is sufficient to demonstrate the use of const. */ class FourPoint { public: double latitude; }; typedef odb::result result; inline std::ostream& operator<<(std::ostream& out, const result& val) { for (result::const_iterator i (val.begin ()); i != val.end (); ++i) out << *i << std::endl; return out; } This code results in the following errors: noconstiter.cpp: In function ?std::ostream& operator<<(std::ostream&, const result&)?: noconstiter.cpp:18:8: error: ?const_iterator? is not a member of ?result {aka odb::result}? noconstiter.cpp:18:31: error: expected ?;? before ?i? noconstiter.cpp:18:49: error: ?i? was not declared in this scope noconstiter.cpp:18:63: error: no matching function for call to ?odb::result::end() const? noconstiter.cpp:18:63: note: candidate is: In file included from /usr/local/include/odb/prepared-query.hxx:12:0, from /usr/local/include/odb/database.hxx:27, from noconstiter.cpp:2: /usr/local/include/odb/result.hxx:176:5: note: odb::result::iterator odb::result::end() [with T = FourPoint; odb::result::iterator = odb::result_iterator] /usr/local/include/odb/result.hxx:176:5: note: no known conversion for implicit ?this? parameter from ?const result* {aka const odb::result*}? to ?odb::result*? Removing all consts in this operator<< results in working code. Regards, Jeroen. From jnw at xs4all.nl Fri Feb 27 12:56:01 2015 From: jnw at xs4all.nl (Jeroen N. Witmond [Bahco]) Date: Fri Feb 27 12:56:08 2015 Subject: [odb-users] Compile error when combining query::[member].in_range and query::_ref([var]) In-Reply-To: References: <6a2068ce2e5530a25ca973e91cf14ba4.squirrel@webmail.xs4all.nl> Message-ID: <6a489f79f31cbe2a882bca0602cd30b4.squirrel@webmail.xs4all.nl> Hi Boris, Boris Kolpackov wrote: > Hi Jeroen, > > Jeroen N. Witmond [Bahco] writes: > >> result r (db->query >> (query::latitude.in_range(query::_ref(lat_min), >> query::_ref(lat_max)) && >> query::longitude.in_range(query::_ref(lon_min), >> query::_ref(lon_max)))); > > in_range() expects a pair of iterators. What you want is in(). My bad. I should have mentioned that latitude, longitude, and the corresponding _min and _max variables are of type double. The _min and _max variables define a range of values which, being of type double, cannot be enumerated. I think this means neither in_range() nor in() is suitable in this case. Regards, Jeroen.