From sean.clarke at sec-consulting.co.uk Sun Mar 3 04:52:53 2019 From: sean.clarke at sec-consulting.co.uk (Sean Clarke) Date: Sun Mar 3 05:09:28 2019 Subject: [odb-users] 2.5.0 release date? In-Reply-To: References: Message-ID: Hi Boris, I appreciate that is great for getting a build together for development, however the advantage of the official releases are you can then look towards getting the platform/distro specific packages (.deb, rpm etc) and use the upgrade/management hooks of the OS's. On Thu, 28 Feb 2019 at 13:41, Boris Kolpackov wrote: > Sean Clarke writes: > > > it seems like 2.5.0 has been an eternity in development, do we have > an > > approximate date for when it might be released? > > Yes, the release is overdue. The reason for the delay is that we > are moving to a uniform build/packaging toolchain as well as more > of "continuous delivery" model in the future. And we are almost but > not quite ready for the release. I would also recommend that you do > not wait for the "official & final" release and start using the new > setup as described here: > > https://codesynthesis.com/products/odb/doc/install-build2.xhtml > > At this stage in the development cycle, it is as stable as 2.4.0, > we are using it ourselves in multiple projects, we have migrated > a number of users with very good results, and it is fully supported > (i.e., we provide the same level of support as for 2.4.0). > From boris at codesynthesis.com Mon Mar 4 08:49:11 2019 From: boris at codesynthesis.com (Boris Kolpackov) Date: Mon Mar 4 09:05:32 2019 Subject: [odb-users] 2.5.0 release date? In-Reply-To: References: Message-ID: Sean Clarke writes: > I appreciate that is great for getting a build together for development, > however the advantage of the official releases are you can then look > towards getting the platform/distro specific packages (.deb, rpm etc) and > use the upgrade/management hooks of the OS's. Yes, I agree, there is that benefit. This is why we are still planning a release. One serious problem with platform distributions is that they can be quite slow to upgrade. In fact, we've had one pretty bad case: https://bugs.launchpad.net/ubuntu/+source/libodb/+bug/1588330 Notice how long it took (8 months) to fix this bug (in an LTS release, of all places) when all that required was a rebuild. This experience made it painfully clear that we need a distribution channel that is a lot more responsive. From javier.gutierrez at web.de Mon Mar 4 09:51:50 2019 From: javier.gutierrez at web.de (Javier Gutierrez) Date: Mon Mar 4 10:08:18 2019 Subject: [odb-users] Way to find out if a table was changed Message-ID: Hi Boris, is there any uniform way in ODB to know if a certain table was changed (i.e.: if a DELETE, UPDATE or INSERT was performed on it) ? Thanks in advance, Javier Gutierrez From boris at codesynthesis.com Tue Mar 5 09:17:28 2019 From: boris at codesynthesis.com (Boris Kolpackov) Date: Tue Mar 5 09:33:52 2019 Subject: [odb-users] Way to find out if a table was changed In-Reply-To: References: Message-ID: Javier Gutierrez writes: > is there any uniform way in ODB to know if a certain table was changed > (i.e.: if a DELETE, UPDATE or INSERT was performed on it) ? No, such a mechanism would have be database implementation-specific, if at all available. From lfiedler at informatik.uni-leipzig.de Sat Mar 9 04:13:42 2019 From: lfiedler at informatik.uni-leipzig.de (Lisa Fiedler) Date: Sat Mar 9 04:30:28 2019 Subject: [odb-users] Prepared query for native queries Message-ID: <210f9854-a2ec-de6e-bb16-10d834c85a0d@informatik.uni-leipzig.de> Hello, I was trying to use prepared native prepared query. For this purpose I created a native view: #pragma db view struct queryCount_view{ ??? #pragma db type("BIGINT") ??? u_int64_t count; }; and then tried the following: ??????????? odb::connection_ptr conn(db->connection()); ??????????? uint64_t weight; ??????????? odb::query q ("SELECT \"record\" FROM complete.\"edge_attributes\" WHERE \"weigth\" ='" + to_string(weight) + "' )"); ??????????? odb::prepared_query p (conn->prepare_query("test_query",q)); ??????????? weight = 8; ??????????? odb::transaction t (db->begin()); ??????????? odb::result r(p.execute()); ??????????? for(auto it = r.begin(); it != r.end(); it++){ ??????????????? cout << it->count << endl; ??????????? } ??????????? t.commit(); This did not work out however, with the error message: error: ?prepare_query? is not a member of ?odb::view_traits_impl? view_traits_impl::prepare_query (c, n, q)); Please note, that this was merely a simple test scenario and is not actually the query I want to pose. I was just trying to find out how to conduct prepared native queries. Is there some other way to realize this? Thank you! From haupt.wolfgang at gmail.com Sat Mar 9 04:54:18 2019 From: haupt.wolfgang at gmail.com (Wolfgang Haupt) Date: Sat Mar 9 05:11:04 2019 Subject: [odb-users] Prepared query for native queries In-Reply-To: <210f9854-a2ec-de6e-bb16-10d834c85a0d@informatik.uni-leipzig.de> References: <210f9854-a2ec-de6e-bb16-10d834c85a0d@informatik.uni-leipzig.de> Message-ID: <2a30a9de-592d-159e-0a5a-508f1aeeb34d@gmail.com> Hi, 2 things come into my mind: * Try again without prepare_query (if it's not essential to you) * Make sure you've compiled with "--generate-prepared" BR Wolfgang On 2019-03-09 10:13, Lisa Fiedler wrote: > Hello, > > I was trying to use prepared native prepared query. > > For this purpose I created a native view: > > #pragma db view struct queryCount_view{ ??? #pragma db type("BIGINT") > ??? u_int64_t count; }; > > and then tried the following: > > ??????????? odb::connection_ptr conn(db->connection()); ??????????? > uint64_t weight; odb::query q ("SELECT \"record\" > FROM complete.\"edge_attributes\" WHERE \"weigth\" ='" + > to_string(weight) + "' )"); odb::prepared_query p > (conn->prepare_query("test_query",q)); ??????????? > weight = 8; ??????????? odb::transaction t (db->begin()); ??????????? > odb::result r(p.execute()); ??????????? for(auto it = > r.begin(); it != r.end(); it++){ ??????????????? cout << it->count << > endl; ??????????? } ??????????? t.commit(); > > This did not work out however, with the error message: > > error: ?prepare_query? is not a member of > ?odb::view_traits_impl? > > view_traits_impl::prepare_query (c, n, q)); > > Please note, that this was merely a simple test scenario and is not > actually the query I want to pose. I was just trying to find out how > to conduct prepared native queries. > > Is there some other way to realize this? > > Thank you! > From lfiedler at informatik.uni-leipzig.de Sat Mar 9 05:05:01 2019 From: lfiedler at informatik.uni-leipzig.de (Lisa Fiedler) Date: Sat Mar 9 05:21:37 2019 Subject: [odb-users] Prepared query for native queries In-Reply-To: <210f9854-a2ec-de6e-bb16-10d834c85a0d@informatik.uni-leipzig.de> References: <210f9854-a2ec-de6e-bb16-10d834c85a0d@informatik.uni-leipzig.de> Message-ID: Hello, I am sorry, it compiles now. I did not properly save the updated makefile with the --generate-prepared option. Thanks all the same On 09.03.19 10:13, Lisa Fiedler wrote: > Hello, > > I was trying to use prepared native prepared query. > > For this purpose I created a native view: > > #pragma db view struct queryCount_view{ ??? #pragma db type("BIGINT") > ??? u_int64_t count; }; > > and then tried the following: > > ??????????? odb::connection_ptr conn(db->connection()); ??????????? > uint64_t weight; odb::query q ("SELECT \"record\" > FROM complete.\"edge_attributes\" WHERE \"weigth\" ='" + > to_string(weight) + "' )"); odb::prepared_query p > (conn->prepare_query("test_query",q)); ??????????? > weight = 8; ??????????? odb::transaction t (db->begin()); ??????????? > odb::result r(p.execute()); ??????????? for(auto it = > r.begin(); it != r.end(); it++){ ??????????????? cout << it->count << > endl; ??????????? } ??????????? t.commit(); > > This did not work out however, with the error message: > > error: ?prepare_query? is not a member of > ?odb::view_traits_impl? > > view_traits_impl::prepare_query (c, n, q)); > > Please note, that this was merely a simple test scenario and is not > actually the query I want to pose. I was just trying to find out how > to conduct prepared native queries. > > Is there some other way to realize this? > > Thank you! > From admin at replaytrader.com Mon Mar 11 18:37:11 2019 From: admin at replaytrader.com (Alexander Kuznetsov) Date: Tue Mar 12 08:38:13 2019 Subject: [odb-users] Building ODB 2.4.0 on OpenSuSE Leap 15.0 Message-ID: Hello. I'm using OpenSuSE Leap 15.0 and GCC 7.3.1 or 8.2.1. Both compilers have been built from sources to include plugin support. Tried to compile odb on that system. Need help or any insight how to compile ODB on systems with GCC > 5. As a note I have compiled everything on OpenSuSE 42.3 using GCC 5, however we're planning to phase out those systems. Here is what I have during compilation (handpicked errors, the entire list is very big) : ?/usr/lib64/gcc/x86_64-suse-linux/8/plugin/include/wide-int.h:933:23: error: 'gcc_checking_assert' was not declared in this scope ?? gcc_checking_assert (precision == x.get_precision ()); ?? ~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ /usr/lib64/gcc/x86_64-suse-linux/8/plugin/include/wide-int.h:2976:25: error: 'STATIC_CONSTANT_P' was not declared in this scope, and no declarations were found by argument-dependent lookup at the point of instantiation [-fpermissive] ??? ? (STATIC_CONSTANT_P (shift < HOST_BITS_PER_WIDE_INT - 1) ?????? ~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ /usr/lib64/gcc/x86_64-suse-linux/8/plugin/include/wide-int.h:1869:25: error: 'STATIC_CONSTANT_P' was not declared in this scope ?? if (STATIC_CONSTANT_P (xi.len == 1)) ?????? ~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~ /usr/lib64/gcc/x86_64-suse-linux/8/plugin/include/machmode.h:394:17: error: no matching function for call to 'scalar_int_mode::scalar_int_mode(mode_traits::from_int)' ?????? *result = T (typename mode_traits::from_int (m)); ???????????????? ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ /usr/lib64/gcc/x86_64-suse-linux/8/plugin/include/machmode.h:357:46: error: could not convert '(mode_traits::from_int)m' from 'mode_traits::from_int' to 'scalar_int_mode' ?? return typename mode_traits::from_int (m); ????????????????????????????????????????????? ^ cxx-lexer.cxx: In member function 'virtual cpp_ttype cxx_string_lexer::next(std::__cxx11::string&, tree_node**)': cxx-lexer.cxx:272:11: error: 'C_IS_RESERVED_WORD' was not declared in this scope ?????? if (C_IS_RESERVED_WORD (id)) ?????????? ^~~~~~~~~~~~~~~~~~ cxx-lexer.cxx:272:11: note: suggested alternative: 'LDPR_RESOLVED_IR' ?????? if (C_IS_RESERVED_WORD (id)) ?????????? ^~~~~~~~~~~~~~~~~~ ?????????? LDPR_RESOLVED_IR -------------- next part -------------- A non-text attachment was scrubbed... Name: pEpkey.asc Type: application/pgp-keys Size: 1778 bytes Desc: not available Url : https://codesynthesis.com/pipermail/odb-users/attachments/20190311/f997c36b/pEpkey.key From boris at codesynthesis.com Tue Mar 12 08:28:53 2019 From: boris at codesynthesis.com (Boris Kolpackov) Date: Tue Mar 12 08:45:40 2019 Subject: [odb-users] Building ODB 2.4.0 on OpenSuSE Leap 15.0 In-Reply-To: References: Message-ID: Alexander Kuznetsov writes: > I'm using OpenSuSE Leap 15.0 and GCC 7.3.1 or 8.2.1. Both compilers > have been built from sources to include plugin support. Tried to > compile odb on that system. > > Need help or any insight how to compile ODB on systems with GCC > 5. The easiest way would be switch to the 2.5.0 pre-release using the new setup as described here: https://codesynthesis.com/products/odb/doc/install-build2.xhtml This version is known to work with both GCC 7 and 8: https://cppget.org/?builds=odb&cf=*linux*-gcc* At this stage in the development cycle, it is as stable as 2.4.0, we are using it ourselves in multiple projects, we have migrated a number of users with very good results, and it is fully supported (i.e., we provide the same level of support as for 2.4.0). Let me know if there are any issues and thanks for re-posting this in English. From becoggins at hotmail.com Wed Mar 13 08:35:26 2019 From: becoggins at hotmail.com (Brian Coggins) Date: Wed Mar 13 08:52:22 2019 Subject: [odb-users] Concerns/Pitfalls Using ODB in a Library? Message-ID: Are there any potential pitfalls to be aware of using ODB in a library whose clients may also be using ODB? For example, imagine I have a component X which uses ODB to access a SQLite database. This is built as a static library, libx.a. This component libx.a would then be linked to several command line tools, one of which, Y, uses ODB to access a MySQL database. My intention is that the ODB schema for these components will be completely separate, with data passed across an interface that does not expose ODB features. That is, the ODB pragmas for X are not exposed to the client code at all and the client code will not know about any of X?s uses of ODB, and likewise ODB components from Y are not passed into X. Thus the ODB compiler invocation for building libx.a will only be aware of X?s schema, while the ODB compiler invocation for building Y will only be aware of Y?s schema. Of course, when all this is linked together, libodb will see both schema, and ODB instances for both may be active at the same time. That?s why I?m asking this question of whether there are any potential problems. One issue I thought of is odb::session, which is thread-specific. If X needs to use an odb::session, presumably it should do this on a separate thread so that there are no potential conflicts with odb::session instances in Y? Are there other concerns? Will odb::schema_catalog handle things correctly if X and Y both invoke it? Thanks, Brian From info at peredin.com Wed Mar 13 08:59:37 2019 From: info at peredin.com (Per Edin) Date: Wed Mar 13 09:16:08 2019 Subject: [odb-users] Concerns/Pitfalls Using ODB in a Library? In-Reply-To: References: Message-ID: Hi Brian! Regarding sessions I think custom sessions would solve the problem, see Section 11.2 in the manual. I.e. libx would implement its own session class and use that, instead of odb::session. It might even be possible to reuse parts of odb::session for this. The schema_catalog class supports schema names, which would "isolate" the schema in libX from libY. I haven't tried mixing ODB in libraries like this myself so maybe you'll run into problems with static initialization and what not. Kind regards, Per Edin Best regards, Per Edin info@peredin.com | https://linkedin.com/in/peredincom | http://peredin.com/ On Wed, Mar 13, 2019 at 1:35 PM Brian Coggins wrote: > > Are there any potential pitfalls to be aware of using ODB in a library whose clients may also be using ODB? > > For example, imagine I have a component X which uses ODB to access a SQLite database. This is built as a static library, libx.a. This component libx.a would then be linked to several command line tools, one of which, Y, uses ODB to access a MySQL database. > > My intention is that the ODB schema for these components will be completely separate, with data passed across an interface that does not expose ODB features. That is, the ODB pragmas for X are not exposed to the client code at all and the client code will not know about any of X?s uses of ODB, and likewise ODB components from Y are not passed into X. Thus the ODB compiler invocation for building libx.a will only be aware of X?s schema, while the ODB compiler invocation for building Y will only be aware of Y?s schema. > > Of course, when all this is linked together, libodb will see both schema, and ODB instances for both may be active at the same time. That?s why I?m asking this question of whether there are any potential problems. > > One issue I thought of is odb::session, which is thread-specific. If X needs to use an odb::session, presumably it should do this on a separate thread so that there are no potential conflicts with odb::session instances in Y? Are there other concerns? Will odb::schema_catalog handle things correctly if X and Y both invoke it? > > Thanks, > Brian > > > > > From lfiedler at informatik.uni-leipzig.de Wed Mar 13 10:38:49 2019 From: lfiedler at informatik.uni-leipzig.de (Lisa Fiedler) Date: Wed Mar 13 10:55:47 2019 Subject: [odb-users] native query with CTE Message-ID: <716386ca-3da0-a4e1-930e-be87130aad50@informatik.uni-leipzig.de> Hello, I was trying to pose the following native query db->query(" WITH nodeTable AS( " ????????????????? "SELECT nodes.node AS node , ROW_NUMBER() OVER (ORDER BY node) AS rowNumber " ????????????????? "FROM " ????????????????? "(SELECT left(\"edge\"," + to_string(k) + ") AS node " ????????????????? "FROM extracted.\"edge\" " ????????????????? "INTERSECT " ????????????????? "SELECT right(\"edge\"," + to_string(k) + ") " ????????????????? "FROM extracted.\"edge\") AS nodes) " ????????????????? "SELECT n1.rowNumber AS node1 , n2.rowNumber AS node2 " ????????????????? "FROM " ????????????????? "nodeTable n1 JOIN extracted.\"edge\" ON (n1.node = left(\"edge\"," + to_string(k) + ")) " ????????????????? "JOIN nodeTable n2 ON (n2.node = right(\"edge\"," + to_string(k) + "))"); where k is an unsigned integer and the view is defined as #pragma db view struct queryAbstractNodes_view{ ??? #pragma db type("bigint") ??? countType node1; ??? #pragma db type("bigint") ??? countType node2; }; However odb prepends my query string with "WHERE", such that an error is raised: 42601: ERROR: syntax error at or near "WHERE" LINE 1: WHERE WITH nodeTable AS( SELECT nodes.node AS node , ROW_NU... ^ How can I stop odb from doing this? The query works fine within psql. (I am using postgresql). Thanks a lot. From boris at codesynthesis.com Fri Mar 15 04:35:41 2019 From: boris at codesynthesis.com (Boris Kolpackov) Date: Fri Mar 15 04:52:35 2019 Subject: [odb-users] Concerns/Pitfalls Using ODB in a Library? In-Reply-To: References: Message-ID: Brian Coggins writes: > Of course, when all this is linked together, libodb will see both > schema, and ODB instances for both may be active at the same time. > That?s why I?m asking this question of whether there are any potential > problems. Provided both components use the same ODB libraries, I think everything should work fine. > One issue I thought of is odb::session, which is thread-specific. If > X needs to use an odb::session, presumably it should do this on a > separate thread so that there are no potential conflicts with > odb::session instances in Y? odb::session uses the database instance as its first-level key, so this will work fine even if you have two odb::database instances of the same type (say SQLite) let alone of different types. > Will odb::schema_catalog handle things correctly if X and Y > both invoke it? Yes, in case of different databases (SQLite and MySQL), they will again end up with different keys. For the same database, as Per suggests, you can use database schema names. So, to summarize, ODB was designed to work in this scenario and I don't expect there to be any issues. But if there is any, then it's most likely a bug and we will want to fix it. From boris at codesynthesis.com Fri Mar 15 04:44:16 2019 From: boris at codesynthesis.com (Boris Kolpackov) Date: Fri Mar 15 05:01:11 2019 Subject: [odb-users] native query with CTE In-Reply-To: <716386ca-3da0-a4e1-930e-be87130aad50@informatik.uni-leipzig.de> References: <716386ca-3da0-a4e1-930e-be87130aad50@informatik.uni-leipzig.de> Message-ID: Lisa Fiedler writes: > db->query(" WITH nodeTable AS( " Can you try removing the leading space in " WITH...", that is: db->query("WITH nodeTable AS( " From lfiedler at informatik.uni-leipzig.de Fri Mar 15 06:36:18 2019 From: lfiedler at informatik.uni-leipzig.de (Lisa Fiedler) Date: Fri Mar 15 06:53:23 2019 Subject: [odb-users] native query with CTE In-Reply-To: References: <716386ca-3da0-a4e1-930e-be87130aad50@informatik.uni-leipzig.de> Message-ID: <1e991083-867d-f391-2fb4-fae6d868b573@informatik.uni-leipzig.de> Yes I did this already. This does not seem to be the problem. Apperently a 'Where' is prepended, if the query does not start with 'SELECT...' On 15.03.19 09:44, Boris Kolpackov wrote: > Lisa Fiedler writes: > >> db->query(" WITH nodeTable AS( " > Can you try removing the leading space in " WITH...", that is: > > db->query("WITH nodeTable AS( " From becoggins at hotmail.com Fri Mar 15 08:33:50 2019 From: becoggins at hotmail.com (Brian Coggins) Date: Fri Mar 15 08:50:52 2019 Subject: [odb-users] Concerns/Pitfalls Using ODB in a Library? In-Reply-To: References: Message-ID: > So, to summarize, ODB was designed to work in this scenario > and I don't expect there to be any issues. But if there is > any, then it's most likely a bug and we will want to fix it. Excellent, that?s what I was hoping to hear! Thanks for clarifying. Brian On Mar 15, 2019, at 4:35 AM, Boris Kolpackov wrote: > Brian Coggins writes: > >> Of course, when all this is linked together, libodb will see both >> schema, and ODB instances for both may be active at the same time. >> That?s why I?m asking this question of whether there are any potential >> problems. > > Provided both components use the same ODB libraries, I think everything > should work fine. > > >> One issue I thought of is odb::session, which is thread-specific. If >> X needs to use an odb::session, presumably it should do this on a >> separate thread so that there are no potential conflicts with >> odb::session instances in Y? > > odb::session uses the database instance as its first-level key, so > this will work fine even if you have two odb::database instances > of the same type (say SQLite) let alone of different types. > > >> Will odb::schema_catalog handle things correctly if X and Y >> both invoke it? > > Yes, in case of different databases (SQLite and MySQL), they > will again end up with different keys. For the same database, > as Per suggests, you can use database schema names. > > So, to summarize, ODB was designed to work in this scenario > and I don't expect there to be any issues. But if there is > any, then it's most likely a bug and we will want to fix it. From boris at codesynthesis.com Fri Mar 15 10:25:13 2019 From: boris at codesynthesis.com (Boris Kolpackov) Date: Fri Mar 15 10:42:11 2019 Subject: [odb-users] native query with CTE In-Reply-To: <1e991083-867d-f391-2fb4-fae6d868b573@informatik.uni-leipzig.de> References: <716386ca-3da0-a4e1-930e-be87130aad50@informatik.uni-leipzig.de> <1e991083-867d-f391-2fb4-fae6d868b573@informatik.uni-leipzig.de> Message-ID: Lisa Fiedler writes: > Yes I did this already. This does not seem to be the problem. Which version of ODB are you using? In the 2.5.0 pre-release in odb/pgsql/query.cxx:275 I see: s.compare (0, (n = 4), "WITH") == 0 || s.compare (0, (n = 4), "with") == 0) Which I would expect to take care of this. From lfiedler at informatik.uni-leipzig.de Sat Mar 16 03:36:39 2019 From: lfiedler at informatik.uni-leipzig.de (Lisa Fiedler) Date: Sat Mar 16 03:53:42 2019 Subject: [odb-users] native query with CTE In-Reply-To: References: <716386ca-3da0-a4e1-930e-be87130aad50@informatik.uni-leipzig.de> <1e991083-867d-f391-2fb4-fae6d868b573@informatik.uni-leipzig.de> Message-ID: <0431322e-641d-7c6e-09c9-d964cd0a3351@informatik.uni-leipzig.de> I am still using version 2.4.0. I was waiting for 2.5.0 to become the official stable version before upgrading. There, (in version 2.4.0.) these lines are nowhere to be found in the odb/pgsql/query.cxx file. In fact I there discovered the lines: static bool ??? check_prefix (const string& s) ??? { ????? string::size_type n; ????? // It is easier to compare to upper and lower-case versions ????? // rather than getting involved with the portable case- ????? // insensitive string comparison mess. ????? // ????? if (s.compare (0, (n = 5), "WHERE") == 0 || ????????? s.compare (0, (n = 5), "where") == 0 || ????????? s.compare (0, (n = 6), "SELECT") == 0 || ????????? s.compare (0, (n = 6), "select") == 0 || ????????? s.compare (0, (n = 8), "ORDER BY") == 0 || ????????? s.compare (0, (n = 8), "order by") == 0 || ????????? s.compare (0, (n = 8), "GROUP BY") == 0 || ????????? s.compare (0, (n = 8), "group by") == 0 || ????????? s.compare (0, (n = 6), "HAVING") == 0 || ????????? s.compare (0, (n = 6), "having") == 0) ????? { ??????? // It either has to be an exact match, or there should be ??????? // a whitespace following the keyword. ??????? // ??????? if (s.size () == n || s[n] == ' ' || s[n] == '\n' || s[n] =='\t') ????????? return true; ????? } Can you tell me a rough estimate as to when version 2.5.0 will be offered as stable? Thanks! On 15.03.19 15:25, Boris Kolpackov wrote: > Lisa Fiedler writes: > >> Yes I did this already. This does not seem to be the problem. > Which version of ODB are you using? > > In the 2.5.0 pre-release in odb/pgsql/query.cxx:275 I see: > > s.compare (0, (n = 4), "WITH") == 0 || > s.compare (0, (n = 4), "with") == 0) > > Which I would expect to take care of this. From lfiedler at informatik.uni-leipzig.de Sun Mar 17 03:48:11 2019 From: lfiedler at informatik.uni-leipzig.de (Lisa Fiedler) Date: Sun Mar 17 04:05:24 2019 Subject: [odb-users] native query with CTE In-Reply-To: <0431322e-641d-7c6e-09c9-d964cd0a3351@informatik.uni-leipzig.de> References: <716386ca-3da0-a4e1-930e-be87130aad50@informatik.uni-leipzig.de> <1e991083-867d-f391-2fb4-fae6d868b573@informatik.uni-leipzig.de> <0431322e-641d-7c6e-09c9-d964cd0a3351@informatik.uni-leipzig.de> Message-ID: <8691309a-248b-6f78-03aa-cd2333abf6ef@informatik.uni-leipzig.de> On 16.03.19 08:36, Lisa Fiedler wrote: > I am still using version 2.4.0. I was waiting for 2.5.0 to become the > official stable version before upgrading. > > There, (in version 2.4.0.) these lines are nowhere to be found in the > odb/pgsql/query.cxx file. > > In fact I there discovered the lines: > > static bool > ??? check_prefix (const string& s) > ??? { > ????? string::size_type n; > > ????? // It is easier to compare to upper and lower-case versions > ????? // rather than getting involved with the portable case- > ????? // insensitive string comparison mess. > ????? // > ????? if (s.compare (0, (n = 5), "WHERE") == 0 || > ????????? s.compare (0, (n = 5), "where") == 0 || > ????????? s.compare (0, (n = 6), "SELECT") == 0 || > ????????? s.compare (0, (n = 6), "select") == 0 || > ????????? s.compare (0, (n = 8), "ORDER BY") == 0 || > ????????? s.compare (0, (n = 8), "order by") == 0 || > ????????? s.compare (0, (n = 8), "GROUP BY") == 0 || > ????????? s.compare (0, (n = 8), "group by") == 0 || > ????????? s.compare (0, (n = 6), "HAVING") == 0 || > ????????? s.compare (0, (n = 6), "having") == 0) > ????? { > ??????? // It either has to be an exact match, or there should be > ??????? // a whitespace following the keyword. > ??????? // > ??????? if (s.size () == n || s[n] == ' ' || s[n] == '\n' || s[n] =='\t') > ????????? return true; > ????? } > > Can you tell me a rough estimate as to when version 2.5.0 will be > offered as stable? > > Thanks! I just checked out the 2.5.0-b.11 release and built it. There, as you assumed correctly it works out perfectly find. So I am going to work with this for the time being. Thanks a lot for your help!! > > > On 15.03.19 15:25, Boris Kolpackov wrote: >> Lisa Fiedler writes: >> >>> Yes I did this already. This does not seem to be the problem. >> Which version of ODB are you using? >> >> In the 2.5.0 pre-release in odb/pgsql/query.cxx:275 I see: >> >> ?????????? s.compare (0, (n = 4), "WITH") == 0 || >> ?????????? s.compare (0, (n = 4), "with") == 0) >> >> Which I would expect to take care of this. > From boris at codesynthesis.com Mon Mar 18 08:46:39 2019 From: boris at codesynthesis.com (Boris Kolpackov) Date: Mon Mar 18 09:03:45 2019 Subject: [odb-users] native query with CTE In-Reply-To: <8691309a-248b-6f78-03aa-cd2333abf6ef@informatik.uni-leipzig.de> References: <716386ca-3da0-a4e1-930e-be87130aad50@informatik.uni-leipzig.de> <1e991083-867d-f391-2fb4-fae6d868b573@informatik.uni-leipzig.de> <0431322e-641d-7c6e-09c9-d964cd0a3351@informatik.uni-leipzig.de> <8691309a-248b-6f78-03aa-cd2333abf6ef@informatik.uni-leipzig.de> Message-ID: Lisa Fiedler writes: > I just checked out the 2.5.0-b.11 release and built it. There, as you > assumed correctly it works out perfectly find. > > So I am going to work with this for the time being. > > Thanks a lot for your help!! You are welcome. While the "official" 2.5.0 release is coming, at this stage in the development cycle the pre-release is as stable as 2.4.0, we are using it ourselves in multiple projects, we have migrated a number of users with very good results, and it is fully supported (i.e., we provide the same level of support as for 2.4.0). From devpro2k19 at gmail.com Tue Mar 19 08:33:05 2019 From: devpro2k19 at gmail.com (Dev Programmer) Date: Tue Mar 19 11:00:28 2019 Subject: [odb-users] Executable crash when I link libodb and libodb-mysql statically (VS2015) Message-ID: Hello I played with my test project that I copied from "hello" example in my Visual Studio 2015. I built it, and executed. With DLLs It worked! After I tried to build odb and odm-mysql statically with my test project. In project libodb I changed target to static library and add preprocessor definition LIBODB_STATIC_LIB In project libodb-mysql I changed target to static library as well and add preprocessor definition LIBODB_STATIC_LIB LIBODB_MYSQL_STATIC_LIB In my test project I added directives LIBODB_STATIC_LIB LIBODB_MYSQL_STATIC_LIB as well. Project was build, but when I try to execute program It was crashed. int main(int argc, char* argv[]) { try { // IT CRASHED HERE auto_ptr db(new odb::mysql::database(argc, argv)); unsigned long john_id, jane_id, joe_id; // Create a few persistent person objects. // { person john("John", "Doe", 33); person jane("Jane", "Doe", 32); person joe("Joe", "Dirt", 30); transaction t(db->begin()); // Make objects persistent and save their ids for later use. // john_id = db->persist(john); jane_id = db->persist(jane); joe_id = db->persist(joe); t.commit(); } } catch (const odb::exception& e) { cerr << e.what() << endl; return 1; } return 0; } I have no idea why it happen. If anybody know where I made a misstake, please, let me know. Thank you. From devpro2k19 at gmail.com Tue Mar 19 08:52:50 2019 From: devpro2k19 at gmail.com (Dev Programmer) Date: Tue Mar 19 11:00:28 2019 Subject: [odb-users] Compiler Warning (level 2) C4275 Message-ID: Hello When I try to build libodb in my Visual Studio 2015 I get compiler warning (level 2) C4275 for class "odb::exception". See https://docs.microsoft.com/ru-ru/cpp/error-messages/compiler-warnings/compiler-warning-level-2-c4275?view=vs-2017 // -- CODE -- namespace odb { struct LIBODB_EXPORT exception: std::exception, details::shared_base { virtual const char* what () const throw () = 0; virtual exception* clone () const = 0; }; namespace common { using odb::exception; } } // -- END CODE -- Parent class std::exception was not exported. From becoggins at hotmail.com Tue Mar 19 17:23:37 2019 From: becoggins at hotmail.com (Brian Coggins) Date: Tue Mar 19 17:40:56 2019 Subject: [odb-users] Strange Problems Building ODB Compiler From Source Message-ID: Hi Boris, I'm back again, this time with a strange ODB compilation problem on one of my development machines. I am building the beta ODB from cppget.org using the homebrew g++-8, but somehow the resulting odb executable is tangled up in clang. Strangely, I have not had this problem on two nearly identical systems where I have built ODB in the last few weeks, all of them Macs running High Sierra. Here's how I build it: $ g++-8 --version g++-8 (Homebrew GCC 8.2.0) 8.2.0 Copyright (C) 2018 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. $ bpkg create -d odb-gcc-8 cc config.cxx=g++-8 config.cc.coptions=-O3 config.bin.rpath=/usr/local/lib config.install.root=/usr/local config.install.sudo=sudo created new configuration in /Users/brian/Software/odb/odb-build/odb-gcc-8/ $ cd odb-gcc-8 $ bpkg build odb@https://pkg.cppget.org/1/beta added pkg:cppget.org/beta fetching pkg:cppget.org/beta warning: authenticity of the certificate for repository pkg:cppget.org/beta cannot be established certificate is for cppget.org, "Code Synthesis" certificate SHA256 fingerprint: 86:BA:D4:DE:2C:87:1A:EE:38:C7:F1:64:7F:65:77:02:15:79:F3:C4:83:C0:AB:5A:EA:F4:F7:8C:1D:63:30:C6 [...cut many lines...] updated odb/2.5.0-b.13 Now if I install this, here's what I get: $ odb --version ODB object-relational mapping (ORM) compiler for C++ 2.5.0-b.13 Copyright (c) 2009-2019 Code Synthesis Tools CC This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. $ odb --database sqlite test.h clang: error: unknown argument: '-fplugin-arg-odb-svc-path=/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include/c++/v1' clang: error: unknown argument: '-fplugin-arg-odb-svc-path=/usr/local/include' clang: error: unknown argument: '-fplugin-arg-odb-svc-path=/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/clang/10.0.0/include' clang: error: unknown argument: '-fplugin-arg-odb-svc-path=/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include' clang: error: unknown argument: '-fplugin-arg-odb-svc-path=/usr/include' clang: error: unknown argument: '-fplugin-arg-odb-svc-path=/System/Library/Frameworks (framework directory)' clang: error: unknown argument: '-fplugin-arg-odb-svc-path=/Library/Frameworks (framework directory)' clang: error: unknown argument: '-fplugin-arg-odb-database=sqlite' clang: error: unknown argument: '-fplugin-arg-odb-svc-file=test.h' Any ideas what is going wrong here? Thanks, Brian From boris at codesynthesis.com Wed Mar 20 09:27:00 2019 From: boris at codesynthesis.com (Boris Kolpackov) Date: Wed Mar 20 09:44:13 2019 Subject: [odb-users] Strange Problems Building ODB Compiler From Source In-Reply-To: References: Message-ID: Brian Coggins writes: > $ odb --database sqlite test.h > > clang: error: unknown argument: '-fplugin-arg-odb-svc-path=/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include/c++/v1' Ok, this suggests that for some reason ODB is using g++ instead of g++-8. On Mac OS g++ is an alias for clang++. Now we need to understand why. Could you run the following for me and send the beginning of the output (or upload the whole log somewhere): $ cd odb-gcc-8/odb-2.5.0-b.13 $ b clean $ b --verbose=5 I am particularly interested in these lines (shown with values from my Linux box): trace: reset: original host: 'x86_64-linux-gnu' trace: reset: canonical host: 'x86_64-linux-gnu'; class: linux cxx ... cxx g++-7@/usr/bin/g++-7 id gcc version 7.2.0 (Ubuntu 7.2.0-1ubuntu1~16.04) ... target x86_64-linux-gnu As well as the g++ compilation command line that shows the -DODB_GXX_NAME option. Also, if you want to try and debug this, the relevant place to look is odb-gcc-8/odb-2.5.0-b.13/buildfile, lines that reference gxx_name. You could, for example, try to print the host/target triplets by adding the following lines: info $cxx.target info $build.host From boris at codesynthesis.com Wed Mar 20 09:32:11 2019 From: boris at codesynthesis.com (Boris Kolpackov) Date: Wed Mar 20 09:49:22 2019 Subject: [odb-users] Executable crash when I link libodb and libodb-mysql statically (VS2015) In-Reply-To: References: Message-ID: Dev Programmer writes: > I played with my test project that I copied from "hello" example in my > Visual Studio 2015. I built it, and executed. With DLLs It worked! > > After I tried to build odb and odb-mysql statically with my test project. > [...] Project was build, but when I try to execute program It was crashed. See this earlier discussion for an answer: https://www.codesynthesis.com/pipermail/odb-users/2018-June/004019.html From boris at codesynthesis.com Wed Mar 20 09:38:12 2019 From: boris at codesynthesis.com (Boris Kolpackov) Date: Wed Mar 20 09:55:23 2019 Subject: [odb-users] Compiler Warning (level 2) C4275 In-Reply-To: References: Message-ID: Dev Programmer writes: > When I try to build libodb in my Visual Studio 2015 I get > compiler warning (level 2) C4275 for class "odb::exception". > > [...] > > namespace odb > { > struct LIBODB_EXPORT exception: std::exception, details::shared_base > [...] > > Parent class std::exception was not exported. These should be silenced by the References: , Message-ID: Also, if you want to try and debug this, the relevant place to look is odb-gcc-8/odb-2.5.0-b.13/buildfile, lines that reference gxx_name. You could, for example, try to print the host/target triplets by adding the following lines: info $cxx.target info $build.host This gets us partway. Here's the code from the buildfile as modified (actually odb-gcc-8/odb-2.5.0-b.13/odb/buildfile): # Unless cross-compiling, pass the C++ compiler's recall path as g++ name. At # some point we should also make it configurable. # gxx_name = ($cxx.target != $build.host ? g++ : $recall($cxx.path)) gxx_name = $regex.replace($gxx_name, '\\', '\\\\') # Escape back slashes. # ADDED FOR DEBUG info $cxx.target info $build.host And here's the output: odb/buildfile:43:1: info: x86_64-apple-darwin17.3.0 info: while applying rule alias to update dir{./} odb/buildfile:44:1: info: x86_64-apple-darwin17.7.0 info: while applying rule alias to update dir{./} That ought to be enough to throw it over to g++ rather than g++-8. Not sure why it is reading different platform versions in those two variables. In case it helps, I ran b --verbose=5 and saved the output to a text file on Dropbox at the following link. That was from before I made the change to the buildfile. https://www.dropbox.com/s/mjus5uu9iwntjnn/odb_build_log.txt?raw=1 Thanks, Brian ________________________________ From: Boris Kolpackov Sent: Wednesday, March 20, 2019 9:27 AM To: Brian Coggins Cc: odb-users@codesynthesis.com Subject: Re: [odb-users] Strange Problems Building ODB Compiler From Source Brian Coggins writes: > $ odb --database sqlite test.h > > clang: error: unknown argument: '-fplugin-arg-odb-svc-path=/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include/c++/v1' Ok, this suggests that for some reason ODB is using g++ instead of g++-8. On Mac OS g++ is an alias for clang++. Now we need to understand why. Could you run the following for me and send the beginning of the output (or upload the whole log somewhere): $ cd odb-gcc-8/odb-2.5.0-b.13 $ b clean $ b --verbose=5 I am particularly interested in these lines (shown with values from my Linux box): trace: reset: original host: 'x86_64-linux-gnu' trace: reset: canonical host: 'x86_64-linux-gnu'; class: linux cxx ... cxx g++-7@/usr/bin/g++-7 id gcc version 7.2.0 (Ubuntu 7.2.0-1ubuntu1~16.04) ... target x86_64-linux-gnu As well as the g++ compilation command line that shows the -DODB_GXX_NAME option. Also, if you want to try and debug this, the relevant place to look is odb-gcc-8/odb-2.5.0-b.13/buildfile, lines that reference gxx_name. You could, for example, try to print the host/target triplets by adding the following lines: info $cxx.target info $build.host From boris at codesynthesis.com Wed Mar 20 11:54:20 2019 From: boris at codesynthesis.com (Boris Kolpackov) Date: Wed Mar 20 12:35:45 2019 Subject: [odb-users] Strange Problems Building ODB Compiler From Source In-Reply-To: References: Message-ID: Brian Coggins writes: > # Unless cross-compiling, pass the C++ compiler's recall path as g++ name. At > # some point we should also make it configurable. > # > gxx_name = ($cxx.target != $build.host ? g++ : $recall($cxx.path)) > gxx_name = $regex.replace($gxx_name, '\\', '\\\\') # Escape back slashes. > > # ADDED FOR DEBUG > info $cxx.target > info $build.host > > And here's the output: > > odb/buildfile:43:1: info: x86_64-apple-darwin17.3.0 > odb/buildfile:44:1: info: x86_64-apple-darwin17.7.0 Ok, looks like the compiler is targeting an older version of the runtime than what you are running. I guess we need to relax the comparison a bit. Could you try replacing the above two gxx_name assignments with the following and see if that helps: if ($cxx.target.cpu == $build.host.cpu && \ $cxx.target.system == $build.host.system) { gxx_name = $recall($cxx.path) gxx_name = $regex.replace($gxx_name, '\\', '\\\\') # Escape back slashes. } else gxx_name = g++ From becoggins at hotmail.com Wed Mar 20 12:53:40 2019 From: becoggins at hotmail.com (Brian Coggins) Date: Wed Mar 20 13:11:01 2019 Subject: [odb-users] Strange Problems Building ODB Compiler From Source In-Reply-To: References: , Message-ID: Could you try replacing the above two gxx_name assignments with the following and see if that helps: if ($cxx.target.cpu == $build.host.cpu && \ $cxx.target.system == $build.host.system) { gxx_name = $recall($cxx.path) gxx_name = $regex.replace($gxx_name, '\\', '\\\\') # Escape back slashes. } else gxx_name = g++ That fixed it! It builds fine, and the resulting odb executable works correctly. Many thanks! Brian ________________________________ From: Boris Kolpackov Sent: Wednesday, March 20, 2019 11:54 AM To: Brian Coggins Cc: odb-users@codesynthesis.com Subject: Re: [odb-users] Strange Problems Building ODB Compiler From Source Brian Coggins writes: > # Unless cross-compiling, pass the C++ compiler's recall path as g++ name. At > # some point we should also make it configurable. > # > gxx_name = ($cxx.target != $build.host ? g++ : $recall($cxx.path)) > gxx_name = $regex.replace($gxx_name, '\\', '\\\\') # Escape back slashes. > > # ADDED FOR DEBUG > info $cxx.target > info $build.host > > And here's the output: > > odb/buildfile:43:1: info: x86_64-apple-darwin17.3.0 > odb/buildfile:44:1: info: x86_64-apple-darwin17.7.0 Ok, looks like the compiler is targeting an older version of the runtime than what you are running. I guess we need to relax the comparison a bit. Could you try replacing the above two gxx_name assignments with the following and see if that helps: if ($cxx.target.cpu == $build.host.cpu && \ $cxx.target.system == $build.host.system) { gxx_name = $recall($cxx.path) gxx_name = $regex.replace($gxx_name, '\\', '\\\\') # Escape back slashes. } else gxx_name = g++ From boris at codesynthesis.com Sat Mar 23 05:04:53 2019 From: boris at codesynthesis.com (Boris Kolpackov) Date: Sat Mar 23 05:22:17 2019 Subject: [odb-users] Strange Problems Building ODB Compiler From Source In-Reply-To: References: Message-ID: Brian Coggins writes: > That fixed it! It builds fine, and the resulting odb executable works > correctly. Thanks for testing. I've applied the fix and uploaded a new revision of the ODB compiler package to cppget.org. From lists1 at afach.de Sat Mar 23 15:28:24 2019 From: lists1 at afach.de (Sam) Date: Sat Mar 23 15:45:55 2019 Subject: [odb-users] Compilation error when using decimal(p, s) or bytea types Message-ID: <1bbb2961-f766-732b-ca72-3b8f4fe9229e@afach.de> Hello there: There seems to be a bug in odb (Ubuntu 18.04 (bionic), the version that comes with the OS) that when I use the types decimal(p,s) or bytea, I get compilation errors in set_image in the file generated. The following is a minimal example. The ORM definition file is the following: ////////////////////////////////////////////////////////////////// #ifndef ORMBALANCES_H #define ORMBALANCES_H #include #include #include // these ODB_COMPILER defs help in preventing g++ from compiling these // statements and produce warnings #ifdef ODB_COMPILER #pragma db model version(1, 1) #pragma db object table("Balances") #endif #ifdef ODB_COMPILER #pragma db object #endif class OrmBalances { #ifdef ODB_COMPILER #pragma db id auto unique column("BalanceID") #endif uint64_t id; #ifdef ODB_COMPILER #pragma db default("0") column("Balance") type("decimal(8,8)") #endif std::string balance; public: friend class odb::access; }; #endif // ORMBALANCES_H ////////////////////////////////////////////////////////////////// The command I use to generate is this: /usr/bin/odb --stdc++14 --schema-version-tableOrmBalances_schema_version-dpgsql /home/user/temp/odb_test/OrmBalances.h More information: $ odb --version ODB object-relational mapping (ORM) compiler for C++ 2.4.0 Copyright (c) 2009-2015 Code Synthesis Tools CC This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. The error is the following: /home/user/temp/build-odb_test-Default_cmake-Default/OrmBalancesClass_ ODB_generated/OrmBalances-odb.cxx:206: error: too many arguments to function call, expected 3, have 4; did you mean 'pgsql::c_string_value_traits::set_image'? pgsql::value_traits< ^~~~~ pgsql::c_string_value_traits::set_image And this how the generated code looks like at set_image(): pgsql::value_traits< ::std::string, pgsql::id_numeric >::set_image ( i.balance_value, size, is_null, v); Is this a bug or am I doing something wrong? If it's a bug, is there a new version with this issue fixed? Thanks. Best, Sam From boris at codesynthesis.com Sun Mar 24 09:03:04 2019 From: boris at codesynthesis.com (Boris Kolpackov) Date: Sun Mar 24 09:20:32 2019 Subject: [odb-users] Compilation error when using decimal(p, s) or bytea types In-Reply-To: <1bbb2961-f766-732b-ca72-3b8f4fe9229e@afach.de> References: <1bbb2961-f766-732b-ca72-3b8f4fe9229e@afach.de> Message-ID: Sam writes: > #ifdef ODB_COMPILER > #pragma db default("0") column("Balance") type("decimal(8,8)") > #endif > std::string balance; > > The error is the following: > > /home/user/temp/build-odb_test-Default_cmake-Default/OrmBalancesClass_ > ODB_generated/OrmBalances-odb.cxx:206: error: too many arguments to > function call, expected 3, have 4; did you mean > 'pgsql::c_string_value_traits::set_image'? > pgsql::value_traits< > ^~~~~ > pgsql::c_string_value_traits::set_image > > Is this a bug or am I doing something wrong? There is no built-in mapping for Postgres decimal type to std::string. All the available built-in mappings are described in the manual, specifically, Section 19.1, "PostgreSQL Type Mapping". You can also add support for a custom mapping as described in this blog post: https://www.codesynthesis.com/~boris/blog/2012/10/16/custom-cxx-to-database-type-mapping-in-odb/ From lists1 at afach.de Sun Mar 24 12:12:51 2019 From: lists1 at afach.de (Sam) Date: Sun Mar 24 12:30:14 2019 Subject: [odb-users] Compilation error when using decimal(p, s) or bytea types In-Reply-To: References: <1bbb2961-f766-732b-ca72-3b8f4fe9229e@afach.de> Message-ID: <68268f18-19bf-34a6-f307-2bb910d81c50@afach.de> Thank you for the response, Boris. There's an issue that's I still don't understand. From reading that blog post, I understand how conversions are done on a low level by implementing value_traits template. So I can convert directly from my type to details::buffer back and forth, which will be stored directly in my database as is. This seems perfect for blobs and byte-arrays and other non-numeric types. But for decimal, I don't understand how this works. I don't know how PostgreSQL stores decimal/numeric internally (and for cross-platform compatibility I'm avoiding guessing). When using SQL queries to store decimal, the decimal value is provided as normal numbers, e.g., "1.2345". How can I do the same with ODB? In other words: If my decimal number is in an std::string in ASCII form, how will the function set_image() look like? I don't imagine I can just use memcpy there because that won't do any binary encoding. Can you please provide an example on how to write set_image correctly for decimal/numeric type from std::string in ASCII format, so that database table-viewers can interpret them correctly? Best, Sam On 2019-03-24 2:03 PM, Boris Kolpackov wrote: Sam [1] writes: #ifdef ODB_COMPILER #pragma db default("0") column("Balance") type("decimal(8,8)") #endif std::string balance; The error is the following: /home/user/temp/build-odb_test-Default_cmake-Default/OrmBalancesClass_ ODB_generated/OrmBalances-odb.cxx:206: error: too many arguments to function call, expected 3, have 4; did you mean 'pgsql::c_string_value_traits::set_image'? pgsql::value_traits< ^~~~~ pgsql::c_string_value_traits::set_image Is this a bug or am I doing something wrong? There is no built-in mapping for Postgres decimal type to std::string. All the available built-in mappings are described in the manual, specifically, Section 19.1, "PostgreSQL Type Mapping". You can also add support for a custom mapping as described in this blog post: [2]https://www.codesynthesis.com/~boris/blog/2012/10/16/custom-cxx-to-database- type-mapping-in-odb/ References 1. mailto:lists1@afach.de 2. https://www.codesynthesis.com/~boris/blog/2012/10/16/custom-cxx-to-database-type-mapping-in-odb/ From boris at codesynthesis.com Mon Mar 25 10:09:46 2019 From: boris at codesynthesis.com (Boris Kolpackov) Date: Mon Mar 25 10:27:14 2019 Subject: [odb-users] Compilation error when using decimal(p, s) or bytea types In-Reply-To: <68268f18-19bf-34a6-f307-2bb910d81c50@afach.de> References: <1bbb2961-f766-732b-ca72-3b8f4fe9229e@afach.de> <68268f18-19bf-34a6-f307-2bb910d81c50@afach.de> Message-ID: Sam writes: > Can you please provide an example on how to write set_image correctly > for decimal/numeric type from std::string in ASCII format, so that > database table-viewers can interpret them correctly? Take a look at some of the traits implementations in . The underlying buffers are described in . From PStath at jmawireless.com Mon Mar 25 14:56:02 2019 From: PStath at jmawireless.com (Paul Stath) Date: Mon Mar 25 15:13:41 2019 Subject: [odb-users] ODB version as timestamp Message-ID: Is it possible in ODB to define the version attribute as a date-time stamp? I seem to recall in a past project having the version column be a boost::posix_time::ptime value. However, this was quite a while back, and I may be confusing it with a Java Persistence API project. When I try to change the data type of the member variable from 'unsigned long' to 'boost::posix_time::ptime', the SQL looks fine, but I get a compilation error in the generated code. In the ::persist() method, the version value is being initialized to an integer 1. obj.version = 1; I would expect it to set obj.version to the current date/time when the record is persisted. I have other columns in the same class that are 'boost_posix_ptime' which work correctly, so I already have the '--profile boost/date-time/posix-time' flag set. Am I trying to do something that is unsupported? --- Paul Stath Senior Software Engineer JMA Wireless pstath@jmawirelesss -----Original Message----- From: odb-users-bounces@codesynthesis.com On Behalf Of odb-users-request@codesynthesis.com Sent: Sunday, March 24, 2019 12:00 PM To: odb-users@codesynthesis.com Subject: odb-users Digest, Vol 103, Issue 15 Send odb-users mailing list submissions to odb-users@codesynthesis.com To subscribe or unsubscribe via the World Wide Web, visit https://linkprotect.cudasvc.com/url?a=https%3a%2f%2fcodesynthesis.com%2fmailman%2flistinfo%2fodb-users&c=E,1,Bj1EJ9pE5muq9GMPD15DPsC45zbEVVJ9_PxneR2GHxJ_j5lIu8sYSt1FABsuWzOFqUc0ZUnO1rJantoN2fLuNUG71jueflEDoQOrIGlhXGnhJsk,&typo=1 or, via email, send a message with subject or body 'help' to odb-users-request@codesynthesis.com You can reach the person managing the list at odb-users-owner@codesynthesis.com When replying, please edit your Subject line so it is more specific than "Re: Contents of odb-users digest..." From boris at codesynthesis.com Wed Mar 27 09:29:06 2019 From: boris at codesynthesis.com (Boris Kolpackov) Date: Wed Mar 27 09:46:41 2019 Subject: [odb-users] ODB version as timestamp In-Reply-To: References: Message-ID: Paul Stath writes: > Is it possible in ODB to define the version attribute as a date-time stamp? > > [...] > > I would expect it to set obj.version to the current date/time when the > record is persisted. No, this is not supported. Quoting from Chapter 12, "Optimistic Concurrency": "Currently, ODB uses object versioning while other methods, such as timestamps, may be supported in the future. [...] The version data member is managed by ODB. It is initialized to 1 when the object is made persistent and incremented by 1 with each update. The 0 version value is not used by ODB and the application can use it as a special value, for example, to indicate that the object is transient. [...]"