From boris at codesynthesis.com Mon Mar 1 04:57:45 2021 From: boris at codesynthesis.com (Boris Kolpackov) Date: Mon Mar 1 05:03:58 2021 Subject: [odb-users] Upcoming Repository Certificate Replacement on cppget.org Message-ID: The cppget.org (and stage.build2.org) repository certificates will be replaced with renewed versions on Tue the 9th of Mar 2021 at 12pm UTC. If you are getting ODB via build2 packages[1], then you may need to make changes to your setup if you pass the repository certificate fingerprint to trust, for example, in an automated script that builds ODB (or build2 itself). For details, see: https://build2.org/blog/repo-cert-replacement.xhtml The fingerprints: cppget.org: new: 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 old: 86:BA:D4:DE:2C:87:1A:EE:38:C7:F1:64:7F:65:77:02:15:79:F3:C4:83:C0:AB:5A:EA:F4:F7:8C:1D:63:30:C6 Let me know if you have any questions or concerns. [1] https://codesynthesis.com/products/odb/doc/install-build2.xhtml From specialgunpowder at outlook.com Fri Mar 5 06:13:27 2021 From: specialgunpowder at outlook.com (Special Gunpowder) Date: Fri Mar 5 08:02:18 2021 Subject: [odb-users] Parent/child datamodel and performance Message-ID: Hello, I am hoping to get some advice on how to improve the performance when loading a large number of objects. I'm pretty sure my datamodel is at fault and have the freedom to change it any way I need to, but not sure how best to proceed. I searched but could not find existing questions that address my issue. This is a simplified version of my datamodel with hopefully enough detail to explain the problem: I have a Parent object with two lists of child objects. One child list of DbValueChild objects is implemented as a 'db value' type. The other child list of DbRelChild objects is implemented as a list of 'related' objects. Each DbRelChild also has a list of related objects (DbRelGrandchild). These four classes (simplified) are shown below. It all works; when I load the Parent, I get all the children and grandchildren loaded as well, which is exactly what I need. But it is slow - very slow. When I read one Parent, ODB executes one query to load all the DbValueChild items. But it looks like for the DbRelChild items, a separate query is executed for each DbRelChild and then for each DbRelGrandchild object as well. Loading 1 Parent with 10 DbValueChild children and 50 DbRelChild children takes about 3 seconds. I don't have a specific performance target, but this is way too slow for my needs, since I need to load tens of thousands of Parent objects and as things are now this will take hours. How can this be improved? Do I need to remodel implement all the children as db value types? All advice welcome. Thanks in advance. -SpecialGunpowder class Parent { private: std::vector> _dbValueChildList; std::vector> _dbRelChildList; }; #pragma db member(Parent::_dbRelChildList) value_not_null // ------------------------------------- #pragma db value class DbValueChild { private: unsigned long _id; std::string _name; }; // ------------------------------------- class DbRelChild { private: unsigned long _id; std::vector> _DbRelGrandchildList; }; #pragma db member(DbRelChild::_DbRelGrandchildList) value_null unordered // ------------------------------------- class DbRelGrandchild { private: unsigned long _id; unsigned long _sequence; }; From boris at codesynthesis.com Mon Mar 8 05:58:27 2021 From: boris at codesynthesis.com (Boris Kolpackov) Date: Mon Mar 8 05:58:38 2021 Subject: [odb-users] Parent/child datamodel and performance In-Reply-To: References: Message-ID: Special Gunpowder writes: > How can this be improved? Do you actually need to load all of the RelChild and/or RelGrandchild eagerly? > Do I need to remodel implement all the children as db value types? That would definitely help. Otherwise, if you don't need all the RelChild/RelGrandchild loaded, then you can consider lazy loading (see lazy_ptr in documentation). Even if you do need to load them all eagerly, you can most likely optimize things by switching to lazy_ptr and then loading all the related objects with a single query using object loading views. Finally, if RelChild/RelGrandchild can be shared by multiple objects, make sure that you use session to avoid loading the same objects repeatedly. From specialgunpowder at outlook.com Mon Mar 8 12:14:55 2021 From: specialgunpowder at outlook.com (Special Gunpowder) Date: Tue Mar 9 07:47:03 2021 Subject: [odb-users] Parent/child datamodel and performance In-Reply-To: References: , Message-ID: Thanks a lot for the feedback and advice Boris. Yes, I do need all the data loaded eagerly. No, there is no sharing of child/grandchild records. I was not aware of the ability to load all related objects with a single query using object loading views - I will read the manual chapter on views and see if that might work. If there is an example that illustrates that approach, please let me know. If that is not an option, I will remodel and make all the children db value types. I think I only modelled the parent/children as related entities because with db value types I cannot have containers of containers so no grandchildren... but I think I can work around that. Thanks again! ________________________________ From: Boris Kolpackov Sent: Monday, March 8, 2021 10:58 AM To: Special Gunpowder Cc: odb-users@codesynthesis.com Subject: Re: [odb-users] Parent/child datamodel and performance Special Gunpowder writes: > How can this be improved? Do you actually need to load all of the RelChild and/or RelGrandchild eagerly? > Do I need to remodel implement all the children as db value types? That would definitely help. Otherwise, if you don't need all the RelChild/RelGrandchild loaded, then you can consider lazy loading (see lazy_ptr in documentation). Even if you do need to load them all eagerly, you can most likely optimize things by switching to lazy_ptr and then loading all the related objects with a single query using object loading views. Finally, if RelChild/RelGrandchild can be shared by multiple objects, make sure that you use session to avoid loading the same objects repeatedly. From emilio.garcia at ieec.cat Mon Mar 15 12:12:24 2021 From: emilio.garcia at ieec.cat (Emilio Garcia) Date: Mon Mar 15 12:12:38 2021 Subject: [odb-users] Release frequency and public repository Message-ID:

