From ali at notatether.com Sun Jan 16 08:53:05 2022 From: ali at notatether.com (Ali Sherief) Date: Mon Jan 17 10:32:43 2022 Subject: [odb-users] Integrating ODB into an automake project Message-ID: Hi, I have wrote a fairly large project which utilizes ODB. There are about a dozen or so files that need to be preprocessed with the ODB compiler before the results can be compiled with the rest of the project. My project's build system is a standard ./autogen.sh && ./configure && make process. I am wondering at which stage of the build process I should place the ODB compilation commands. My gut feeling tells me in the ./autogen.sh script is the most logical place, but then again, I would like it to be compiled alongside the rest of the files during the `make` process. Kind Regards, Ali Sherief notatether.com From boris at codesynthesis.com Mon Jan 17 10:42:33 2022 From: boris at codesynthesis.com (Boris Kolpackov) Date: Mon Jan 17 10:39:45 2022 Subject: [odb-users] Integrating ODB into an automake project In-Reply-To: References: Message-ID: Ali Sherief writes: > My project's build system is a standard ./autogen.sh && ./configure && make > process. I am wondering at which stage of the build process I should place > the ODB compilation commands. My gut feeling tells me in the ./autogen.sh > script is the most logical place, but then again, I would like it to be > compiled alongside the rest of the files during the `make` process. Automake has some support for auto-generated source code. Try searching the web for "automake generated source files" -- the first couple of results look quite promising (includs a link to an example from Automake documentation). From per.edin at sequence-point.se Mon Jan 17 10:43:02 2022 From: per.edin at sequence-point.se (Per Edin) Date: Mon Jan 17 10:45:57 2022 Subject: [odb-users] Integrating ODB into an automake project In-Reply-To: References: Message-ID: Hi! I'm using build2 for building my projects, but I think the same applies to whatever build system you're using. Don't "auto-generate" the files during build, instead, create a script that runs ODB on whatever files are required, then commit those files as part of the source tree. This allows others to build the project without requiring the ODB compiler unless they also have to modify the schema. In addition, ODB generates a changelog of the schema to enable migrations, this file needs to be committed as well, and could change as a result of simply building the project if ODB is run automatically. In conclusion, I would advise against auto-running ODB during builds. I did try and gave up on it. See https://git.build2.org/cgit/bdep/tree/bdep/odb.sh for an example (part of bdep, part of build2). Kind regards, Per Edin On Mon, Jan 17, 2022 at 4:35 PM Ali Sherief wrote: > Hi, > > I have wrote a fairly large project which utilizes ODB. There are about a > dozen or so files that need to be preprocessed with the ODB compiler before > the results can be compiled with the rest of the project. > > My project's build system is a standard ./autogen.sh && ./configure && > make process. I am wondering at which stage of the build process I should > place the ODB compilation commands. My gut feeling tells me in the > ./autogen.sh script is the most logical place, but then again, I would like > it to be compiled alongside the rest of the files during the `make` process. > > Kind Regards, > Ali Sherief > notatether.com From phillip.shelton at cardno.com.au Tue Jan 18 04:44:25 2022 From: phillip.shelton at cardno.com.au (Phillip Shelton) Date: Wed Jan 19 11:01:44 2022 Subject: [odb-users] cmake build recipe Message-ID: Hello, I was wondering where there any plans to create and ship a cmake based method for compiling libodb and libobd-sqlilte? Phillip Shelton SENIOR TRANSPORT MODELLER CARDNO [cid:image001.png@01D80CA3.C8F8C9E0] Phone +61 7 3369 9822 Direct +61 7 3877 6991 Address Level 11, 515 St Paul's Terrace, Fortitude Valley, Queensland 4006 Australia Postal Locked Bag 4006, Fortitude Valley 4006 Email phillip.shelton@cardno.com.au Web www.cardno.com CONNECT WITH CARDNO [cid:image002.png@01D80CA3.C8F8C9E0] [cid:image003.png@01D80CA3.C8F8C9E0] [cid:image004.png@01D80CA3.C8F8C9E0] [cid:image005.png@01D80CA3.C8F8C9E0] [Reconciliation Action Plan Icon] Cardno acknowledges the Traditional Owners of the land upon which we live and work and pay our respects to their Elders past, present and emerging - learn more. Cardno's management systems are certified to ISO9001 (quality) and AS/NZS4801/OHSAS18001 (occupational health and safety) This email and its attachments may contain confidential and/or privileged information for the sole use of the intended recipient(s). All electronically supplied data must be checked against an applicable hardcopy version which shall be the only document which Cardno warrants accuracy. If you are not the intended recipient, any use, distribution or copying of the information contained in this email and its attachments is strictly prohibited. If you have received this email in error, please email the sender by replying to this message and immediately delete and destroy any copies of this email and any attachments. The views or opinions expressed are the author's own and may not reflect the views or opinions of Cardno. -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 2818 bytes Desc: image001.png Url : https://codesynthesis.com/pipermail/odb-users/attachments/20220118/62788447/image001.png -------------- next part -------------- A non-text attachment was scrubbed... Name: image002.png Type: image/png Size: 258 bytes Desc: image002.png Url : https://codesynthesis.com/pipermail/odb-users/attachments/20220118/62788447/image002.png -------------- next part -------------- A non-text attachment was scrubbed... Name: image003.png Type: image/png Size: 275 bytes Desc: image003.png Url : https://codesynthesis.com/pipermail/odb-users/attachments/20220118/62788447/image003.png -------------- next part -------------- A non-text attachment was scrubbed... Name: image004.png Type: image/png Size: 251 bytes Desc: image004.png Url : https://codesynthesis.com/pipermail/odb-users/attachments/20220118/62788447/image004.png -------------- next part -------------- A non-text attachment was scrubbed... Name: image005.png Type: image/png Size: 1166 bytes Desc: image005.png Url : https://codesynthesis.com/pipermail/odb-users/attachments/20220118/62788447/image005.png -------------- next part -------------- A non-text attachment was scrubbed... Name: image006.png Type: image/png Size: 3655 bytes Desc: image006.png Url : https://codesynthesis.com/pipermail/odb-users/attachments/20220118/62788447/image006.png From boris at codesynthesis.com Thu Jan 20 08:03:53 2022 From: boris at codesynthesis.com (Boris Kolpackov) Date: Thu Jan 20 08:01:05 2022 Subject: [odb-users] Integrating ODB into an automake project In-Reply-To: References: Message-ID: Per Edin writes: > I'm using build2 for building my projects, but I think the same applies to > whatever build system you're using. > > Don't "auto-generate" the files during build, instead, create a script that > runs ODB on whatever files are required, then commit those files as part of > the source tree. This allows others to build the project without requiring > the ODB compiler unless they also have to modify the schema. > > In addition, ODB generates a changelog of the schema to enable migrations, > this file needs to be committed as well, and could change as a result of > simply building the project if ODB is run automatically. > > In conclusion, I would advise against auto-running ODB during builds. I did > try and gave up on it. > > See https://git.build2.org/cgit/bdep/tree/bdep/odb.sh for an example (part > of bdep, part of build2). While the challenges you list are real, I don't believe a manually-run script is a solution we should settle for(1). In fact, one of the main reasons for build2's existence is proper support for auto-generated source code and with the latest release we've come pretty far: https://build2.org/build2-toolchain/doc/build2-toolchain-intro.xhtml#guide-build-time-linked https://build2.org/release/0.13.0.xhtml#adhoc-recipe https://build2.org/release/0.14.0.xhtml#adhoc-rules The only part that is still missing is the header dependency extraction (which would be needed for the ODB compilation recipe to detect changes in the included headers) and that is already implemented and coming in the next release (we will also need to expose the -M* option family in the ODB compiler). We also have a solution to this problem: > This allows others to build the project without requiring the ODB > compiler unless they also have to modify the schema. In `build2` we have a notion of the "development build": https://build2.org/release/0.14.0.xhtml#develop So you can commit the pre-generated source code into the repository and only enable its recompilation in the development build. You can see an example of this technique in CLI: https://git.codesynthesis.com/cgit/cli/cli/tree/cli/cli/buildfile#n32 Note that the one part that is still missing for this to work perfectly is support for conditional dependencies in build2 (you would want the dependency on the ODB compiler to be only enabled in the development build). This is also coming in the next release. Let me know if you decide to give this a try and run into any issues. (1) We do in build2 due to the chicken-and-egg problem, but even then we plan to get rid of it soon. From boris at codesynthesis.com Thu Jan 20 08:12:38 2022 From: boris at codesynthesis.com (Boris Kolpackov) Date: Thu Jan 20 08:09:47 2022 Subject: [odb-users] cmake build recipe In-Reply-To: References: Message-ID: Phillip Shelton writes: > I was wondering where there any plans to create and ship a cmake > based method for compiling libodb and libobd-sqlilte? No plans that I am aware of. ODB "upstream" is moving to a build2- based building/packaging in the upcoming release: https://codesynthesis.com/products/odb/doc/install-build2.xhtml Note that you should be able to consume the result of this build in a CMake-based project. From finjulhich at gmail.com Sun Jan 23 09:33:41 2022 From: finjulhich at gmail.com (MM) Date: Sun Jan 23 09:31:07 2022 Subject: [odb-users] c++17,20,23 and sqlite Message-ID: Hello, I need to hold the content of a custom layout file in a cell, about 30 kbytes. I have a 1-row table where I store static data. 1 of the columns would hold the content of the file. First, I'm not sure what C++ type to use for that file. I need to store the content, not the file path. The first thing that springs to mind is that I like the std::byte type. Would a std::basic_string work? Or a std::vector? What type would have a natural mapping in sqlite? Rds, MM From boris at codesynthesis.com Mon Jan 24 08:11:26 2022 From: boris at codesynthesis.com (Boris Kolpackov) Date: Mon Jan 24 08:08:33 2022 Subject: [odb-users] c++17,20,23 and sqlite In-Reply-To: References: Message-ID: MM writes: > Hello, > I need to hold the content of a custom layout file in a cell, about 30 > kbytes. > I have a 1-row table where I store static data. 1 of the columns would hold > the content of the file. > > First, I'm not sure what C++ type to use for that file. I need to store the > content, not the file path. > The first thing that springs to mind is that I like the std::byte type. > Would a std::basic_string work? Or a std::vector? > What type would have a natural mapping in sqlite? You can read more about the supported C++ to SQLite type mapping in Section 18.1, "SQLite Type Mapping" of the ODB manual: https://codesynthesis.com/products/odb/doc/manual.xhtml#18.1 Specifically, Section 18.1.2, "Binary Type Mapping" talks about storing BLOB (binary large object). std::byte is most likely a cute alias for char or unsigned char so std::vectro will probably work out of the box. From per.edin at sequence-point.se Tue Jan 25 04:59:56 2022 From: per.edin at sequence-point.se (Per Edin) Date: Tue Jan 25 08:00:57 2022 Subject: [odb-users] Integrating ODB into an automake project In-Reply-To: References: Message-ID: On Thu, Jan 20, 2022 at 2:04 PM Boris Kolpackov wrote: > > Let me know if you decide to give this a try and run into any issues. > Impressive! I must say. I'll experiment with this and try it out later this week. :) // Per From gatekeeper.mail at gmail.com Wed Jan 26 16:06:50 2022 From: gatekeeper.mail at gmail.com (Andy S) Date: Thu Jan 27 09:52:02 2022 Subject: [odb-users] Couldn't find method odb::database::id Message-ID: OS: Debian Bullseye Compiler: g++-9 ODB version: 2.4.0 I have a model class: -- InvType.h: -- #include #include #include #pragma db model version(1, 1) #pragma db object table("invTypes") class InvType { public: InvType() = default;; uint16_t typeID() const { return typeID_; }; void typeID(const uint16_t id_) { typeID_ = id_; }; float basePrice() const { return basePrice_; }; void basePrice(const float basePrice_v) { basePrice_ = basePrice_v; }; private: friend class odb::access; #pragma db id #pragma db not_null #pragma db access(typeID) #pragma db column("typeID") uint16_t typeID_; #pragma db not_null #pragma db default(0) #pragma db access(basePrice) #pragma db column("basePrice") float basePrice_; }; -- end of InvType.h -- which is compiled as: /usr/bin/odb --multi-database dynamic -d common --generate-query --generate-session --generate-schema --generate-prepared --std c++11 --output-dir ./odb_gen --hxx-suffix .hxx --ixx-suffix .ixx --cxx-suffix .cpp --odb-file-suffix common:_odb -I/usr/include ./model/invType/InvType.h The code invoking a query looks like this: -- main.cpp: -- #include #include #include #include #include "model/invType/InvType.h" #include "odb_gen/InvType_odb.hxx" using std::auto_ptr; int main() { auto_ptr db( new odb::mysql::database( "user", "pass", "mydb", "127.0.0.1", 3306 ) ); using std::vector; vector ids({1, 2, 3, 4, 5, 6, 7, 8, 9, 10}); { odb::transaction t(db->begin()); db->execute("SELECT 1", 8); typedef odb::query qry_t; typedef odb::result res_t; qry_t q(qry_t::typeID.in_range(ids.begin(), ids.end())); res_t r( db->query(q) ); for ( const auto it: r ) { std::cout << it.typeID() << ":" << it.basePrice() << std::endl; } } return 0; } -- end of main.cpp -- The code is compiled and linked without errors. When I run this code I receive SIGSEGV Program received signal SIGSEGV, Segmentation fault. odb::access::object_traits_impl::query (db=..., q=...) at ./odb_gen/InvType_odb.ixx:94 94 return function_table[db.id ()]->query (db, q); (gdb) bt #0 odb::access::object_traits_impl::query (db=..., q=...) at ./odb_gen/InvType_odb.ixx:94 #1 0x00005558f78fcd7e in odb::database::query_::call > (db=..., q=...) at /usr/local/include/odb/database.txx:478 #2 0x00005558f78fc52b in odb::database::query (this=0x5558f833e460, q=..., cache=true) at /usr/local/include/odb/database.txx:19 #3 0x00005558f78fb554 in main () at ./main.cpp:35 #4 0x00007fdafc3dad0a in __libc_start_main (main=0x5558f78fb325 , argc=1, argv=0x7ffc0c662778, init=, fini=, rtld_fini=, stack_end=0x7ffc0c662768) at ../csu/libc-start.c:308 #5 0x00005558f78fb26a in _start () (gdb) p db $1 = (odb::database &) @0x5558f833e460: (gdb) p db.id() Couldn't find method odb::database::id (gdb) p db.id_ There is no member named id_. The driver and connection itself works correctly since the transaction has successfully started and `SELECT 1` was executed successfully. The problem is with only ORM models compiled with ODB. Could someone point me on where to dig the problem? From boris at codesynthesis.com Thu Jan 27 10:04:56 2022 From: boris at codesynthesis.com (Boris Kolpackov) Date: Thu Jan 27 10:02:02 2022 Subject: [odb-users] Couldn't find method odb::database::id In-Reply-To: References: Message-ID: Andy S writes: > /usr/bin/odb --multi-database dynamic -d common --generate-query > --generate-session --generate-schema --generate-prepared --std c++11 > --output-dir ./odb_gen --hxx-suffix .hxx --ixx-suffix .ixx --cxx-suffix > .cpp --odb-file-suffix common:_odb -I/usr/include ./model/invType/InvType.h > > [...] > > The code is compiled and linked without errors. When I run this code I > receive SIGSEGV > Program received signal SIGSEGV, Segmentation fault. > odb::access::object_traits_impl::query > (db=..., q=...) at ./odb_gen/InvType_odb.ixx:94 > 94 return function_table[db.id ()]->query (db, q); My guess would be you haven't generated and/or linked into your application the database support code for each concrete database you want to support in the dynamic mode (and, as a result, the corresponding function table entry is NULL and thus SIGSEGV). This is covered in the introduction to Chapter 16, "Multi- Database Support" in the ODB manual. From gatekeeper.mail at gmail.com Thu Jan 27 16:47:20 2022 From: gatekeeper.mail at gmail.com (Andy S) Date: Fri Jan 28 01:44:16 2022 Subject: [odb-users] Couldn't find method odb::database::id In-Reply-To: References: Message-ID: On Thu, Jan 27, 2022 at 10:05 AM Boris Kolpackov wrote: > My guess would be you haven't generated and/or linked into your > application the database support code for each concrete database > you want to support in the dynamic mode (and, as a result, the > corresponding function table entry is NULL and thus SIGSEGV). > This is covered in the introduction to Chapter 16, "Multi- > Database Support" in the ODB manual. > Well, after some messing I've got the point. If the ODB-related code is a static library which is then statically linked into the resulting executable, ODB fails with NULLs-initialized table (despite all the libodb-* libraries are shared-linked into the executable). If I only change the library definition to SHARED in my cmake config the result is: it works. From boris at codesynthesis.com Fri Jan 28 03:10:00 2022 From: boris at codesynthesis.com (Boris Kolpackov) Date: Fri Jan 28 03:07:04 2022 Subject: [odb-users] Couldn't find method odb::database::id In-Reply-To: References: Message-ID: Andy S writes: > If the ODB-related code is a static library which is then statically linked > into the resulting executable, ODB fails with NULLs-initialized table > (despite all the libodb-* libraries are shared-linked into the executable). Yes, that explains it: in the dynamic mode nothing in your application references the generated code for each concrete database. Rather, the generated code registers itself in these function tables. > If I only change the library definition to SHARED in my cmake config the > result is: it works. You can also fix this by linking the static library in the whole archive mode (not sure what's the CMake's incantation, by the GCC options are -Wl,--whole-archive -Wl,--no-whole-archive). From finjulhich at gmail.com Sat Jan 29 14:10:01 2022 From: finjulhich at gmail.com (MM) Date: Sat Jan 29 14:07:24 2022 Subject: [odb-users] c++17,20,23 and sqlite Message-ID: On Mon, 24 Jan 2022 at 13:11, Boris Kolpackov wrote: > MM writes: > > > Hello, > > I need to hold the content of a custom layout file in a cell, about 30 > > kbytes. > > I have a 1-row table where I store static data. 1 of the columns would > hold > > the content of the file. > > > > First, I'm not sure what C++ type to use for that file. I need to store > the > > content, not the file path. > > The first thing that springs to mind is that I like the std::byte type. > > Would a std::basic_string work? Or a std::vector? > > What type would have a natural mapping in sqlite? > > You can read more about the supported C++ to SQLite type mapping > in Section 18.1, "SQLite Type Mapping" of the ODB manual: > > https://codesynthesis.com/products/odb/doc/manual.xhtml#18.1 > > Specifically, Section 18.1.2, "Binary Type Mapping" talks about > storing BLOB (binary large object). std::byte is most likely a > cute alias for char or unsigned char so std::vectro > will probably work out of the box. Without a self-contained case, perhaps a specialisation is not found. .cxx:1408:40: error: no matching function for call to ?odb::sqlite::value_traits, odb::sqlite::id_blob>::set_image(odb::details::buffer&, std::size_t&, bool&, const std::vector&)? 1406 | sqlite::value_traits< | ~~~~~~~~~~~~~~~~~~~~~ 1407 | ::std::vector< ::std::byte >, | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 1408 | sqlite::id_blob >::set_image ( | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^ 1409 | i.data_value, | ~~~~~~~~~~~~~ 1410 | i.data_size, | ~~~~~~~~~~~~ 1411 | is_null, | ~~~~~~~~ 1412 | v); with std::vector it worked on the other hand. odb 2.5.0-b.21 (GCC) 11.2.1 20211203 Regards. From boris at codesynthesis.com Mon Jan 31 09:49:11 2022 From: boris at codesynthesis.com (Boris Kolpackov) Date: Mon Jan 31 09:46:14 2022 Subject: [odb-users] c++17,20,23 and sqlite In-Reply-To: References: Message-ID: MM writes: > Without a self-contained case, perhaps a specialisation is not found. > > error: no matching function for call to > ?odb::sqlite::value_traits, > odb::sqlite::id_blob>::set_image(odb::details::buffer&, std::size_t&, > bool&, const std::vector&)? Yes, turns out std::byte is a lot more involved than a simple alias for char. From GCC 11 cstddef header: enum class byte : unsigned char {}; So, yes, a specialization will be need. Will try to add it at some point.