From finjulhich at gmail.com Sun Jun 9 18:36:53 2024 From: finjulhich at gmail.com (MM) Date: Tue Jun 25 04:50:04 2024 Subject: [odb-users] build2 odb postgresql 15 to 16 Message-ID: I see these versions of rpms installed on Fedora for the client devel psql libraries libpq-devel.x86_64 15.3-1.fc39 postgresql16-private-devel 16.1-2.fc39 It looks like the name of the package hosting the client devel headers and libs changed. Can I build odb pgsql with either of those 2? Rds From me at raphieps.com Fri Jun 21 16:50:10 2024 From: me at raphieps.com (Raphael Palefsky-Smith) Date: Tue Jun 25 04:50:04 2024 Subject: [odb-users] Postgres Bulk Operations on Windows? Message-ID: Hi! I've been interested in trying the Postgres bulk operations feature in the 2.5.0 beta, and have gotten the beta version building smoothly. There's one snag - getting linker errors for the actual update/delete/insert code: unresolved external symbol "public: unsigned __int64 __cdecl odb::pgsql::update_statement::execute(unsigned __int64,struct odb::multiple_exceptions &)" After digging into the source, I'm seeing several instances of this check, which implies the libpq pipelining (and therefore pgsql bulk) is unsupported on Windows: #if defined(LIBPQ_HAS_PIPELINING) && !defined(_WIN32) Is this something that might be supported later, or is there something in the Windows networking stack that makes this impossible? Thanks either way! From boris at codesynthesis.com Tue Jun 25 04:41:42 2024 From: boris at codesynthesis.com (Boris Kolpackov) Date: Tue Jun 25 04:50:05 2024 Subject: [odb-users] ODB 2.5.0-b.27 release candidate published Message-ID: We have published ODB 2.5.0-b.27 to cppget.org which we are treating as a release candidate. If there are no major issues, we aim to release 2.5.0 final in a few months. Note that this version contains quite a few fixes compared to the previous 2.5.0-b.25 version, so please test it for any regressions. In particular, we had to add declarations of explicit template instantiations in the generated code in order to make recent Clang versions happy. Other noteworthy changes and developments: * Support for GCC 14. * We have reorganized the ODB git repositories by merging (with history) individual repositories into one: https://git.codesynthesis.com/cgit/odb/odb/tree/ * We have ported ODB tests and examples to build2. * We now have complete CI coverage for all five databases, Qt5/Qt6/Boost profiles, and single/multi-database modes across all the major platforms and compilers. In total, all these combinations produce almost a thousand distinct build configurations. Note that the tests/examples are currently not published to cppget.org due to a backwards-compatibility bug in build2 0.16.0. But they will be published before or during the 2.5.0 release. Also note that due to the above-mentioned bug in build2, we strongly recommend that you upgrade from 0.16.0 (or earlier) to the latest build2 0.17.0. In particular, if you continue using 0.16.0, you may not be able to consume packages from cppget.org in the near future. For details, see: https://build2.org/release/0.17.0.xhtml To install or upgrade to ODB 2.5.0-b.27 see the installation instructions: https://codesynthesis.com/products/odb/doc/install-build2.xhtml A note to Mac OS users: ODB with Homebrew GCC 14 appears to work correctly. From sunny.sun at ringcentral.com Tue Jun 18 22:21:09 2024 From: sunny.sun at ringcentral.com (Sunny Sun) Date: Tue Jun 25 04:54:11 2024 Subject: [odb-users] Mutex may not be released Re: It was blocked by odb::sqlite::connection_pool_factory::create() In-Reply-To: References: Message-ID: Hi?I noticed the following code snippet? signal () { if (waiters_ > signals_) { if (signals_++ == 0) { if (SetEvent (event_) == 0) throw win32_exception (); } } mutex_.unlock (); } If it throw win32_exception(), it will not unlock mutex. It?s not reasonable. Looking forward to your reply. Thank you very much. On May 27, 2024, at 17:38, Sunny Sun wrote: Hi Boris, We encountered a problem that was the thread was blocked by odb::sqlite::connection_pool_factory::create(). We created a new db file with odb::sqlite::database, then we call db->schema_version() which will call odb::sqlite::connection_pool_factory::create(). But it was blocked. What I want to know is: 1. What will cause this block? 2. How to avoid this block? 2. Is there any approach to recover from the block? We use ODB 2.4.0 and sqlite. If you need more information, please let me know. Thank you very much. From boris at codesynthesis.com Tue Jun 25 05:27:46 2024 From: boris at codesynthesis.com (Boris Kolpackov) Date: Tue Jun 25 05:27:32 2024 Subject: [odb-users] Postgres Bulk Operations on Windows? In-Reply-To: References: Message-ID: 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 boris at codesynthesis.com Tue Jun 25 05:32:01 2024 From: boris at codesynthesis.com (Boris Kolpackov) Date: Tue Jun 25 05:31:46 2024 Subject: [odb-users] build2 odb postgresql 15 to 16 In-Reply-To: References: Message-ID: MM writes: > I see these versions of rpms installed on Fedora for the client devel psql > libraries > > libpq-devel.x86_64 15.3-1.fc39 > postgresql16-private-devel 16.1-2.fc39 You will need to provide more details (who installs them, what's the command line, etc). But: - libpq-devel is the PostgreSQL client library (libpq). - postgresql16-private-devel (I am guessing) is some server development files (maybe extensions). Generally, with PostgreSQL, you are able to use different versions of the client library and servers. > Can I build odb pgsql with either of those 2? No, you can only build libodb-pgsql with libpq-devel. From boris at codesynthesis.com Tue Jun 25 06:39:52 2024 From: boris at codesynthesis.com (Boris Kolpackov) Date: Tue Jun 25 06:39:39 2024 Subject: [odb-users] Mutex may not be released Re: It was blocked by odb::sqlite::connection_pool_factory::create() In-Reply-To: References: Message-ID: Sunny Sun writes: > We encountered a problem that was the thread was blocked by > odb::sqlite::connection_pool_factory::create(). > > We created a new db file with odb::sqlite::database, then we call > db->schema_version() which will call > odb::sqlite::connection_pool_factory::create(). Are you sure it is connection_pool_factory::create() that is blocking and not connection_pool_factory::connect()? connection_pool_factory::create() essentially calls sqlite3_open_v2() and then executes a couple of PRAGMA statements, which I don't see how they can block, at least not at the ODB level. Perhaps the file is locked on the filesystem level or some such? > I noticed the following code snippet? > > signal () > { > > > > if (waiters_ > signals_) > { > if (signals_++ == 0) > { > if (SetEvent (event_) == 0) > throw win32_exception (); > } > } > > > mutex_.unlock (); > } > > > If it throw win32_exception(), it will not unlock mutex. If the Win32 SetEvent() function fails, it means there is something fundamentally broken with synchronization primitives in the process and whether you unlock a mutex or not doesn't really matter. Are you observing this exception being thrown in your case? Also, I don't see how it is connected to the create() function above. Can you explain how this code is relevant to the problem at hand? From boris at codesynthesis.com Tue Jun 25 06:51:48 2024 From: boris at codesynthesis.com (Boris Kolpackov) Date: Tue Jun 25 06:51:34 2024 Subject: [odb-users] MSVC19 link error: LNK2001: Unresolved external symbol In-Reply-To: <344ee50b-56e7-4e53-954c-4f84443422e1@cetoni.de> References: <344ee50b-56e7-4e53-954c-4f84443422e1@cetoni.de> Message-ID: CETONI GmbH - Uwe Kindler writes: > error LNK2001: Unresolved external symbol ""struct odb::details::share > odb::details::shared" (?shared@details@odb@@3Ushare@12@A)" > > The symbol is declared in odb/details/shared_ptr/base.hxx: > > > extern LIBODB_EXPORT share shared; I believe adding -DLIBODB_SHARED to your MSVC compiler command line when building your application (and generated code) will help. For background, without either LIBODB_SHARED or LIBODB_STATIC we fall back to automatic symbol importing but in MSVC it only works for functions, not global variables (this is the reason why you only see this unresolved symbol rather than many -- the rest are all functions and that works). From sunny.sun at ringcentral.com Thu Jun 27 22:53:50 2024 From: sunny.sun at ringcentral.com (Sunny Sun) Date: Fri Jun 28 02:10:23 2024 Subject: [odb-users] Mutex may not be released Re: It was blocked by odb::sqlite::connection_pool_factory::create() In-Reply-To: References: Message-ID: <3AEBBBF8-8875-45F9-83B8-7A909E000708@ringcentral.com> If the Win32 SetEvent() function fails, it means there is something fundamentally broken with synchronization primitives in the process and whether you unlock a mutex or not doesn't really matter. Yes, we really got win32_exception() when call odb::sqlite::connection(). Here is the steps? 1. Create odb. auto db = std::shared_ptr(new odb::sqlite::database(dbFile, SQLITE_OPEN_READWRITE | SQLITE_OPEN_CREATE | SQLITE_OPEN_SHAREDCACHE | SQLITE_OPEN_FULLMUTEX, false, "", poolInTransP)); 2. Init schema 3. Do task in transaction { odb::session commitDataSession; auto connection = db->connection(); odb::transaction t (connection->begin ()); task(); t.commit (); } The above code throw win32_exception(), but not sure which line throw it. We got 2 times win32_exception(). 4. It was blocked by odb::sqlite::connection_pool_factory::create(). It really was blocked by odb::sqlite::connection_pool_factory::create(). odb::sqlite::connection_pool_factory::create() may be called by auto connection = db->connection(); 2which will call connection_pool_factory::connect(). At first we also suspected that the db file was damaged or occupied, and we tested it. It may lead to other problems, but not the same with this issue. This issue only happened once, and we did not find out the root cause. We only find this issue same began with the win32_exception(). Any help will be appreciated. Thank you very much. On Jun 25, 2024, at 18:39, Boris Kolpackov wrote: [EXTERNAL] Sunny Sun writes: We encountered a problem that was the thread was blocked by odb::sqlite::connection_pool_factory::create(). We created a new db file with odb::sqlite::database, then we call db->schema_version() which will call odb::sqlite::connection_pool_factory::create(). Are you sure it is connection_pool_factory::create() that is blocking and not connection_pool_factory::connect()? connection_pool_factory::create() essentially calls sqlite3_open_v2() and then executes a couple of PRAGMA statements, which I don't see how they can block, at least not at the ODB level. Perhaps the file is locked on the filesystem level or some such? I noticed the following code snippet? signal () { if (waiters_ > signals_) { if (signals_++ == 0) { if (SetEvent (event_) == 0) throw win32_exception (); } } mutex_.unlock (); } If it throw win32_exception(), it will not unlock mutex. If the Win32 SetEvent() function fails, it means there is something fundamentally broken with synchronization primitives in the process and whether you unlock a mutex or not doesn't really matter. Are you observing this exception being thrown in your case? Also, I don't see how it is connected to the create() function above. Can you explain how this code is relevant to the problem at hand? From finjulhich at gmail.com Sat Jun 29 10:56:16 2024 From: finjulhich at gmail.com (MM) Date: Sat Jun 29 10:56:50 2024 Subject: [odb-users] make integer field autoincrement when it wasn't Message-ID: Hi with sqlite, and class having a uint64_t as an id #pragma db member(myclass::id) id I didn't have auto. But when I add it, odb errors with: "error: changing object id auto kind in an existing class is not supported info: consider re-implementing this change by adding a new class with the desired object id auto kind, migrating the data, and deleting the old class" I have the pragma for model version (A,B) at the moment, Can I manually hack around this? ie I edit the old xmls? and then edit the database myself?