Hi all,

I've recently discovered the ODB software but I would like to answer the following questions before going further:

  • Is planned to move the source code to GitHub or so in order to be able to track the development and to fill issues?
  • How often is a release made?

Thanks in advance,

--

Emilio Garcia Quintana
emilio.garcia@ieec.cat
Software Engineer
Tel: +34 93 737 97 88
Ext: 933002

Campus UAB, Carrer de Can Magrans, s/n
08193 Cerdanyola del Vall?s

IEEC logo

Institute of Space Studies of Catalonia (IEEC)
http://www.ieec.cat?

From boris at codesynthesis.com Tue Mar 16 08:25:49 2021 From: boris at codesynthesis.com (Boris Kolpackov) Date: Tue Mar 16 08:25:58 2021 Subject: [odb-users] Release frequency and public repository In-Reply-To: References: Message-ID: Emilio Garcia writes: >
  • Is planned to move the source code to GitHub or so in order to > be able to track the development and to fill issues?
    • There are no plans to move the development to GitHub but we may provide a mirror there in the future. >
  • How often is a release made?
    • We are moving towards more of a continuous delivery model (though there will still be "official" releases at some points). You can read more about it here: https://codesynthesis.com/products/odb/doc/install-build2.xhtml From youngsunhere at gmail.com Wed Mar 24 09:55:13 2021 From: youngsunhere at gmail.com (ys C) Date: Wed Mar 24 09:55:34 2021 Subject: [odb-users] segmentation error on the hello example(w.r.t auto_ptr db (new odb::mysql::database (argc, argv));) Message-ID: Hi, I was able to compile the driver executable, with the following command in README, *c++ -c person-odb.cxx* *c++ -DDATABASE_MYSQL -c driver.cxx* *c++ -o driver driver.o person-odb.o -lodb-mysql -lodb* I also created the schema by, mysql --user=root --database=cpp_test < person.sql I checked that cpp_test was created with the people table. However when driver is run as below, I get segmentation error. *./driver --user root --database cpp_test* My debugging only got so far as finding out that it was due to L 62 in *database.hxx* *auto_ptr db (new odb::mysql::database (argc, argv));)* I am running on Ubuntu 18.04, using mysql for db, as mentioned. Could this be installation issue? Thanks for the help! -- Best regards, Youngsun Cho From youngsunhere at gmail.com Wed Mar 24 09:56:44 2021 From: youngsunhere at gmail.com (ys C) Date: Wed Mar 24 09:57:04 2021 Subject: [odb-users] Re: segmentation error on the hello example(w.r.t auto_ptr db (new odb::mysql::database (argc, argv));) In-Reply-To: References: Message-ID: *auto_ptr db (new odb::mysql::database (argc, argv));)* *->Sorry, please ignore the extra ) at the end, it was my typo while writing this email!.* On Wed, Mar 24, 2021 at 10:55 PM ys C wrote: > Hi, > > I was able to compile the driver executable, with the following command in > README, > > > *c++ -c person-odb.cxx* > *c++ -DDATABASE_MYSQL -c driver.cxx* > *c++ -o driver driver.o person-odb.o -lodb-mysql -lodb* > > I also created the schema by, > mysql --user=root --database=cpp_test < person.sql > I checked that cpp_test was created with the people table. > > However when driver is run as below, I get segmentation error. > > *./driver --user root --database cpp_test* > > > My debugging only got so far as finding out that it was due to L 62 in > *database.hxx* > > > *auto_ptr db (new odb::mysql::database (argc, argv));)* > > I am running on Ubuntu 18.04, using mysql for db, as mentioned. > Could this be installation issue? > > Thanks for the help! > > -- > Best regards, > Youngsun Cho > -- Best regards, Youngsun Cho From haupt.wolfgang at gmail.com Wed Mar 24 11:19:17 2021 From: haupt.wolfgang at gmail.com (Wolfgang Haupt) Date: Wed Mar 24 11:19:54 2021 Subject: [odb-users] Errors building with ccache Message-ID: Hi guys, I've seen a problem compiling the odb compiler with ccache. Following the guide to build 2.5 beta with build2 from the official docs, I get issues similar to what is described here: https://bugs.gentoo.org/753173 It's not 100% a blocker for me, as I can just remove ccache from my pipeline, but I want to bring it to your attention in case you want to work on a fix. Let me know if you need/want more details. Best Regards, Wolfgang From PRAJ at beckman.com Wed Mar 24 12:38:59 2021 From: PRAJ at beckman.com (Raj, Phani) Date: Thu Mar 25 08:21:04 2021 Subject: [odb-users] Querying with native SQL Statements Message-ID: Dear Team, Is there a possibility of querying data from the SQL Server using ODB::ORM with native SQL statements. My App generates SQL Statements that has to be executed thru' the db->query method. Is it possible to do so. Please revert back on this. Thanks Phaniraj Please be advised that this email may contain confidential information. If you are not the intended recipient, please notify us by email by replying to the sender and delete this message. The sender disclaims that the content of this email constitutes an offer to enter into, or the acceptance of, any agreement; provided that the foregoing does not invalidate the binding effect of any digital or other electronic reproduction of a manual signature that is included in any attachment. -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.gif Type: image/gif Size: 1117 bytes Desc: image001.gif Url : https://codesynthesis.com/pipermail/odb-users/attachments/20210324/32fa6838/image001.gif From boris at codesynthesis.com Thu Mar 25 08:39:20 2021 From: boris at codesynthesis.com (Boris Kolpackov) Date: Thu Mar 25 08:39:22 2021 Subject: [odb-users] Querying with native SQL Statements In-Reply-To: References: Message-ID: Raj, Phani writes: > Is there a possibility of querying data from the SQL Server using > ODB::ORM with native SQL statements. My App generates SQL Statements > that has to be executed thru' the db->query method. Is it possible to > do so. Yes, see "Executing Native SQL Statements": https://codesynthesis.com/products/odb/doc/manual.xhtml#3.12 As well as "Native Views": https://codesynthesis.com/products/odb/doc/manual.xhtml#10.6 From boris at codesynthesis.com Thu Mar 25 08:59:15 2021 From: boris at codesynthesis.com (Boris Kolpackov) Date: Thu Mar 25 08:59:15 2021 Subject: [odb-users] Errors building with ccache In-Reply-To: References: Message-ID: Wolfgang Haupt writes: > I've seen a problem compiling the odb compiler with ccache. Yes, this is a known issue and the next version of build2 will help with detecting the situation better: https://github.com/build2/build2/issues/86#issuecomment-647401742 In a nutshell, while ccache advertises itself as real GCC, it in fact is not and is incapable of handling the way build2 compiles things (with -fdirectives-only, etc). But the above bug report has some further pointers if you want to try to make it work (our long-term plan is to provide built-in support for distributed compilation and caching). From boris at codesynthesis.com Thu Mar 25 09:22:52 2021 From: boris at codesynthesis.com (Boris Kolpackov) Date: Thu Mar 25 09:22:53 2021 Subject: [odb-users] segmentation error on the hello example(w.r.t auto_ptr db (new odb::mysql::database (argc, argv));) In-Reply-To: References: Message-ID: ys C writes: > However when driver is run as below, I get segmentation error. > > *./driver --user root --database cpp_test* > > My debugging only got so far as finding out that it was due to L 62 in > *database.hxx* > > > *auto_ptr db (new odb::mysql::database (argc, argv));)* > > I am running on Ubuntu 18.04, using mysql for db, as mentioned. > Could this be installation issue? Yes, this could be a compiler/ABI mismatch between the compiler that you use to build the example and that was used to build the libodb* packages (I assume you are using system-installed ones). If you want to try to eliminate this possibility, I would suggest building the 2.5 pre-release from source as described here: https://codesynthesis.com/products/odb/doc/install-build2.xhtml Otherwise (or if you have the same issues with 2.5), you will need to build the test with debug information (-g) and look around in the debugger (e.g., stack trace, etc) for what might be causing this. From haupt.wolfgang at gmail.com Thu Mar 25 11:18:55 2021 From: haupt.wolfgang at gmail.com (Wolfgang Haupt) Date: Thu Mar 25 11:19:06 2021 Subject: [odb-users] Errors building with ccache In-Reply-To: References: Message-ID: <9afb4452-5add-826a-2545-7a60edc2d653@gmail.com> On 25.03.21 13:59, Boris Kolpackov wrote: > Wolfgang Haupt writes: > >> I've seen a problem compiling the odb compiler with ccache. > Yes, this is a known issue and the next version of build2 will > help with detecting the situation better: > > https://github.com/build2/build2/issues/86#issuecomment-647401742 > > In a nutshell, while ccache advertises itself as real GCC, it in > fact is not and is incapable of handling the way build2 compiles > things (with -fdirectives-only, etc). But the above bug report > has some further pointers if you want to try to make it work (our > long-term plan is to provide built-in support for distributed > compilation and caching). I somehow missed the ticket, sorry - sounds like a tricky situation. I compile as part of an operating system that cross-compiles to a variety of architectures. That system has a script called host-g++ in it's toolchain that will always use ccache, so all tools built with the host compiler (swig, cmake, odb, etc.) are unconditionally built with ccache. Guess I'll add a way to not use ccache for odb meanwhile. From PRAJ at beckman.com Thu Mar 25 22:22:33 2021 From: PRAJ at beckman.com (Raj, Phani) Date: Fri Mar 26 05:14:37 2021 Subject: [odb-users] Querying with native SQL Statements In-Reply-To: References: Message-ID: Hi Sir, Thanks for your response on this. I do have some queries on this. >From the Documentation my team was able to analyze the following things: * Execute method is used to perform only INSERT, DELETE and UPDATE operations as it only returns the number of rows affected. * Views will work on queries that are created at design time. But sir, I want to ask you one question, the query method has an overloaded version that takes a string as argument. But the documentation doesn't mention about it. My App needs to generate the SQL Statement dynamically as we are using a lot of polymorphic objects in a large hierarchy. So we want to use the query by simply building the query and execute them to return the results Can I call the query method that takes string as argument to get the required results? The Template version might not help us as per the requirement. Awaiting your valuable inputs. Thanks Phaniraj In my app, the query is auto generated. So -----Original Message----- From: Boris Kolpackov Sent: Thursday, March 25, 2021 6:09 PM To: Raj, Phani Cc: odb-users@codesynthesis.com Subject: Re: [odb-users] Querying with native SQL Statements Raj, Phani > writes: > Is there a possibility of querying data from the SQL Server using > ODB::ORM with native SQL statements. My App generates SQL Statements > that has to be executed thru' the db->query method. Is it possible to > do so. Yes, see "Executing Native SQL Statements": https://urldefense.proofpoint.com/v2/url?u=https-3A__codesynthesis.com_products_odb_doc_manual.xhtml-233.12&d=DwIBAg&c=9mghv0deYPYDGP-W745IEdQLV1kHpn4XJRvR6xMRXtA&r=4Wm03HXkMibbXdeNZ2Ayqw&m=4vCG1Nef7EQzuDBPWZbHp5MCRhJ5K9Ykk4LIGT2G88o&s=bJwdMoJx9RZqbUVoeg2XeXpaghZr_OAC56u0MGeJ-0g&e= As well as "Native Views": https://urldefense.proofpoint.com/v2/url?u=https-3A__codesynthesis.com_products_odb_doc_manual.xhtml-2310.6&d=DwIBAg&c=9mghv0deYPYDGP-W745IEdQLV1kHpn4XJRvR6xMRXtA&r=4Wm03HXkMibbXdeNZ2Ayqw&m=4vCG1Nef7EQzuDBPWZbHp5MCRhJ5K9Ykk4LIGT2G88o&s=2tDtImtae-5SJWHSVweLHS3q0-nqRKn0pC6k1h8f7Nw&e= Please be advised that this email may contain confidential information. If you are not the intended recipient, please notify us by email by replying to the sender and delete this message. The sender disclaims that the content of this email constitutes an offer to enter into, or the acceptance of, any agreement; provided that the foregoing does not invalidate the binding effect of any digital or other electronic reproduction of a manual signature that is included in any attachment. From boris at codesynthesis.com Fri Mar 26 05:26:23 2021 From: boris at codesynthesis.com (Boris Kolpackov) Date: Fri Mar 26 05:26:23 2021 Subject: [odb-users] Querying with native SQL Statements In-Reply-To: References: Message-ID: Raj, Phani writes: > * Views will work on queries that are created at design time. More precisely, native views will work for queries which have the number of columns in the result and their types known at design time. In other words, you can execute multiple queries with varying "WHERE ..." clauses using a single native view. > My App needs to generate the SQL Statement dynamically as we are > using a lot of polymorphic objects in a large hierarchy. So we > want to use the query by simply building the query and execute > them to return the results. As I mentioned above, if the result of such a query is "fixed" at compile-time, then you can use a native view. If you need to execute a (SELECT) query with a result set that is only know at runtime, then ODB won't be of much help to you and you are probably better off using a fully dynamic API like ODBC (or low-level wrappers found in libodb- libraries). From youngsunhere at gmail.com Fri Mar 26 06:53:31 2021 From: youngsunhere at gmail.com (ys C) Date: Fri Mar 26 06:53:52 2021 Subject: [odb-users] segmentation error on the hello example(w.r.t auto_ptr db (new odb::mysql::database (argc, argv));) In-Reply-To: References: Message-ID: ys C 12:10 PM (7 hours ago) to odb-users Thank you for your reply, Boris! I used g++ 7 for example and libodb build. I did use the 2.5 pre-release install through build as well. As you mentioned, I tried debugging while running the executable, and got the following clues. Could this be some broken linkage issue? libc.so.6!_int_malloc(mstate av, size_t bytes) libc.so.6!__GI___libc_malloc(size_t,bytes) libstdc++.so.6!operator new(unsigned long) libodb-mysql-2.4.so !odb::mysql::database::database(int&,char**,bool,std::__cxx11... create_database(int&,char**) main Thank you for your time! Youngsun Cho On Thu, Mar 25, 2021 at 10:22 PM Boris Kolpackov wrote: > ys C writes: > > > However when driver is run as below, I get segmentation error. > > > > *./driver --user root --database cpp_test* > > > > My debugging only got so far as finding out that it was due to L 62 in > > *database.hxx* > > > > > > *auto_ptr db (new odb::mysql::database (argc, argv));)* > > > > I am running on Ubuntu 18.04, using mysql for db, as mentioned. > > Could this be installation issue? > > Yes, this could be a compiler/ABI mismatch between the compiler that > you use to build the example and that was used to build the libodb* > packages (I assume you are using system-installed ones). > > If you want to try to eliminate this possibility, I would suggest > building the 2.5 pre-release from source as described here: > > https://codesynthesis.com/products/odb/doc/install-build2.xhtml > > Otherwise (or if you have the same issues with 2.5), you will > need to build the test with debug information (-g) and look > around in the debugger (e.g., stack trace, etc) for what might > be causing this. > -- Best regards, Youngsun Cho From boris at codesynthesis.com Fri Mar 26 09:56:14 2021 From: boris at codesynthesis.com (Boris Kolpackov) Date: Fri Mar 26 09:56:17 2021 Subject: [odb-users] segmentation error on the hello example(w.r.t auto_ptr db (new odb::mysql::database (argc, argv));) In-Reply-To: References: Message-ID: ys C writes: > I did use the 2.5 pre-release install through build as well. > > libodb-mysql-2.4.so As you can see your application is still loading the 2.4 version of the ODB runtime library. So you are either still building with 2.4 or wrong libraries are found/loaded. From ddiorio at jmawireless.com Mon Mar 29 01:24:22 2021 From: ddiorio at jmawireless.com (Domenico Di Iorio) Date: Mon Mar 29 09:53:53 2021 Subject: [odb-users] Issue in derived class callback Message-ID: Good morning, Issue has been found when registering callback in derived class. Apparently it overrides the one registered in base class. Is it already known? e.g. #pragma db callback(cb1) class Base { ... } #pragma db callback(cb2) class Derived : public Base { ... } cb1 gets overridden by cb2. Thanks, Di Iorio Domenico From boris at codesynthesis.com Mon Mar 29 10:16:26 2021 From: boris at codesynthesis.com (Boris Kolpackov) Date: Mon Mar 29 10:16:29 2021 Subject: [odb-users] Issue in derived class callback In-Reply-To: References: Message-ID: Domenico Di Iorio writes: > Issue has been found when registering callback in derived class. > Apparently it overrides the one registered in base class. > Is it already known? > > e.g. > #pragma db callback(cb1) > class Base { > ... > } > > #pragma db callback(cb2) > class Derived : public Base { > ... > } > > cb1 gets overridden by cb2. Hm, which one of the two cases is this: 1. cb2 is now called for instances of the Base class. 2. cb2 is now called for instances of the Derived class. If it's (1), then that would definitely be a bug. If it's (2), then that seems like a fairly logical and flexible behavior. From ddiorio at jmawireless.com Mon Mar 29 10:34:27 2021 From: ddiorio at jmawireless.com (Domenico Di Iorio) Date: Tue Mar 30 09:44:26 2021 Subject: [odb-users] Issue in derived class callback In-Reply-To: References: Message-ID: <1DAE5A35-6B20-47E0-9A3B-D312A952BC8B@jmawireless.com> It?s (2). I agree it seems logical and flexible, (user can always define cb2 to call cb1). I just wanted to make sure it was known because I didn?t find on manual. Thanks for reply, Regards, Di Iorio Domenico > Il giorno 29 mar 2021, alle ore 16:16, Boris Kolpackov ha scritto: > > Domenico Di Iorio writes: > >> Issue has been found when registering callback in derived class. >> Apparently it overrides the one registered in base class. >> Is it already known? >> >> e.g. >> #pragma db callback(cb1) >> class Base { >> ... >> } >> >> #pragma db callback(cb2) >> class Derived : public Base { >> ... >> } >> >> cb1 gets overridden by cb2. > > Hm, which one of the two cases is this: > > 1. cb2 is now called for instances of the Base class. > > 2. cb2 is now called for instances of the Derived class. > > If it's (1), then that would definitely be a bug. If it's (2), then > that seems like a fairly logical and flexible behavior.