From becoggins at hotmail.com Sat Aug 3 13:43:56 2024 From: becoggins at hotmail.com (Brian Coggins) Date: Sat Aug 3 13:44:18 2024 Subject: [odb-users] WITH Queries in Views In-Reply-To: References: Message-ID: Boris, Thank you so much! This solved the problem, and no issues encountered. Brian > On 31 Jul 2024, at 09:17, Boris Kolpackov wrote: > > Brian Coggins writes: > >> Yes, it tries to guess whether it's a complete query or the WHERE >> clause by checking if the query starts with one of the known keywords >> (like SELECT). I have a TODO item to recognize some additional database- >> specific keywords (like WITH). >> >> I?ve run into this limitation again, this time in the context of a >> WITH RECURSIVE ? query that I don?t think can be accomplished any >> other way. I upgraded to ODB 2.5.0-b.27 but it seems the issue is >> still there. >> >> Any chance we might be able to get a patch to loosen up these restrictions? > > Ok, I went ahead and added WITH as a recognized SELECT prefix (I see it's > also supported by SQLite). Plus I've added the /*SELECT*/ prefix as a > hint that what follows is a SELECT-like query (this is similar to the > /*CALL*/ hint we use to distinguish procedure calls in PostgreSQL, which > uses SELECT for everything). > > If you want to give it a try, I've published the snapshot packages here: > > https://queue.stage.build2.org > > Simply replace: > > https://pkg.cppget.org/1/beta > > with: > > https://queue.stage.build2.org/1/alpha > > in the bpkg commands when building ODB. > > Let me know if there any issues. From xuewen.ok at gmail.com Fri Aug 2 11:21:03 2024 From: xuewen.ok at gmail.com (xuewen wang) Date: Mon Aug 5 10:21:18 2024 Subject: [odb-users] Recursive Loading Issue with Mutual Aggregation in ODB Classes Message-ID: Dear ODB Development Team, I am writing to report a potential issue with the ODB ORM system when two model classes include or aggregate each other. This mutual aggregation can lead to recursive loading problems when querying records from the database. ### Example Scenario Consider the following two classes, `Person` and `Address`, where each `Person` has an `Address` and each `Address` has a `Person`. #### Person.hxx cpp #pragma once #include #include #include "Address.hxx" #pragma db object class Person { public: Person() = default; Person(const std::string& name, std::shared_ptr
address) : name_(name), address_(address) {} const std::string& name() const { return name_; } std::shared_ptr
address() const { return address_; } private: friend class odb::access; #pragma db id auto unsigned long id_; std::string name_; #pragma db not_null std::shared_ptr
address_; }; #### Address.hxx cpp #pragma once #include #include #include "Person.hxx" #pragma db object class Address { public: Address() = default; Address(const std::string& street, std::shared_ptr person) : street_(street), person_(person) {} const std::string& street() const { return street_; } std::shared_ptr person() const { return person_; } private: friend class odb::access; #pragma db id auto unsigned long id_; std::string street_; #pragma db not_null std::shared_ptr person_; }; ### Issue When querying a `Person` from the database, ODB will try to load the associated `Address`. While loading the `Address`, ODB will again try to load the associated `Person`, leading to a recursive loop. ### Query Example cpp #include #include #include #include "Person.hxx" #include "Person-odb.hxx" #include "Address.hxx" #include "Address-odb.hxx" int main() { std::shared_ptr db(new odb::sqlite::database("test.db", SQLITE_OPEN_READWRITE | SQLITE_OPEN_CREATE)); // Start a transaction odb::transaction t(db->begin()); // Query a person by id std::shared_ptr person(db->load(1)); // Commit the transaction t.commit(); // Access the person's address std::shared_ptr
address = person->address(); return 0; } In this example, loading a `Person` will recursively load the `Address`, which will again try to load the `Person`, causing a recursive call. ### Request Could you please look into this issue and provide a resolution or workaround? Thank you for your attention to this matter. Best regards, From xuewen.ok at gmail.com Fri Aug 2 23:23:54 2024 From: xuewen.ok at gmail.com (xuewen wang) Date: Mon Aug 5 10:21:18 2024 Subject: [odb-users] Re: Recursive Loading Issue with Mutual Aggregation in ODB Classes In-Reply-To: References: Message-ID: Sorry, all, It is my fault that I used the wrong inverse(id) keyword; it used the second class's id but not the inverse member id. Best regards... ---- Sean Wang (Xuewen Wang), Beijing, China. On Fri, Aug 2, 2024 at 11:21?PM xuewen wang wrote: > Dear ODB Development Team, > > I am writing to report a potential issue with the ODB ORM system when two > model classes include or aggregate each other. This mutual aggregation can > lead to recursive loading problems when querying records from the database. > > ### Example Scenario > > Consider the following two classes, `Person` and `Address`, where each > `Person` has an `Address` and each `Address` has a `Person`. > > #### Person.hxx > cpp > #pragma once > > #include > #include > #include "Address.hxx" > > #pragma db object > class Person > { > public: > Person() = default; > Person(const std::string& name, std::shared_ptr
address) > : name_(name), address_(address) {} > > const std::string& name() const { return name_; } > std::shared_ptr
address() const { return address_; } > > private: > friend class odb::access; > > #pragma db id auto > unsigned long id_; > std::string name_; > > #pragma db not_null > std::shared_ptr
address_; > }; > #### Address.hxx > cpp > #pragma once > > #include > #include > #include "Person.hxx" > > #pragma db object > class Address > { > public: > Address() = default; > Address(const std::string& street, std::shared_ptr person) > : street_(street), person_(person) {} > > const std::string& street() const { return street_; } > std::shared_ptr person() const { return person_; } > > private: > friend class odb::access; > > #pragma db id auto > unsigned long id_; > std::string street_; > > #pragma db not_null > std::shared_ptr person_; > }; > ### Issue > > When querying a `Person` from the database, ODB will try to load the > associated `Address`. While loading the `Address`, ODB will again try to > load the associated `Person`, leading to a recursive loop. > > ### Query Example > cpp > #include > #include > #include > #include "Person.hxx" > #include "Person-odb.hxx" > #include "Address.hxx" > #include "Address-odb.hxx" > > int main() > { > std::shared_ptr db(new odb::sqlite::database("test.db", > SQLITE_OPEN_READWRITE | SQLITE_OPEN_CREATE)); > > // Start a transaction > odb::transaction t(db->begin()); > > // Query a person by id > std::shared_ptr person(db->load(1)); > > // Commit the transaction > t.commit(); > > // Access the person's address > std::shared_ptr
address = person->address(); > > return 0; > } > In this example, loading a `Person` will recursively load the `Address`, > which will again try to load the `Person`, causing a recursive call. > > ### Request > > Could you please look into this issue and provide a resolution or > workaround? > > Thank you for your attention to this matter. > > Best regards, > From xuewen.ok at gmail.com Fri Aug 2 23:42:30 2024 From: xuewen.ok at gmail.com (xuewen wang) Date: Mon Aug 5 10:21:18 2024 Subject: [odb-users] Re: Recursive Loading Issue with Mutual Aggregation in ODB Classes In-Reply-To: References: Message-ID: I fixed the mistake mentioned in the previous email, but the recursive querying still exists. here are odb class headers and SQL log. Best regards... ---- Sean Wang (Xuewen Wang), Beijing, China. On Sat, Aug 3, 2024 at 11:23?AM xuewen wang wrote: > Sorry, all, > It is my fault that I used the wrong inverse(id) keyword; it used the > second class's id but not the inverse member id. > Best regards... > ---- Sean Wang (Xuewen Wang), Beijing, China. > > > On Fri, Aug 2, 2024 at 11:21?PM xuewen wang wrote: > >> Dear ODB Development Team, >> >> I am writing to report a potential issue with the ODB ORM system when two >> model classes include or aggregate each other. This mutual aggregation can >> lead to recursive loading problems when querying records from the database. >> >> ### Example Scenario >> >> Consider the following two classes, `Person` and `Address`, where each >> `Person` has an `Address` and each `Address` has a `Person`. >> >> #### Person.hxx >> cpp >> #pragma once >> >> #include >> #include >> #include "Address.hxx" >> >> #pragma db object >> class Person >> { >> public: >> Person() = default; >> Person(const std::string& name, std::shared_ptr
address) >> : name_(name), address_(address) {} >> >> const std::string& name() const { return name_; } >> std::shared_ptr
address() const { return address_; } >> >> private: >> friend class odb::access; >> >> #pragma db id auto >> unsigned long id_; >> std::string name_; >> >> #pragma db not_null >> std::shared_ptr
address_; >> }; >> #### Address.hxx >> cpp >> #pragma once >> >> #include >> #include >> #include "Person.hxx" >> >> #pragma db object >> class Address >> { >> public: >> Address() = default; >> Address(const std::string& street, std::shared_ptr person) >> : street_(street), person_(person) {} >> >> const std::string& street() const { return street_; } >> std::shared_ptr person() const { return person_; } >> >> private: >> friend class odb::access; >> >> #pragma db id auto >> unsigned long id_; >> std::string street_; >> >> #pragma db not_null >> std::shared_ptr person_; >> }; >> ### Issue >> >> When querying a `Person` from the database, ODB will try to load the >> associated `Address`. While loading the `Address`, ODB will again try to >> load the associated `Person`, leading to a recursive loop. >> >> ### Query Example >> cpp >> #include >> #include >> #include >> #include "Person.hxx" >> #include "Person-odb.hxx" >> #include "Address.hxx" >> #include "Address-odb.hxx" >> >> int main() >> { >> std::shared_ptr db(new >> odb::sqlite::database("test.db", SQLITE_OPEN_READWRITE | >> SQLITE_OPEN_CREATE)); >> >> // Start a transaction >> odb::transaction t(db->begin()); >> >> // Query a person by id >> std::shared_ptr person(db->load(1)); >> >> // Commit the transaction >> t.commit(); >> >> // Access the person's address >> std::shared_ptr
address = person->address(); >> >> return 0; >> } >> In this example, loading a `Person` will recursively load the `Address`, >> which will again try to load the `Person`, causing a recursive call. >> >> ### Request >> >> Could you please look into this issue and provide a resolution or >> workaround? >> >> Thank you for your attention to this matter. >> >> Best regards, >> > -------------- next part -------------- A non-text attachment was scrubbed... Name: 1.log Type: text/x-log Size: 5782 bytes Desc: not available Url : https://codesynthesis.com/pipermail/odb-users/attachments/20240803/0623edbd/1.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: IrradianceTemperatureDb.h Type: text/x-chdr Size: 2258 bytes Desc: not available Url : https://codesynthesis.com/pipermail/odb-users/attachments/20240803/0623edbd/IrradianceTemperatureDb.h -------------- next part -------------- A non-text attachment was scrubbed... Name: IrradianceProfileDb.h Type: text/x-chdr Size: 1328 bytes Desc: not available Url : https://codesynthesis.com/pipermail/odb-users/attachments/20240803/0623edbd/IrradianceProfileDb.h From boris at codesynthesis.com Tue Aug 6 08:38:06 2024 From: boris at codesynthesis.com (Boris Kolpackov) Date: Tue Aug 6 08:37:44 2024 Subject: [odb-users] querying object and loading into a stack variable, then setting its id to 0 and persisting In-Reply-To: References: Message-ID: MM writes: > I load 1 object with > Derived d; > db.query_one(..., d) > which returns true, and a Derived object is loaded. > > Then I change d's attributes, in particular I set d.id to 0, and other > attributes, then call > > db.persist(d); > > This inserted a row with id 0, then the next time around "duplicate" > because id is already present > > I mean this is really the crux of the question. How do I load a row into > d, "copy" it to another row, with the id being automatic, how to set id to > NULL? > > The question is both sqlite and portsgresl. the id is of c++ type > std::uint64_t This should not be happening. There must be something special (or broken) about your setup. I will need a complete reproducer to investigate this: - a header with the persistent object definitions - the ODB compiler command line used to compile this header - and the driver source file that reproduces the problem I should be able to do: odb ... test.hxx g++ ... -o driver driver.cxx test-odb.cxx ./driver # This should cause the duplicate id. From boris at codesynthesis.com Tue Aug 6 08:40:39 2024 From: boris at codesynthesis.com (Boris Kolpackov) Date: Tue Aug 6 08:40:13 2024 Subject: [odb-users] Recursive Loading Issue with Mutual Aggregation in ODB Classes In-Reply-To: References: Message-ID: xuewen wang writes: > I am writing to report a potential issue with the ODB ORM system when two > model classes include or aggregate each other. This mutual aggregation can > lead to recursive loading problems when querying records from the database. You need use a session to load such relationships: https://www.codesynthesis.com/products/odb/doc/manual.xhtml#11 From lloydkl.tech at gmail.com Fri Aug 9 03:56:19 2024 From: lloydkl.tech at gmail.com (Lloyd) Date: Fri Aug 9 03:59:41 2024 Subject: [odb-users] Unresolved symbol - ODB 2.5.0-b.27 - PostgreSQL Message-ID: Hi, I am trying out ODB 2.5 with PostgreSQL. When I link the application, I am getting a link error. unresolved external symbol "public: static enum odb::pgsql::details::endian_traits::endian const odb::pgsql::details::endian_traits::host_endian" I am using ODB in shared mode by setting compiler definition "LIBODB_SHARED" Any help is greatly appreciated Thanks a lot From me at raphieps.com Mon Aug 12 17:08:07 2024 From: me at raphieps.com (Raphael Palefsky-Smith) Date: Mon Aug 12 17:08:38 2024 Subject: [odb-users] Postgres Bulk Operations on Windows? In-Reply-To: References: Message-ID: Hi Boris - reviving this old topic, apologies for not responding before. I've been looking into pipeline mode some more, and it seems non-trivial to get working. However, I'm wondering if there are other, simpler methods to bulk insert a bunch of rows. I'm currently inserting ~750 records in a loop, and it's taking about 10ms per record. An EXPLAIN ANALYZE on the insert query reports about 0.150ms execution time, so I suspected the network as the primary bottleneck. Indeed, from looking at some Wireshark traces, it appears that we're waiting for a complete roundtrip to the database for each record. This makes sense given that the INSERT returns the newly created row's ID, and ODB has no way of knowing whether or not I'm going to use that ID mid-loop and needs to wait for its return before executing the next persist. So nothing can be optimized automatically. But perhaps there are tricks to do this insert without the per-row roundtrip? Maybe using Postgres arrays, or some other mechanism short of the full pipeline mode? I'll be running some tests using raw SQL, but if you know of any "idiomatic libodb" ways of doing this, let me know. Thanks again! On Tue, Jun 25, 2024 at 5:27?AM Boris Kolpackov wrote: > Raphael Palefsky-Smith writes: > > > Is this something that might be supported later, or is there something in > > the Windows networking stack that makes this impossible? > > I am a bit vague on this (it's been a while since I implemented this > support), but I believe it was either unsupported in libpq or required > a separate code on the ODB side (Winsock and all that fun). I think to > be sure you will have to dig into libpq and, if pipelining is supported > on Windows, see what it will take to support on the ODB side. > From me at raphieps.com Tue Aug 13 10:44:51 2024 From: me at raphieps.com (Raphael Palefsky-Smith) Date: Tue Aug 13 10:45:24 2024 Subject: [odb-users] Postgres Bulk Operations on Windows? In-Reply-To: References: Message-ID: I gave pipeline mode another shot and it was actually quite simple. I am getting a *50x* speedup, even more on slower connections. So a huge thank you for pipeline mode, it really does make a big difference. To get it working, I changed all instances of: #if defined(LIBPQ_HAS_PIPELINING) && !defined(_WIN32) to: #if defined(LIBPQ_HAS_PIPELINING) And then I added the following two lines to pgsql/statement.cxx. There's definitely a better way to link Winsock but I didn't want to dive into bpkg just yet: #include #pragma comment(lib, "Ws2_32.lib") Cheers! On Mon, Aug 12, 2024 at 5:08?PM Raphael Palefsky-Smith wrote: > Hi Boris - reviving this old topic, apologies for not responding before. > > I've been looking into pipeline mode some more, and it seems non-trivial > to get working. However, I'm wondering if there are other, simpler methods > to bulk insert a bunch of rows. > > I'm currently inserting ~750 records in a loop, and it's taking about 10ms > per record. An EXPLAIN ANALYZE on the insert query reports about 0.150ms > execution time, so I suspected the network as the primary bottleneck. > Indeed, from looking at some Wireshark traces, it appears that we're > waiting for a complete roundtrip to the database for each record. > > This makes sense given that the INSERT returns the newly created row's ID, > and ODB has no way of knowing whether or not I'm going to use that ID > mid-loop and needs to wait for its return before executing the next > persist. So nothing can be optimized automatically. But perhaps there are > tricks to do this insert without the per-row roundtrip? Maybe using > Postgres arrays, or some other mechanism short of the full pipeline mode? > > I'll be running some tests using raw SQL, but if you know of any > "idiomatic libodb" ways of doing this, let me know. Thanks again! > > > > On Tue, Jun 25, 2024 at 5:27?AM Boris Kolpackov > wrote: > >> Raphael Palefsky-Smith writes: >> >> > Is this something that might be supported later, or is there something >> in >> > the Windows networking stack that makes this impossible? >> >> I am a bit vague on this (it's been a while since I implemented this >> support), but I believe it was either unsupported in libpq or required >> a separate code on the ODB side (Winsock and all that fun). I think to >> be sure you will have to dig into libpq and, if pipelining is supported >> on Windows, see what it will take to support on the ODB side. >> > From xuewen.ok at gmail.com Thu Aug 8 09:24:13 2024 From: xuewen.ok at gmail.com (xuewen wang) Date: Tue Aug 13 10:46:58 2024 Subject: [odb-users] Issue with std::weak_ptr in Bidirectional Relationship with ODB Classes Message-ID: Dear ODB Users, I am encountering an issue when using `std::weak_ptr` to declare a bidirectional relationship between two ODB classes. Here are the details: 1. According to the libodb manual, `std::weak_ptr` can be used to declare a bidirectional relationship between two ODB classes, where one class uses `std::shared_ptr` and the other uses `std::weak_ptr` . 2. In all official examples, `lazy_weak_ptr` is predominantly used. 3. I have successfully compiled code using `lazy_weak_ptr` with forward declarations of the class members. 4. However, when I try to use `std::weak_ptr` , the compilation fails. It seems that `std::weak_ptr` requires the template parameter to have a complete definition, otherwise it results in a compilation error. The compilation error I am encountering is as follows: ====================[ Build | result_not_cache_bug | Debug ]==================== /opt/JetBrains/Toolbox/apps/CLion/ch-0/233.13135.93/bin/cmake/linux/x64/bin/cmake --build /path/to/project --target result_not_cache_bug -j 10 [1/6] Generating /path/to/project/IrradianceTemperatureDb-odb.h, /path/to/project/IrradianceTemperatureDb-odb.cpp, /path/to/project/IrradianceTemperatureDb-odb.ixx.h FAILED: /path/to/project/IrradianceTemperatureDb-odb.h /path/to/project/IrradianceTemperatureDb-odb.cpp /path/to/project/IrradianceTemperatureDb-odb.ixx.h cd /path/to/project/cmake-build-debug && /usr/bin/odb --database sqlite --generate-query --generate-schema --generate-session --std c++11 --hxx-suffix .h --cxx-suffix .cpp --ixx-suffix .ixx.h --output-dir /path/to/project -I /path/to/project --default-pointer std::shared_ptr /path/to/project/IrradianceTemperatureDb.h In file included from /usr/include/c++/10/bits/move.h:57, from /usr/include/c++/10/bits/stl_pair.h:59, from /usr/include/c++/10/bits/stl_algobase.h:64, from /usr/include/c++/10/bits/char_traits.h:39, from /usr/include/c++/10/string:40, from :7: /usr/include/c++/10/type_traits: In instantiation of ?struct std::is_constructible, const std::weak_ptr&>?: /usr/include/c++/10/bits/shared_ptr.h:688:8: required by substitution of ?template template using _Constructible = typename std::enable_if, _Arg>::value>::type [with _Arg = const std::weak_ptr&; _Tp = database::IrradianceProfileDb]? /usr/include/c++/10/bits/shared_ptr.h:707:30: required by substitution of ?template std::weak_ptr::weak_ptr(const std::weak_ptr<_Tp>&) [with _Yp = database::IrradianceProfileDb; = ]? /usr/include/odb/tr1/pointer-traits.hxx:116:1: required from here /usr/include/c++/10/type_traits:909:52: error: non-constant condition for static assertion 909 | static_assert(std::__is_complete_or_unbounded(__type_identity<_Tp>{}), | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~ /usr/include/c++/10/type_traits:909: confused by earlier errors, bailing out My development environment is as follows: - OS: Ubuntu 22.04.4 LTS - CMake version: 3.22.1 - Ninja version: 1.10.1 - GCC version: 11.4.0 - ODB version: 2.4.0 Could you please advise if `std::weak_ptr` can be used to declare ODB classes with bidirectional relationships and how to avoid the above compilation error? Thank you so much for your help. Best regards... ---- Sean Wang (Xuewen Wang), Beijing, China. From boris at codesynthesis.com Tue Aug 13 10:51:21 2024 From: boris at codesynthesis.com (Boris Kolpackov) Date: Tue Aug 13 10:50:55 2024 Subject: [odb-users] Unresolved symbol - ODB 2.5.0-b.27 - PostgreSQL In-Reply-To: References: Message-ID: Lloyd writes: > I am trying out ODB 2.5 with PostgreSQL. When I link the application, I am > getting a link error. > > unresolved external symbol "public: static enum > odb::pgsql::details::endian_traits::endian const > odb::pgsql::details::endian_traits::host_endian" > > I am using ODB in shared mode by setting compiler definition "LIBODB_SHARED" I assume this is Windows. Try also adding LIBODB_PGSQL_SHARED. From lloydkl.tech at gmail.com Wed Aug 14 02:59:51 2024 From: lloydkl.tech at gmail.com (Lloyd) Date: Wed Aug 14 03:03:23 2024 Subject: [odb-users] Unresolved symbol - ODB 2.5.0-b.27 - PostgreSQL In-Reply-To: References: Message-ID: On Tue, Aug 13, 2024 at 8:20?PM Boris Kolpackov wrote: > Lloyd writes: > > > I am trying out ODB 2.5 with PostgreSQL. When I link the application, I > am > > getting a link error. > > > > unresolved external symbol "public: static enum > > odb::pgsql::details::endian_traits::endian const > > odb::pgsql::details::endian_traits::host_endian" > > > > I am using ODB in shared mode by setting compiler definition > "LIBODB_SHARED" > > I assume this is Windows. Try also adding LIBODB_PGSQL_SHARED. > Thanks a lot, this helped to resolve the error. Yes, this is Windows. From boris at codesynthesis.com Thu Aug 15 01:51:12 2024 From: boris at codesynthesis.com (Boris Kolpackov) Date: Thu Aug 15 01:50:45 2024 Subject: [odb-users] Issue with std::weak_ptr in Bidirectional Relationship with ODB Classes In-Reply-To: References: Message-ID: xuewen wang writes: > /usr/include/c++/10/bits/shared_ptr.h:707:30: required by substitution of > ?template > std::weak_ptr::weak_ptr(const > std::weak_ptr<_Tp>&) [with _Yp = database::IrradianceProfileDb; > = ]? This suggests that the definition is needed when calling the weak_ptr's copy constructor (and likely other functions, like the destructor). I suggest that you try to move definitions of all your functions in the two classes after both are defined. Something along these lines: class B; class A { std::weak_ptr b; A (const A&); }; class B { std::shared_ptr b; }; inline A::A (const A&) : ... { } If you still cannot make it work, please provide a minimal but complete reproducer (header file plus the ODB compiler command line to compile it). From javier.gutierrez at web.de Tue Aug 20 09:52:48 2024 From: javier.gutierrez at web.de (Javier Gutierrez) Date: Tue Aug 20 09:53:08 2024 Subject: [odb-users] Looking for a database::update_query() Message-ID: <015a01daf308$3e873ff0$bb95bfd0$@web.de> Hi Boris, I again am in the need to run an UPDATE using a query. For such cases in my current code I use native SQL queries for each of the possible databases. This becomes difficult to test and maintain. I was wondering if there is a way in ODB to do this, similar to how database::erase_query() works? Thanks in advance. Best regards, Javier Gutierrez From boris at codesynthesis.com Thu Aug 22 04:35:08 2024 From: boris at codesynthesis.com (Boris Kolpackov) Date: Thu Aug 22 04:34:38 2024 Subject: [odb-users] Looking for a database::update_query() In-Reply-To: <015a01daf308$3e873ff0$bb95bfd0$@web.de> References: <015a01daf308$3e873ff0$bb95bfd0$@web.de> Message-ID: Javier Gutierrez writes: > I again am in the need to run an UPDATE using a query. > > For such cases in my current code I use native SQL queries for each of the > possible databases. > This becomes difficult to test and maintain. > > I was wondering if there is a way in ODB to do this, similar to how > database::erase_query() works? No, currently there is no way other than with native queries. With regards to erase_query(), that was easy to support since it only needed the WHERE clause which we could reuse as-is from the SELECT queries. With UPDATE we would also need to handle the SET clause which currently has no analogs in ODB and so we would need to make something from scratch. It is likely doable and I agree it would be useful to have (we use native queries for this ourselves in a few places), but it's not going to be easy and is not a high priority, unless someone wants to fund this work. From lloydkl.tech at gmail.com Fri Aug 23 02:51:26 2024 From: lloydkl.tech at gmail.com (Lloyd) Date: Fri Aug 23 02:55:09 2024 Subject: [odb-users] ODB 2.5.0-b.27 - MSVC 2019 - C++17 /permissive- flag error Message-ID: Hi, I am trying out a minimal Qt 6.7 application which is making use of ODB 2.5. Qt 6.7 requires C++17 as the minimum. On Windows, along with C++17 it also needs to set MSVC compiler flags "/Zc:__cplusplus" and "/permissive-". When I pass "/permissive-" to the compiler, I am seeing a lot of compiler errors similar to error C2955: 'odb::query': use of class template requires template argument list ... error C2039: 'User': is not a member of 'odb::query' ... etc... These errors are not related to Qt. If I write a minimal ODB application with the compiler flag "/permissive-" passed, this error can be reproduced. If the "/permissive-" option is removed, there are no compiler errors. May I know how to fix this? PS: I am using CMake, so the compiler specific settings are passed as: set (CMAKE_CXX_STANDARD 17) set (CMAKE_CXX_STANDARD_REQUIRED ON) add_compile_options(/Zc:__cplusplus) add_compile_options(/permissive-) https://learn.microsoft.com/en-us/cpp/build/reference/permissive-standards-conformance?view=msvc-170 Thanks a lot in advance From boris at codesynthesis.com Mon Aug 26 07:48:44 2024 From: boris at codesynthesis.com (Boris Kolpackov) Date: Mon Aug 26 07:48:12 2024 Subject: [odb-users] ODB 2.5.0-b.27 - MSVC 2019 - C++17 /permissive- flag error In-Reply-To: References: Message-ID: Lloyd writes: > I am trying out a minimal Qt 6.7 application which is making use of ODB > 2.5. Qt 6.7 requires C++17 as the minimum. On Windows, along with C++17 it > also needs to set MSVC compiler flags "/Zc:__cplusplus" and > "/permissive-". Hm, I don't believe /permissive- is required by Qt. We build it without this flag without any problems. > When I pass "/permissive-" to the compiler, I am seeing a lot of > compiler errors similar to > > error C2955: 'odb::query': use of class template requires template argument > list > ... > error C2039: 'User': is not a member of 'odb::query' > ... > > If I write a minimal ODB application with the compiler flag > "/permissive-" passed, this error can be reproduced. If the > "/permissive-" option is removed, there are no compiler errors. > May I know how to fix this? In our experience (admittedly from a few years ago, but then you don't specify the version of MSVC either), the /permissive- flag broke a lot of perfectly valid code due to the MSVC compiler bugs. But if you can provide the complete diagnostics that you are getting (including file names and locations), I can take a look to at least get a sense if it's something real or not.