From michael.dembroge at leica-geosystems.com Tue Jan 9 15:09:57 2024 From: michael.dembroge at leica-geosystems.com (DEMBROGE Michael) Date: Wed Jan 10 08:44:14 2024 Subject: [odb-users] Error when compiling ODB compiler in 2.5.0-b25 on Windows Message-ID: Hello, I'm getting the following error when I try to build the ODB compiler for ODB 2.5.0-b25: odb-2.5.0-b.25\build\root.build:37:5: error: ODB compiler can only be built with GCC. The issue is that I'm configuring it to use gcc, but for some reason, in Windows, it's setting the compiler to 'msvc' (see below). Here is a summary of my procedure (from https://codesynthesis.com/products/odb/doc/install-build2.xhtml): Step 1: create folder - c:\odb-build>bpkg create -d odb-mingw cxx^ More? Config.cxx=gcc^ More? Config.cc.coptions=-O2^ More? Config.install.root=c:\build2 created new configuration in C:\odb-build\odb-mingw\ uuid: e7166948-dcad-4427-a7b4-9301b12691b0 type: target Step 2: download source C:\odb-build>cd odb-mingw C:\odb-build\odb-mingw>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" admin@cppget.org certificate SHA256 fingerprint: 70:64:FE:E4:E0:F3:60:F1:B4:51:E1:FA:12:5C:E0:B3:DB:DF:96:33:39:B9:2E:E5:C2:68:63:4C:A6:47:39:43 trust this certificate? [y/n] y fetching pkg:cppget.org/testing (complements pkg:cppget.org/beta) fetching pkg:cppget.org/stable (complements pkg:cppget.org/testing) new libstudxml/1.1.0-b.10+2 (required by odb) new libcutl/1.11.0-b.9+1 (required by odb) new odb/2.5.0-b.25 continue? [Y/n] Y libstudxml-1.1.0-b.10+2.tar.gz: ###### ... ###### 100.0% fetched libstudxml/1.1.0-b.10+2 unpacked libstudxml/1.1.0-b.10+2 libcutl-1.11.0-b.9+1.tar.gz: ###### ... ###### 100.0% fetched libcutl/1.11.0-b.9+1 unpacked libcutl/1.11.0-b.9+1 odb-2.5.0-b.25.tar.gz: ###### ... ###### 100.0% fetched odb/2.5.0-b.25 unpacked odb/2.5.0-b.25 configured libstudxml/1.1.0-b.10+2 configured libcutl/1.11.0-b.9+1 odb-2.5.0-b.25\build\root.build:37:5: error: ODB compiler can only be built with GCC info: while configuring odb I then found the line in root.build where this test was failing: if ($cxx.id != 'gcc') fail 'ODB compiler can only be built with GCC' My next step was to make a slight modification to root.build to output $cxx.id: if ($cxx.id != 'gcc') fail 'ODB compiler can only be built with GCC. cxx.id = ' $cxx.id I then re-ran the 'build' command: C:\odb-build\odb-mingw>bpkg build odb@https://pkg.cppget.org/1/beta fetching pkg:cppget.org/beta fetching pkg:cppget.org/testing (complements pkg:cppget.org/beta) fetching pkg:cppget.org/stable (complements pkg:cppget.org/testing) odb-2.5.0-b.25\build\root.build:37:5: error: ODB compiler can only be built with GCC. cxx.id = msvc info: while configuring odb Does anyone have any ideas as to what is going wrong? I have installed gcc, but maybe it's missing something else? TIA, Mike Dembroge From boris at codesynthesis.com Wed Jan 10 08:58:58 2024 From: boris at codesynthesis.com (Boris Kolpackov) Date: Wed Jan 10 08:49:35 2024 Subject: [odb-users] Error when compiling ODB compiler in 2.5.0-b25 on Windows In-Reply-To: References: Message-ID: DEMBROGE Michael writes: > c:\odb-build>bpkg create -d odb-mingw cxx^ > More? Config.cxx=gcc^ > More? Config.cc.coptions=-O2^ > More? Config.install.root=c:\build2 There are two issues with this command line: 1. All then config.* variables should start with the lower-case letter. So config.cxx instead of Config.cxx, etc. 2. The compiler name specified with config.cxx should be g++, not gcc. For details, see: https://codesynthesis.com/products/odb/doc/install-build2.xhtml#windows-odb From michael.dembroge at leica-geosystems.com Wed Jan 10 13:21:14 2024 From: michael.dembroge at leica-geosystems.com (DEMBROGE Michael) Date: Wed Jan 10 13:12:00 2024 Subject: [odb-users] Error when compiling ODB compiler in 2.5.0-b25 on Windows In-Reply-To: References: Message-ID: Thank you Boris for the info. Regarding the capitalization, that was a Microsoft auto-format in the email that I did not notice. The original commands used lower-case 'c'. Regarding the compiler version, I tried both, gcc & g++ and had no luck either way. That said, I was able to get it to compile on another computer. I had previously built the ODB libraries for Linux on my machine using WSL, so I think there is some remnant or something that is causing it to fail. When I built on a clean machine, it worked okay. Thanks again, Mike -----Original Message----- From: Boris Kolpackov Sent: Wednesday, January 10, 2024 5:59 AM To: DEMBROGE Michael Cc: odb-users@codesynthesis.com; EDDOWES Scott Subject: Re: [odb-users] Error when compiling ODB compiler in 2.5.0-b25 on Windows [You don't often get email from boris@codesynthesis.com. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ] This email is not from Hexagon's Office 365 instance. Please be careful while clicking links, opening attachments, or replying to this email. DEMBROGE Michael writes: > c:\odb-build>bpkg create -d odb-mingw cxx^ More? Config.cxx=gcc^ More? > Config.cc.coptions=-O2^ More? Config.install.root=c:\build2 There are two issues with this command line: 1. All then config.* variables should start with the lower-case letter. So config.cxx instead of Config.cxx, etc. 2. The compiler name specified with config.cxx should be g++, not gcc. For details, see: https://codesynthesis.com/products/odb/doc/install-build2.xhtml#windows-odb From roberto.minarelli.de at gmail.com Wed Jan 10 10:24:19 2024 From: roberto.minarelli.de at gmail.com (roberto minarelli) Date: Thu Jan 11 04:16:48 2024 Subject: [odb-users] Inserting CLOB greater having size greater then 12288 In-Reply-To: References: Message-ID: Hi Boris, as you suggested I created a simple table with only two fields as follows create table TEST_LOB_TABLE ( id NUMBER not null, request CLOB ) then I mapped the preceding table on the following class #pragma db object table("MPVR_DBA.TEST_LOB_TABLE") class TestLobTable { #pragma db id column("ID") unsigned long Id; #pragma db column("REQUEST") type("CLOB") string strRequest; friend class odb::access; public: TestLobTable(){} virtual ~TestLobTable(){} const unsigned long getId() const { return Id; } void setId(const unsigned long value) { Id = value; } const string &getRequest() const { return strRequest; } void setRequest(const string &value) { strRequest = value; } }; and following there is a simple code I wrote to test the insertion of the CLOB int main(int argc, char* argv[]) { // some initialization string strLob string strLob(20000, 'A'); try { unique_ptr f (new oracle::connection_pool_factory (20, 1)); dbPtr db (new oracle::database (strUser, strPwd, strDBname,0, 0, nullptr, getConnection(f) )); unsigned long uId(2); spdlog::info("trying with TestLobTable"); oracle::transaction t1(db->begin()); TestLobTable obj; obj.setId(uId); bool bRes(false); size_t len(strLob.length()); while(!bRes) { try { spdlog::info("len is {}", len); obj.setRequest(strLob.substr(0,len)); db->persist(obj); spdlog::info("ok strLob len is {0}, strLob is {1}", len, strLob.substr(0,len)); t1.commit(); bRes=true; } catch(odb::object_already_persistent& e) { t1.rollback(); spdlog::error("error is {}", e.what()); break; } catch (std::exception &e) { len--; spdlog::error("error is {}", e.what()); } } } } catch(std::exception& e) { spdlog::error("error is {}", e.what()); return EXIT_FAILURE; } return EXIT_SUCCESS; } this result in the following situation [2024-01-09 19:36:15.409] [info] trying with TestLobTable [2024-01-09 19:48:17.324] [info] len is 20000 [2024-01-09 19:48:17.347] [error] error is 1461: ORA-01461: can bind a LONG value only for insert into a LONG column [2024-01-09 19:48:17.347] [info] len is 19999 [2024-01-09 19:48:17.348] [error] error is 1461: ORA-01461: can bind a LONG value only for insert into a LONG column ..... [2024-01-09 19:36:15.740] [info] len is 12288 [2024-01-09 19:36:15.756] [info] ok strLob len is 12288, strLob is "AAA....." the datatype are correct and there is no possible ambiguity So the question rises again: How can I possibly insert a CLOB greater than 12288 char? Thanks a lot in advance for your support Roberto Minarelli Della Valle Il giorno ven 22 dic 2023 alle ore 15:37 Boris Kolpackov < boris@codesynthesis.com> ha scritto: > roberto minarelli writes: > > > I am trying to inserting a in a column specified as CLOB more than 12288 > > chars, that appears to be the actual limit > > > > ORA-01461: can bind a LONG value only for insert into a LONG column > > I don't believe you should be getting this error when trying to insert > this amount of data into CLOB. I suspect you are trying to insert it > (perhaps by mistake) into, for example, a VARCHAR2 column. I would > suggest that you create a separate test with a single object that > contains a single column of the CLOB type (plus the id column) and > try this. If you are able to insert more than 12288 characters in > this test, then there is something wrong with your application. > > Also see: > > > https://stackoverflow.com/questions/9156019/ora-01461-can-bind-a-long-value-only-for-insert-into-a-long-column-occurs-when/14497831 > From michael.dembroge at leica-geosystems.com Thu Jan 11 21:05:51 2024 From: michael.dembroge at leica-geosystems.com (DEMBROGE Michael) Date: Thu Jan 11 20:56:36 2024 Subject: [odb-users] gcc issue with odb compiler Message-ID: Hello, After building ODB 2.5.0-b25, I'm getting a strange error message when I attempt to compile a project: 10>cc1plus.exe : error : plugin support is disabled; configure with --enable-plugin After some reading and research, I believe this is telling me is that the gcc compiler being invoked by the ODB compiler (odb.exe) is not configured to support plugins. Am I supposed to re-compile gcc on my system in order to use ODB 2.5.0-b25 on Windows? Or, is there another/better route? Thank you, Mike Dembroge Leica Geosystems From alaiseca at gmail.com Thu Jan 11 18:30:53 2024 From: alaiseca at gmail.com (Aldo Laiseca) Date: Thu Jan 11 23:27:52 2024 Subject: [odb-users] Problem with inheritance and composite value Message-ID: <8DFFB6A3-5AD7-46A8-97C3-AEF0601B2D34@gmail.com> Hi, I would appreciate some help to overcome a problem with this scenario: I have three clases, say A,B,C, mapping to three different tables. All the tables have in common a set of columns which I consider appropriate to be grouped into a composite value, so I created a class, say CV, to represent that composite value, like this: /* CV.h */ #include #include #include #include #pragma db value class CV { private: #pragma db get(getPropertyA) set(setPropertyA) #pragma db column(?prop_a") not_null std::string propA; #pragma db get(getPropertyB) set(setPropertyB) #pragma db column(?prop_b") not_null std::string propB; #pragma db get(getAnotherEntity) set(setAnotherEntity) #pragma db column("id_another_entity") not_null std::shared_ptr anotherEntity; ? public: CV() = default; virtual ~CV() = default; std::string getPropertyA() const; void setPropertyA(const std::string& propA); std::string getPropertyB() const; void setPropertyB(const std::string& propB); std::shared_ptr getAnotherEntity() const; void setAnotherEntity(std::shared_ptr anotherEntity); ... }; Now, since three tables have the same group of columns, instead of repeating the composite value as property and its getters and setters methods in each class A, B and C, I thought I was a better idea to have a common base abstract class doing so, like this: /* BaseClass.h */ #include #include ?CV.h" #pragma db object abstract class BaseClass { protected: #pragma db get(getCV) set(setCV) CV cv; CV() = default; virtual ~CV() = default; public: CV getCV() const; void setCV(const CV& cv); }; And class A, for instance, would look like this (similar for B and C): /* A.h */ #pragma db object table(?table_A") class A : public BaseClass { private: /* Declare all the necessary properties except those already included in CV */ }; My odb compiler script looks like this: odb -I /usr/local/include -d pgsql --std c++17 BaseClass.h odb -I /usr/local/include -d pgsql --std c++17 InfoDomicilio.h odb -I /usr/local/include -d pgsql --generate-query --std c++17 A.h No problems so far; files -odb.hxx and orb-ixx being generated ok for all the above lines. However, at the moment I try to write a query for clase A like this: #include "A.h" #include "A-odb.hxx" typedef odb::query query; std::shared_ptr MyDAO::searchByPropX(const std::string &ref) { return db->query_one(query::propX == query::_ref(ref)); } My compiler (clang Mac OS Intel with BigSur 11.7) complains: A-odb.hxx:483:5: error: implicit instantiation of undefined template 'odb::query_columns>' query_columns< ::BaseClass, id_pgsql, A >, /usr/local/include/odb/pgsql/query.hxx:2050:25: note: in instantiation of template class 'odb::query_columns>' requested here public query_selector::columns_type /usr/local/include/odb/pgsql/query.hxx:2120:45: note: in instantiation of template class 'odb::pgsql::query' requested here class query: public pgsql::query ^ ../MyDAO.cpp:9:38: note: in instantiation of template class 'odb::query' requested here return db->query_one(query::propX == query::_ref(ref)); ^ /usr/local/include/odb/query.hxx:30:10: note: template is declared here struct query_columns; ^ In file included from ../MyDAO.cpp:3: ../A-odb.hxx:484:5: error: implicit instantiation of undefined template 'odb::query_columns>' query_columns< ::BaseClass, id_pgsql, A > ^ /usr/local/include/odb/query.hxx:30:10: note: template is declared here struct query_columns; ^ 1 warning generated. ../MyDAO.cpp:9:62: error: no member named '_ref' in 'odb::query' return db->query_one(query::propX == query::_ref(ref)); Could you please advise on this? Any help is highly appreciated. Thanks!!! From boris at codesynthesis.com Fri Jan 12 05:30:50 2024 From: boris at codesynthesis.com (Boris Kolpackov) Date: Fri Jan 12 05:21:26 2024 Subject: [odb-users] Inserting CLOB greater having size greater then 12288 In-Reply-To: References: Message-ID: roberto minarelli writes: > [2024-01-09 19:48:17.347] [info] len is 19999 > [2024-01-09 19:48:17.348] [error] error is 1461: ORA-01461: can bind a LONG > value only for insert into a LONG column I am not sure what's going on here. Can you try to insert the same length value into this column from a different Oracle client (e.g., sqlplus)? If that works, then the issue is probably in libodb-oracle somewhere. Unfortunately I won't have time to look into this any time soon so I suggest that you try to debug it yourself. From boris at codesynthesis.com Fri Jan 12 05:35:50 2024 From: boris at codesynthesis.com (Boris Kolpackov) Date: Fri Jan 12 05:26:26 2024 Subject: [odb-users] gcc issue with odb compiler In-Reply-To: References: Message-ID: DEMBROGE Michael writes: > 10>cc1plus.exe : error : plugin support is disabled; configure > with --enable-plugin Per the instructions[1] you should be using MinGW GCC supplied with build2. It has been configured with plugins enabled, has been tested with ODB, and is known to work. If you did build ODB as instructed, then perhaps you have a different g++ in your PATH? Try running the following from the command line prompt: > where g++ This should point to C:\build2\bin\g++.exe or similar. [1] https://codesynthesis.com/products/odb/doc/install-build2.xhtml#windows-build2 From boris at codesynthesis.com Fri Jan 12 05:38:13 2024 From: boris at codesynthesis.com (Boris Kolpackov) Date: Fri Jan 12 05:28:49 2024 Subject: [odb-users] Problem with inheritance and composite value In-Reply-To: <8DFFB6A3-5AD7-46A8-97C3-AEF0601B2D34@gmail.com> References: <8DFFB6A3-5AD7-46A8-97C3-AEF0601B2D34@gmail.com> Message-ID: Aldo Laiseca writes: > odb -I /usr/local/include -d pgsql --std c++17 BaseClass.h > odb -I /usr/local/include -d pgsql --std c++17 InfoDomicilio.h > odb -I /usr/local/include -d pgsql --generate-query --std c++17 A.h > > [...] > > A-odb.hxx:483:5: error: implicit instantiation of undefined template 'odb::query_columns>' > query_columns< ::BaseClass, id_pgsql, A >, Try compiling all your headers with --generate-query. From roberto.minarelli.de at gmail.com Fri Jan 12 13:54:30 2024 From: roberto.minarelli.de at gmail.com (roberto minarelli) Date: Mon Jan 15 05:18:59 2024 Subject: [odb-users] Inserting CLOB greater having size greater then 12288 In-Reply-To: References: Message-ID: Hi Boris, yes indeed I can insert the same length CLOB into the column using a different Oracle client I can try to debug it by myself but do you have any hint? Thanks a lot Roberto Minarelli Della Valle Il giorno ven 12 gen 2024 alle ore 11:30 Boris Kolpackov < boris@codesynthesis.com> ha scritto: > roberto minarelli writes: > > > [2024-01-09 19:48:17.347] [info] len is 19999 > > [2024-01-09 19:48:17.348] [error] error is 1461: ORA-01461: can bind a > LONG > > value only for insert into a LONG column > > I am not sure what's going on here. Can you try to insert the same > length value into this column from a different Oracle client (e.g., > sqlplus)? > > If that works, then the issue is probably in libodb-oracle somewhere. > Unfortunately I won't have time to look into this any time soon so > I suggest that you try to debug it yourself. > From boris at codesynthesis.com Mon Jan 15 05:32:40 2024 From: boris at codesynthesis.com (Boris Kolpackov) Date: Mon Jan 15 05:23:18 2024 Subject: [odb-users] Inserting CLOB greater having size greater then 12288 In-Reply-To: References: Message-ID: roberto minarelli writes: > I can try to debug it by myself but do you have any hint? Start the test you wrote under the debugger and step into the ODB function that throws the exception. The underlying error is most likely reported by the OCI API, which will most likely be either when binding the parameter or when executing the statement. Look at how things are bound and executed, read OCI documentation, and try to figure out what could possible be wrong. From roberto.minarelli.de at gmail.com Mon Jan 15 13:55:47 2024 From: roberto.minarelli.de at gmail.com (roberto minarelli) Date: Tue Jan 16 09:08:55 2024 Subject: [odb-users] Inserting CLOB greater having size greater then 12288 In-Reply-To: References: Message-ID: Hi Boris, I give an update on version 2.4.0 but with different OS and compiler (g++ 7.3.1) it works fine on versione 2.5.0-b-23 with g++ 8.5.0 and OS OL 8.7 it does not on insert and update, but it works when I try to load an object that has the the Lob length > 12288 I suspect that the problem is on the exchanging of data between a string with a that length and a CLOB I cannot be still sure though Regards Roberto Minarelli Della Valle Il giorno lun 15 gen 2024 alle ore 11:55 roberto minarelli < roberto.minarelli.de@gmail.com> ha scritto: > Ok thanks > I'll have a look as you described > > Roberto Minarelli Della Valle > > Il giorno lun 15 gen 2024 alle ore 11:32 Boris Kolpackov < > boris@codesynthesis.com> ha scritto: > >> roberto minarelli writes: >> >> > I can try to debug it by myself but do you have any hint? >> >> Start the test you wrote under the debugger and step into the >> ODB function that throws the exception. The underlying error >> is most likely reported by the OCI API, which will most likely >> be either when binding the parameter or when executing the >> statement. Look at how things are bound and executed, read >> OCI documentation, and try to figure out what could possible >> be wrong. >> > From boris at codesynthesis.com Wed Jan 17 08:09:13 2024 From: boris at codesynthesis.com (Boris Kolpackov) Date: Wed Jan 17 07:59:48 2024 Subject: [odb-users] Inserting CLOB greater having size greater then 12288 In-Reply-To: References: Message-ID: roberto minarelli writes: > on version 2.4.0 but with different OS and compiler (g++ 7.3.1) it works > fine > on versione 2.5.0-b-23 with g++ 8.5.0 and OS OL 8.7 it does not on insert > and update, but it works when I try to load an object that has the the Lob > length > 12288 Hm, interesting. The bug is then most likely either in some changes in libodb-oracle or in the generated code. I looked through the libodb-oracle changelog and the only commit that stood out is this one: https://git.codesynthesis.com/cgit/odb/libodb-oracle/commit/?id=76a03fd7964b85cdc1a903df79bfd47711c720e9 With the following commit making the corresponding changes in the ODB compiler: https://git.codesynthesis.com/cgit/odb/odb/commit/?id=858b2d37950c33cdf076382849de952ea44d7779 I think there is a very good change that this where the regression is. Could you review it and see if you can spot anything amiss? Regarding the generated code, you may want to diff the 2.4.0 vs 2.5.0 *-odb.?xx files and see if there is anything else that could cause this regression. From michael.dembroge at leica-geosystems.com Wed Jan 17 13:21:09 2024 From: michael.dembroge at leica-geosystems.com (DEMBROGE Michael) Date: Wed Jan 17 13:11:57 2024 Subject: [odb-users] ODB 2.5.0-b25 compiler hangs when compiling (where 2.4.0 did not) Message-ID: Hello, After upgrading from ODB 2.4.0 to ODB 2.5.0-b25, some of our .hxx files no longer compile. The odb compiler hangs and must be forced to shut down via End Task. Here is the contents of the smallest/simplest file that no longer compiles in 2.5.0-b25 (but does compile in 2.4.0): // Contents of OdbEigen.hxx #pragma once #include #include typedef std::array std_array_3d; namespace Eigen { #pragma db value (Eigen::Vector3d) transient #pragma db member(Eigen::Vector3d::data) virtual(std_array_3d) \ get( *( reinterpret_cast(&this)) ) \ set( operator=(* reinterpret_cast(&(?)) )) } // end namespace Eigen I'm very new to ODB, so if anyone sees something obvious or there's something that changed in 2.5.0-b25, please let me know. Thank you in advance, Mike Dembroge Leica Geosystems From roberto.minarelli.de at gmail.com Thu Jan 18 10:08:58 2024 From: roberto.minarelli.de at gmail.com (roberto minarelli) Date: Thu Jan 18 10:35:28 2024 Subject: [odb-users] Inserting CLOB greater having size greater then 12288 In-Reply-To: References: Message-ID: Hi Boris, the error come out at /usr/local/include/odb/oracle/statement.hxx line 333 unfortunately I cannot go deeper into debugging Don't know if with this further indication you can easily discover a solution Roberto Minarelli Della Valle Il giorno mer 17 gen 2024 alle ore 14:56 roberto minarelli < roberto.minarelli.de@gmail.com> ha scritto: > Hi Boris, > thanks for the link > I will have a look at them > > Roberto Minarelli Della Valle > > Il giorno mer 17 gen 2024 alle ore 14:09 Boris Kolpackov < > boris@codesynthesis.com> ha scritto: > >> roberto minarelli writes: >> >> > on version 2.4.0 but with different OS and compiler (g++ 7.3.1) it works >> > fine >> > on versione 2.5.0-b-23 with g++ 8.5.0 and OS OL 8.7 it does not on >> insert >> > and update, but it works when I try to load an object that has the the >> Lob >> > length > 12288 >> >> Hm, interesting. The bug is then most likely either in some changes in >> libodb-oracle or in the generated code. >> >> I looked through the libodb-oracle changelog and the only commit that >> stood out is this one: >> >> >> https://git.codesynthesis.com/cgit/odb/libodb-oracle/commit/?id=76a03fd7964b85cdc1a903df79bfd47711c720e9 >> >> With the following commit making the corresponding changes in the ODB >> compiler: >> >> >> https://git.codesynthesis.com/cgit/odb/odb/commit/?id=858b2d37950c33cdf076382849de952ea44d7779 >> >> I think there is a very good change that this where the regression is. >> Could you review it and see if you can spot anything amiss? >> >> Regarding the generated code, you may want to diff the 2.4.0 vs 2.5.0 >> *-odb.?xx files and see if there is anything else that could cause this >> regression. >> > From boris at codesynthesis.com Fri Jan 19 10:04:39 2024 From: boris at codesynthesis.com (Boris Kolpackov) Date: Fri Jan 19 09:55:16 2024 Subject: [odb-users] ODB 2.5.0-b25 compiler hangs when compiling (where 2.4.0 did not) In-Reply-To: References: Message-ID: DEMBROGE Michael writes: > After upgrading from ODB 2.4.0 to ODB 2.5.0-b25, some of our .hxx > files no longer compile. The odb compiler hangs and must be forced > to shut down via End Task. > > Here is the contents of the smallest/simplest file that no longer > compiles in 2.5.0-b25 (but does compile in 2.4.0): I was able to reproduce this on the latest master, thanks for the report. That's definitely a bug in ODB and I have a fix but it's not exactly trivial so need to test it a bit more for regressions. I should have something for you to try early next week. From michael.dembroge at leica-geosystems.com Fri Jan 19 13:09:34 2024 From: michael.dembroge at leica-geosystems.com (DEMBROGE Michael) Date: Fri Jan 19 13:00:19 2024 Subject: [odb-users] ODB 2.5.0-b25 compiler hangs when compiling (where 2.4.0 did not) In-Reply-To: References: Message-ID: That is great news (for me anyway ?) Thank you for the response and your efforts. Mike Dembroge Leica Geosystems -----Original Message----- From: Boris Kolpackov Sent: Friday, January 19, 2024 7:05 AM To: DEMBROGE Michael Cc: odb-users@codesynthesis.com Subject: Re: [odb-users] ODB 2.5.0-b25 compiler hangs when compiling (where 2.4.0 did not) [You don't often get email from boris@codesynthesis.com. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ] This email is not from Hexagon?s Office 365 instance. Please be careful while clicking links, opening attachments, or replying to this email. DEMBROGE Michael writes: > After upgrading from ODB 2.4.0 to ODB 2.5.0-b25, some of our .hxx > files no longer compile. The odb compiler hangs and must be forced to > shut down via End Task. > > Here is the contents of the smallest/simplest file that no longer > compiles in 2.5.0-b25 (but does compile in 2.4.0): I was able to reproduce this on the latest master, thanks for the report. That's definitely a bug in ODB and I have a fix but it's not exactly trivial so need to test it a bit more for regressions. I should have something for you to try early next week. From boris at codesynthesis.com Mon Jan 22 06:44:03 2024 From: boris at codesynthesis.com (Boris Kolpackov) Date: Mon Jan 22 06:34:40 2024 Subject: [odb-users] ODB 2.5.0-b25 compiler hangs when compiling (where 2.4.0 did not) In-Reply-To: References: Message-ID: Ok, I've published a revision of 2.5.0-b.25, for now to the queue: https://queue.cppget.org/odb/2.5.0-b.25+1 Could you try it on your project and let me know if there are still any issues? Specifically, you can build 2.5.0-b.25+1 by replacing this command in the instructions: bpkg build odb@https://pkg.cppget.org/1/beta With: bpkg build odb@https://pkg.cppget.org/1/queue/beta You don't need to rebuild the runtime libraries. If you confirm it's all good, I will migrate it to cppget.org. From michael.dembroge at leica-geosystems.com Mon Jan 22 13:42:18 2024 From: michael.dembroge at leica-geosystems.com (DEMBROGE Michael) Date: Mon Jan 22 13:33:02 2024 Subject: [odb-users] ODB 2.5.0-b25 compiler hangs when compiling (where 2.4.0 did not) In-Reply-To: References: Message-ID: Thank you very much. I will get on this ASAP and get back to you. Mike Dembroge Leica Geosystems -----Original Message----- From: Boris Kolpackov Sent: Monday, January 22, 2024 3:44 AM To: DEMBROGE Michael Cc: odb-users@codesynthesis.com Subject: Re: [odb-users] ODB 2.5.0-b25 compiler hangs when compiling (where 2.4.0 did not) [You don't often get email from boris@codesynthesis.com. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ] This email is not from Hexagon's Office 365 instance. Please be careful while clicking links, opening attachments, or replying to this email. Ok, I've published a revision of 2.5.0-b.25, for now to the queue: https://queue.cppget.org/odb/2.5.0-b.25+1 Could you try it on your project and let me know if there are still any issues? Specifically, you can build 2.5.0-b.25+1 by replacing this command in the instructions: bpkg build odb@https://pkg.cppget.org/1/beta With: bpkg build odb@https://pkg.cppget.org/1/queue/beta You don't need to rebuild the runtime libraries. If you confirm it's all good, I will migrate it to cppget.org. From michael.dembroge at leica-geosystems.com Thu Jan 25 16:26:40 2024 From: michael.dembroge at leica-geosystems.com (DEMBROGE Michael) Date: Thu Jan 25 16:17:25 2024 Subject: [odb-users] ODB 2.5.0-b25 compiler hangs when compiling (where 2.4.0 did not) In-Reply-To: References: Message-ID: Hello Boris, I am unable to build/configure 2.5.0.b25+1. I have tried the following steps, but without success: 1. I clicked on the links you sent me to replace instructions in build process. These links are to an email, and so when activated, I get an Outlook email client window. Here is the link you sent me (copied from below): [Boris Kolpackov wrote]: Specifically, you can build 2.5.0-b.25+1 by replacing this command in the instructions: bpkg build odb@https://pkg.cppget.org/1/beta 2. I then tried to rebuild everything, but used the repository "https://pkg.cppget.org/1/queue/beta" (as opposed to https://pkg.cppget.org/1/beta) when rebuilding. The appeared to work, but I then ran into trouble with the subsequent commands: >bpkg build libodb - This returns an error: unknown package 3. I then tried ">bpkg build odb", and this appears to work but none of the other packages will build: libodb-sqlite, libodb-qt, etc. Is there anything you can do to help? I'm pretty stuck here. Thank you, Mike Dembroge Leica Geosystems -----Original Message----- From: Boris Kolpackov Sent: Monday, January 22, 2024 3:44 AM To: DEMBROGE Michael Cc: odb-users@codesynthesis.com Subject: Re: [odb-users] ODB 2.5.0-b25 compiler hangs when compiling (where 2.4.0 did not) [You don't often get email from boris@codesynthesis.com. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ] This email is not from Hexagon's Office 365 instance. Please be careful while clicking links, opening attachments, or replying to this email. Ok, I've published a revision of 2.5.0-b.25, for now to the queue: https://queue.cppget.org/odb/2.5.0-b.25+1 Could you try it on your project and let me know if there are still any issues? Specifically, you can build 2.5.0-b.25+1 by replacing this command in the instructions: bpkg build odb@https://pkg.cppget.org/1/beta With: bpkg build odb@https://pkg.cppget.org/1/queue/beta You don't need to rebuild the runtime libraries. If you confirm it's all good, I will migrate it to cppget.org. From boris at codesynthesis.com Thu Jan 25 23:22:30 2024 From: boris at codesynthesis.com (Boris Kolpackov) Date: Thu Jan 25 23:13:06 2024 Subject: [odb-users] ODB 2.5.0-b25 compiler hangs when compiling (where 2.4.0 did not) In-Reply-To: References: Message-ID: DEMBROGE Michael writes: > bpkg build odb@https://pkg.cppget.org/1/beta > > 2. I then tried to rebuild everything, but used the repository > "https://pkg.cppget.org/1/queue/beta" (as opposed to > https://pkg.cppget.org/1/beta) when rebuilding. The appeared to work, You only need to rebuild and reinstall the ODB compiler. In other words, only complete the "Building ODB compiler" step in the instructions but using .../1/queue/beta instead of .../1/beta in the URL > but I then ran into trouble with the subsequent commands: > >bpkg build libodb - This returns an error: unknown package You do not need to rebuild the runtime libraries. If you do need to build them (for example, you are doing a fresh installation), then use the original (.../1/beta) URL for the "Building ODB Runtime Libraries" step. From michael.dembroge at leica-geosystems.com Fri Jan 26 13:16:49 2024 From: michael.dembroge at leica-geosystems.com (DEMBROGE Michael) Date: Fri Jan 26 13:07:32 2024 Subject: [odb-users] ODB 2.5.0-b25 compiler hangs when compiling (where 2.4.0 did not) In-Reply-To: References: Message-ID: Ah, that makes sense. Thank you Boris. I will implement this today and let you of the results. Mike Dembroge Leica Geosystems -----Original Message----- From: Boris Kolpackov Sent: Thursday, January 25, 2024 8:23 PM To: DEMBROGE Michael Cc: odb-users@codesynthesis.com Subject: Re: [odb-users] ODB 2.5.0-b25 compiler hangs when compiling (where 2.4.0 did not) [You don't often get email from boris@codesynthesis.com. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ] This email is not from Hexagon's Office 365 instance. Please be careful while clicking links, opening attachments, or replying to this email. DEMBROGE Michael writes: > bpkg build > odb@https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2F > pkg.cppget.org%2F1%2Fbeta&data=05%7C02%7Cmichael.dembroge%40leica-geos > ystems.com%7C9804f6fb9d3241b890b708dc1e266d50%7C1b16ab3eb8f64fe39f3e2d > b7fe549f6a%7C0%7C0%7C638418397593067662%7CUnknown%7CTWFpbGZsb3d8eyJWIj > oiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C > %7C%7C&sdata=zbST1jktXcozg35Bz3M5FT2crj2sWCjvTKpJTWs3%2FmY%3D&reserved > =0 > > 2. I then tried to rebuild everything, but used the repository > "https://pkg.cppget.org/1/queue/beta" (as opposed to > > https://pkg/. > cppget.org%2F1%2Fbeta&data=05%7C02%7Cmichael.dembroge%40leica-geosyste > ms.com%7C9804f6fb9d3241b890b708dc1e266d50%7C1b16ab3eb8f64fe39f3e2db7fe > 549f6a%7C0%7C0%7C638418397593081733%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC > 4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C% > 7C&sdata=R9mB0huUGWLF5PjCQRg7ETkYTM4x%2F3P6X6M%2FdS3yZlM%3D&reserved=0 > ) when rebuilding. The appeared to work, You only need to rebuild and reinstall the ODB compiler. In other words, only complete the "Building ODB compiler" step in the instructions but using .../1/queue/beta instead of .../1/beta in the URL > but I then ran into trouble with the subsequent commands: > >bpkg build libodb - This returns an error: unknown package You do not need to rebuild the runtime libraries. If you do need to build them (for example, you are doing a fresh installation), then use the original (.../1/beta) URL for the "Building ODB Runtime Libraries" step. From michael.dembroge at leica-geosystems.com Fri Jan 26 17:30:35 2024 From: michael.dembroge at leica-geosystems.com (DEMBROGE Michael) Date: Fri Jan 26 17:21:20 2024 Subject: [odb-users] ODB 2.5.0-b25 compiler hangs when compiling (where 2.4.0 did not) In-Reply-To: References: Message-ID: Hello Boris, Just to let you know that your fix to the ODB compiler, in ODB 2.5.0-b25+1, works great. No longer does it hang when compiling a .hxx file that uses Eigen types. Additionally, our suite of unit-tests complete without issue as well, so this is also very good. If you do an official new version (i.e. not in /queue/beta), let me know and I will pull/compile/test. Thank you again, Mike Dembroge Leica Geosystems -----Original Message----- From: Boris Kolpackov Sent: Monday, January 22, 2024 3:44 AM To: DEMBROGE Michael Cc: odb-users@codesynthesis.com Subject: Re: [odb-users] ODB 2.5.0-b25 compiler hangs when compiling (where 2.4.0 did not) [You don't often get email from boris@codesynthesis.com. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ] This email is not from Hexagon's Office 365 instance. Please be careful while clicking links, opening attachments, or replying to this email. Ok, I've published a revision of 2.5.0-b.25, for now to the queue: https://queue.cppget.org/odb/2.5.0-b.25+1 Could you try it on your project and let me know if there are still any issues? Specifically, you can build 2.5.0-b.25+1 by replacing this command in the instructions: bpkg build odb@https://pkg.cppget.org/1/beta With: bpkg build odb@https://pkg.cppget.org/1/queue/beta You don't need to rebuild the runtime libraries. If you confirm it's all good, I will migrate it to cppget.org. From roberto.minarelli.de at gmail.com Mon Jan 29 06:11:30 2024 From: roberto.minarelli.de at gmail.com (roberto minarelli) Date: Tue Jan 30 08:26:20 2024 Subject: [odb-users] Inserting CLOB greater having size greater then 12288 In-Reply-To: References: Message-ID: Hi Boris, have you an update for this issue? I tried to debug the callback but I couldn't step into it My guess is that the callback is called three times, each of which with a chunk of 4Kb of maximum dimension when writing And it is called maximum three times first time with OCI_FIRST_PIECE second time with OCI_NEXT_PIECE and finally with OCI_LAST_PIECE But as I said before I could not managed to step into it Thank for the support Roberto Minarelli Della Valle Il giorno gio 18 gen 2024 alle ore 16:08 roberto minarelli < roberto.minarelli.de@gmail.com> ha scritto: > Hi Boris, > the error come out at /usr/local/include/odb/oracle/statement.hxx line 333 > unfortunately I cannot go deeper into debugging > > Don't know if with this further indication you can easily discover a > solution > > Roberto Minarelli Della Valle > > Il giorno mer 17 gen 2024 alle ore 14:56 roberto minarelli < > roberto.minarelli.de@gmail.com> ha scritto: > >> Hi Boris, >> thanks for the link >> I will have a look at them >> >> Roberto Minarelli Della Valle >> >> Il giorno mer 17 gen 2024 alle ore 14:09 Boris Kolpackov < >> boris@codesynthesis.com> ha scritto: >> >>> roberto minarelli writes: >>> >>> > on version 2.4.0 but with different OS and compiler (g++ 7.3.1) it >>> works >>> > fine >>> > on versione 2.5.0-b-23 with g++ 8.5.0 and OS OL 8.7 it does not on >>> insert >>> > and update, but it works when I try to load an object that has the the >>> Lob >>> > length > 12288 >>> >>> Hm, interesting. The bug is then most likely either in some changes in >>> libodb-oracle or in the generated code. >>> >>> I looked through the libodb-oracle changelog and the only commit that >>> stood out is this one: >>> >>> >>> https://git.codesynthesis.com/cgit/odb/libodb-oracle/commit/?id=76a03fd7964b85cdc1a903df79bfd47711c720e9 >>> >>> With the following commit making the corresponding changes in the ODB >>> compiler: >>> >>> >>> https://git.codesynthesis.com/cgit/odb/odb/commit/?id=858b2d37950c33cdf076382849de952ea44d7779 >>> >>> I think there is a very good change that this where the regression is. >>> Could you review it and see if you can spot anything amiss? >>> >>> Regarding the generated code, you may want to diff the 2.4.0 vs 2.5.0 >>> *-odb.?xx files and see if there is anything else that could cause this >>> regression. >>> >> From boris at codesynthesis.com Tue Jan 30 08:59:15 2024 From: boris at codesynthesis.com (Boris Kolpackov) Date: Tue Jan 30 08:49:47 2024 Subject: [odb-users] ODB 2.5.0-b25 compiler hangs when compiling (where 2.4.0 did not) In-Reply-To: References: Message-ID: DEMBROGE Michael writes: > Just to let you know that your fix to the ODB compiler, in > ODB 2.5.0-b25+1, works great. No longer does it hang when compiling > a .hxx file that uses Eigen types. > > Additionally, our suite of unit-tests complete without issue as well, > so this is also very good. Good to hear, thanks for the confirmation. > If you do an official new version (i.e. not in /queue/beta), let me > know and I will pull/compile/test. I've now replaced odb-2.5.0-b.25 with the odb-2.5.0-b.25+1 revision on cppget.org. From alaiseca at gmail.com Wed Jan 31 00:11:48 2024 From: alaiseca at gmail.com (Aldo Laiseca) Date: Wed Jan 31 07:58:52 2024 Subject: [odb-users] Problem with bidirectional relationship Message-ID: <4416DF91-49E7-4C15-9051-1729EED5BC1F@gmail.com> Hi, I have two tables that, for the sake of simplicity, could be seen as: CREATE TABLE IF NOT EXISTS TABLE_A( ID BIGSERIAL NOT NULL, ? OTHER FIELDS ... PRIMARY KEY(ID) ); CREATE TABLE IF NOT EXISTS TABLE_B( ID VARCHAR(20) NOT NULL, ID_A BIGINT NOT NULL, ? OTHER FIELDS ... PRIMARY KEY(ID), FOREIGN KEY(ID_A) REFERENCES TABLE_A(ID) ON DELETE NO ACTION ON UPDATE NO ACTION ); That is, I have a one to many relationship from A to B (A can have many B?s but B can have only one A). I have created the corresponding headers like this: #A.h class B; #pragma db object table(?TABLE_A?) class A { private: #pragma db get(getId) set(setId) #pragma db id auto column("id") not_null unsigned long id; #pragma db get(getB) set(setB) #pragma db value_null inverse(a) std::vector> b; /* This is line 45 in the real header which is causing the problem */ ? public: A() = default; virtual ~A() = default; unsigned long getId() const { return id } void setId(unsigned long id) { this->id = id; } ?. }; # B.h #pragma db object table(?TABLE_B") class B { private: #pragma db get(getId) set(setId) #pragma db id column("id") not_null std::string id; #pragma db get(getA) set(setA) #pragma db column("id_a") not_null odb::lazy_shared_ptr a; ? public: B() = default; virtual ~B() = default; unsigned long getId() const { return id } void setId(unsigned long id) { this->id = id; } odb::lazy_shared_ptr getA() const { return a; } void setA(odb::lazy_shared_ptr a) { this->a = a; } ?. }; My odb scripts for these classes look like this: odb -I /usr/local/include -d pgsql --generate-query --odb-epilogue "#include \?B.h\"" --std c++17 A.h odb -I /usr/local/include -d pgsql --generate-query --std c++17 B.h However, my script fails saying this: A.h:45:55: error: unable to map C++ type '::std::__new_allocator< ::odb::lazy_weak_ptr< ::B > >::value_type' used in data member ?b' to a PostgreSQL database type A.h:45:55: info: use '#pragma db value_type' to specify the database type A.h:45:55: error: unable to map C++ type '::std::__new_allocator< ::odb::lazy_weak_ptr< ::B > >::value_type' used in data member ?b' to a PostgreSQL database type A.h:45:55: info: use '#pragma db value_type' to specify the database type I have read the chapter 6 from the manual about bidirectional relationships and lazy pointers and based my code on the provided examples. Cannot figure out what the problem is. As usual, your help is highly appreciated. Regards, Aldo From victorgrch.intechs at gmail.com Wed Jan 31 08:05:36 2024 From: victorgrch.intechs at gmail.com (=?UTF-8?B?0JLQuNC60YLQvtGAINCT0YDQuNC90LXQstC40Yc=?=) Date: Wed Jan 31 07:58:52 2024 Subject: [odb-users] container is not saved in the database Message-ID: Hi, I am using ODB 2.5.0-b.25, gcc/g++11, qt5.15, mysql I have classes: Base, Animal, Man. Where Animal and Man are inherited from Base(polymorphic), and Man contains the Animal array as members. persist(Man) saves Man and the Animal array pointers, but does NOT save the original Animal. If you then request ?query()?, then when working with odb::result we will receive an exception ?odb::object_not_persistent? with the message ?object not persistent? I compile files with the command: *odb -I$QT_DIR/gcc_64/include -I**QT_DIR**/gcc_64/include/QtCore -I$EXTERNAL_LIB_DIR/libodb/include -I$PROJECT_DIR/ -x -fPIE -x -fPIC --profile qt --std c++17 -d mysql --generate-query --generate-schema --suppress-schema-version --schema-format separate --generate-session --output-dir $ODB_GEN_DIR **$PROJECT_DIR**/odbTest.h* *odbTest.h: *https://github.com/VictorManKBO/testOdb/blob/master/odbTest.h *main.cpp: *https://github.com/VictorManKBO/testOdb/blob/master/main.cpp *full qt project:* https://github.com/VictorManKBO/testOdb/tree/master Why when running my program 3/4 of the tables in the database are filled? mysql> select * from base; +---------------------------------------------------------+--------+ | id | typeid | +---------------------------------------------------------+--------+ | 0b5ee0ec-314b-4c91-a57a-998097ecdbde | Man | +---------------------------------------------------------+--------+ 1 row in set (0,00 sec) mysql> select * from man; +---------------------------------------------------------+------+ | id | name | +---------------------------------------------------------+------+ | 0b5ee0ec-314b-4c91-a57a-998097ecdbde | Jon | +---------------------------------------------------------+------+ 1 row in set (0,00 sec) mysql> select * from animal; Empty set (0,00 sec) mysql> select * from man_pets; +------------------------------------------------------- -+-------+-------+ | object_id | index | value | +---------------------------------------------------------+-------+-------+ | 0b5ee0ec-314b-4c91-a57a-998097ecdbde | 0 | 0 | | 0b5ee0ec-314b-4c91-a57a-998097ecdbde | 1 | 1 | | 0b5ee0ec-314b-4c91-a57a-998097ecdbde | 2 | 2 | | 0b5ee0ec-314b-4c91-a57a-998097ecdbde | 3 | 3 | | 0b5ee0ec-314b-4c91-a57a-998097ecdbde | 4 | 4 | +---------------------------------------------------------+-------+-------+ 5 rows in set (0,00 sec) In the last table(man_pets), the value should be a reference to base.id, and the XML file contains the following information: When I manually added the missing records to the Animal and Base tables, "query()" returned what I expected without exception INSERT INTO base (id,typeid) VALUES ('0','Animal'), ('1','Animal'), ('2','Animal'), ('3','Animal'), ('4','Animal'); INSERT INTO animal (id,nickname) VALUES ('0','pet_0'), ('1','pet_1'), ('2','pet_2'), ('3','pet_3'), ('4','pet_4');