From boris at codesynthesis.com Thu Sep 1 11:39:45 2016 From: boris at codesynthesis.com (Boris Kolpackov) Date: Thu Sep 1 11:39:55 2016 Subject: [odb-users] Does ODB support partial update? If not, how can we improve the performance? In-Reply-To: References: Message-ID: Hi Albert, Albert Gu writes: > I am using ODB currently, just want to know how can I improve the > update/insert/delete performance? > > Let's say, I have to insert 1000 new records, update 1000 old records, > delete 1000 records, after getting the response from server. > > These records are mixed together. Is there any good performance practice > for this kind of issue? SQLite doesn't support batch operations (unlike say Oracle or SQL Server). First thing I would do is understand what is the time split between inserts, updates, and deletes. For updates, if only updating a few members, then object sections could help (Chapter 9; perhaps that's what you meant by "partial update"). Also, with a lot of modification, suspending constraint checking always helps. If this is possible in your case, I would definitely try it first. Boris From albert.gu at ringcentral.com Thu Sep 1 21:08:30 2016 From: albert.gu at ringcentral.com (Albert Gu) Date: Fri Sep 2 12:31:04 2016 Subject: [odb-users] Does ODB support partial update? If not, how can we improve the performance? In-Reply-To: References: Message-ID: Get it. I will try it. Thank you Boris! - Regards, Albert On 9/1/16, 11:39 PM, "Boris Kolpackov" wrote: >Hi Albert, > >Albert Gu writes: > >> I am using ODB currently, just want to know how can I improve the >> update/insert/delete performance? >> >> Let's say, I have to insert 1000 new records, update 1000 old records, >> delete 1000 records, after getting the response from server. >> >> These records are mixed together. Is there any good performance practice >> for this kind of issue? > >SQLite doesn't support batch operations (unlike say Oracle or SQL Server). > >First thing I would do is understand what is the time split between >inserts, updates, and deletes. For updates, if only updating a few >members, then object sections could help (Chapter 9; perhaps that's >what you meant by "partial update"). > >Also, with a lot of modification, suspending constraint checking >always helps. If this is possible in your case, I would definitely >try it first. > >Boris From boris at codesynthesis.com Fri Sep 2 13:03:39 2016 From: boris at codesynthesis.com (Boris Kolpackov) Date: Fri Sep 2 13:03:46 2016 Subject: [odb-users] Custom ODB compiler build rule on OSX In-Reply-To: References: Message-ID: Hi Alexandre, Alexandre Pretyman writes: > I have not found a odb example which runs the odb compiler on a > project's headers, so please announce it to the list when there > one. Yes, will do. While ODB is not yet supported, one of the main goals of build2 is first-class, "no hacks" support for auto-generated source code. We do have rules for CLI[1] and it is working well. > [ as constructive feedback, I found hard to find the version of > libpq which is available in your repository ]. That's because it is a stub. That is, there is no source code (yet) and the only way to "build" a stub is to have it installed in the system. The link I gave you was running the version of the web interface that didn't indicate this. This one, however, does: https://stage.build2.org > I'm not a biggest fan of CMake, but I don't see it going away any time soon > :-) I guess us CMakers will have to integrate build2. I don't see why you would want to write, well, let's admit it, brain- dead build descriptions only to auto-convert them to something sane. Might as well write sane ;-) [1] http://codesynthesis.com/projects/cli/ Boris From Steve.Hales at garmin.com Fri Sep 2 19:54:49 2016 From: Steve.Hales at garmin.com (Hales, Steve) Date: Sat Sep 3 11:40:48 2016 Subject: [odb-users] Use of thread local storage in ODB Message-ID: <70A0FADD3F518341B85A76EC370B5E63E4D99FD9@OLAWPA-EXMB05.ad.garmin.com> My team has created an iOS app that uses ODB. We recently submitted the app to Apple to be published in the app store. Our app was rejected due to the presence of the symbol "__tlv_bootstrap" which Apple considers to be part of an unapproved private API. Our research indicates that this symbol results from use of the "__thread" modifier to create a thread local variable. The only place we can find __thread in our code is in the ODB header tls.hxx where it appears to take effect when POSIX threads are enabled. When we built the ODB library for our app we specified --enable-threads in the configure step. Can you tell us if that header, specifically the __thread use, is likely to be included in our code? If so, would rebuilding ODB with threads disabled remove it? And what effect might that have on our app? Thanks, Steve ________________________________ CONFIDENTIALITY NOTICE: This email and any attachments are for the sole use of the intended recipient(s) and contain information that may be Garmin confidential and/or Garmin legally privileged. If you have received this email in error, please notify the sender by reply email and delete the message. Any disclosure, copying, distribution or use of this communication (including attachments) by someone other than the intended recipient is prohibited. Thank you. From odb at a-cunningham.com Sat Sep 3 14:35:09 2016 From: odb at a-cunningham.com (Andrew Cunningham) Date: Sat Sep 3 14:35:22 2016 Subject: [odb-users] Use of thread local storage in ODB In-Reply-To: <70A0FADD3F518341B85A76EC370B5E63E4D99FD9@OLAWPA-EXMB05.ad.garmin.com> References: <70A0FADD3F518341B85A76EC370B5E63E4D99FD9@OLAWPA-EXMB05.ad.garmin.com> Message-ID: It depends on whether your app is running transactions in multiple threads. ODB has a concept of the "current transaction" and the "current session" which are variables that are TLS ( local to a thread). You might need to come up with another mechanism if you can't use the standard __thread. I would protest to Apple about rejecting your app. I can't see how compiling against "public" POSIX threading API's could be seen as using private APIs. Apple , of course, uses some automatic scanning of the app, maybe get a human involved. On Fri, Sep 2, 2016 at 4:54 PM, Hales, Steve wrote: > My team has created an iOS app that uses ODB. We recently submitted the > app to Apple to be published in the app store. Our app was rejected due to > the presence of the symbol "__tlv_bootstrap" which Apple considers to be > part of an unapproved private API. Our research indicates that this symbol > results from use of the "__thread" modifier to create a thread local > variable. The only place we can find __thread in our code is in the ODB > header tls.hxx where it appears to take effect when POSIX threads are > enabled. When we built the ODB library for our app we specified > --enable-threads in the configure step. Can you tell us if that header, > specifically the __thread use, is likely to be included in our code? If so, > would rebuilding ODB with threads disabled remove it? And what effect might > that have on our app? > > Thanks, > Steve > > ________________________________ > > CONFIDENTIALITY NOTICE: This email and any attachments are for the sole > use of the intended recipient(s) and contain information that may be Garmin > confidential and/or Garmin legally privileged. If you have received this > email in error, please notify the sender by reply email and delete the > message. Any disclosure, copying, distribution or use of this communication > (including attachments) by someone other than the intended recipient is > prohibited. Thank you. > From odb at a-cunningham.com Sat Sep 3 16:11:14 2016 From: odb at a-cunningham.com (Andrew Cunningham) Date: Sat Sep 3 16:11:27 2016 Subject: [odb-users] Use of thread local storage in ODB In-Reply-To: <4522F3E1-9115-4E7A-9707-F0E4BDDCA858@garmin.com> References: <70A0FADD3F518341B85A76EC370B5E63E4D99FD9@OLAWPA-EXMB05.ad.garmin.com> <4522F3E1-9115-4E7A-9707-F0E4BDDCA858@garmin.com> Message-ID: I know the pain of having an app rejected for no good reason (an app that does not use ODB..). The good news is that you have the source to libodb and can build a version without TLS. If you look at the source you will find ODB_TLS_POINTER is only used in transaction.cxx and session.cxx and is used to find the "current_transaction" and "current_session" for the "current_thread". I can think of many solutions. You could for example have a non TLS static std::map that contains a thread_id as the key, and the transaction * as the value, and the static current(),has_current() functions just lookup the std::map using the current thread_id. Obviously would need std::mutex around insert and remove of the std::map values for thread safety as a thread could be looking up the current_transaction while another was inserting/removing from the map On Sat, Sep 3, 2016 at 11:58 AM, Hales, Steve wrote: > Yes, our app does run simultaneous transactions in multiple threads. > Regarding the use of another mechanism instead of __thread do you have any > suggestions for how to do that? We have gotten a human involved at Apple > but they tend to be rather intransigent about these things. A number of > developers have complained on-line about Apple?s prohibition against > __thread and Apple has announced that Xcode 8 will support the thread_local > modifier introduced in C++11. We are up against a schedule deadline on this > and would be most appreciative of any guidance you can provide. If it > matters, we are using sqlite as our backing database with ODB. > > Thanks, > Steve > > From: on behalf of Andrew Cunningham < > odb@a-cunningham.com> > Date: Saturday, September 3, 2016 at 11:35 AM > To: "Hales, Steve" > Cc: "odb-users@codesynthesis.com" > Subject: Re: [odb-users] Use of thread local storage in ODB > > It depends on whether your app is running transactions in multiple > threads. ODB has a concept of the "current transaction" and the "current > session" which are variables that are TLS ( local to a thread). > You might need to come up with another mechanism if you can't use the > standard __thread. > > I would protest to Apple about rejecting your app. I can't see how > compiling against "public" POSIX threading API's could be seen as using > private APIs. Apple , of course, uses some automatic scanning of the app, > maybe get a human involved. > > > On Fri, Sep 2, 2016 at 4:54 PM, Hales, Steve > wrote: > >> My team has created an iOS app that uses ODB. We recently submitted the >> app to Apple to be published in the app store. Our app was rejected due to >> the presence of the symbol "__tlv_bootstrap" which Apple considers to be >> part of an unapproved private API. Our research indicates that this symbol >> results from use of the "__thread" modifier to create a thread local >> variable. The only place we can find __thread in our code is in the ODB >> header tls.hxx where it appears to take effect when POSIX threads are >> enabled. When we built the ODB library for our app we specified >> --enable-threads in the configure step. Can you tell us if that header, >> specifically the __thread use, is likely to be included in our code? If so, >> would rebuilding ODB with threads disabled remove it? And what effect might >> that have on our app? >> >> Thanks, >> Steve >> >> ________________________________ >> >> CONFIDENTIALITY NOTICE: This email and any attachments are for the sole >> use of the intended recipient(s) and contain information that may be Garmin >> confidential and/or Garmin legally privileged. If you have received this >> email in error, please notify the sender by reply email and delete the >> message. Any disclosure, copying, distribution or use of this communication >> (including attachments) by someone other than the intended recipient is >> prohibited. Thank you. >> > > From Steve.Hales at garmin.com Sat Sep 3 14:58:54 2016 From: Steve.Hales at garmin.com (Hales, Steve) Date: Mon Sep 5 12:04:00 2016 Subject: [odb-users] Use of thread local storage in ODB In-Reply-To: References: <70A0FADD3F518341B85A76EC370B5E63E4D99FD9@OLAWPA-EXMB05.ad.garmin.com> Message-ID: <4522F3E1-9115-4E7A-9707-F0E4BDDCA858@garmin.com> Yes, our app does run simultaneous transactions in multiple threads. Regarding the use of another mechanism instead of __thread do you have any suggestions for how to do that? We have gotten a human involved at Apple but they tend to be rather intransigent about these things. A number of developers have complained on-line about Apple?s prohibition against __thread and Apple has announced that Xcode 8 will support the thread_local modifier introduced in C++11. We are up against a schedule deadline on this and would be most appreciative of any guidance you can provide. If it matters, we are using sqlite as our backing database with ODB. Thanks, Steve From: > on behalf of Andrew Cunningham > Date: Saturday, September 3, 2016 at 11:35 AM To: "Hales, Steve" > Cc: "odb-users@codesynthesis.com" > Subject: Re: [odb-users] Use of thread local storage in ODB It depends on whether your app is running transactions in multiple threads. ODB has a concept of the "current transaction" and the "current session" which are variables that are TLS ( local to a thread). You might need to come up with another mechanism if you can't use the standard __thread. I would protest to Apple about rejecting your app. I can't see how compiling against "public" POSIX threading API's could be seen as using private APIs. Apple , of course, uses some automatic scanning of the app, maybe get a human involved. On Fri, Sep 2, 2016 at 4:54 PM, Hales, Steve > wrote: My team has created an iOS app that uses ODB. We recently submitted the app to Apple to be published in the app store. Our app was rejected due to the presence of the symbol "__tlv_bootstrap" which Apple considers to be part of an unapproved private API. Our research indicates that this symbol results from use of the "__thread" modifier to create a thread local variable. The only place we can find __thread in our code is in the ODB header tls.hxx where it appears to take effect when POSIX threads are enabled. When we built the ODB library for our app we specified --enable-threads in the configure step. Can you tell us if that header, specifically the __thread use, is likely to be included in our code? If so, would rebuilding ODB with threads disabled remove it? And what effect might that have on our app? Thanks, Steve ________________________________ CONFIDENTIALITY NOTICE: This email and any attachments are for the sole use of the intended recipient(s) and contain information that may be Garmin confidential and/or Garmin legally privileged. If you have received this email in error, please notify the sender by reply email and delete the message. Any disclosure, copying, distribution or use of this communication (including attachments) by someone other than the intended recipient is prohibited. Thank you. From boris at codesynthesis.com Mon Sep 5 12:08:28 2016 From: boris at codesynthesis.com (Boris Kolpackov) Date: Mon Sep 5 12:08:33 2016 Subject: [odb-users] Use of thread local storage in ODB In-Reply-To: <4522F3E1-9115-4E7A-9707-F0E4BDDCA858@garmin.com> References: <70A0FADD3F518341B85A76EC370B5E63E4D99FD9@OLAWPA-EXMB05.ad.garmin.com> <4522F3E1-9115-4E7A-9707-F0E4BDDCA858@garmin.com> Message-ID: Hi Steve, Hales, Steve writes: > Regarding the use of another mechanism instead of __thread do you have any > suggestions for how to do that? Just comment out #define for ODB_THREADS_TLS_KEYWORD in libodb/odb/details/config.h. ODB will then use (slower) POSIX TLS API which is acceptable to Apple, AFAIK. Boris From arnaud.kapp at islog.com Fri Sep 9 13:01:36 2016 From: arnaud.kapp at islog.com (Arnaud Kapp) Date: Fri Sep 9 13:34:22 2016 Subject: [odb-users] Error: Relation "schema_version" already exists Message-ID: <64ce8aab-ecd1-f59c-ac5d-0819c4f25ab2@islog.com> Hello, I've been using ODB against SQLite and MySQL database. I had a weird issue that didn't hit SQLite. Therefore, I wanted to give a try with PostgreSQL. I'm new to Postgre but I don't think it's particularly relevant here. I use multiple ODB schema, and use versioning. Therefore, when generating various model tables, a schema_version table is also created. The problem is, when targeting Postgre, an exception is thrown when creating the second schema. The first one gets created ok, then `42P07: ERROR: relation "schema_version" already exists` is thrown. From reading the documentation as well as various mailing list post I know that this can happen when building the table from various .sql files. However, I generate embedded schema, and I believe ODB should take of this for me (and it does with SQLite / MySQL). Would this be something I missed, a potential bug, or something else? Thank you ! -- Best regards / Cordialement, Arnaud KAPP 13, rue du g?n?ral de Castelnau 67000 Strasbourg FRANCE http://www.islog.com From boris at codesynthesis.com Mon Sep 12 11:06:05 2016 From: boris at codesynthesis.com (Boris Kolpackov) Date: Mon Sep 12 11:06:18 2016 Subject: [odb-users] Error: Relation "schema_version" already exists In-Reply-To: <64ce8aab-ecd1-f59c-ac5d-0819c4f25ab2@islog.com> References: <64ce8aab-ecd1-f59c-ac5d-0819c4f25ab2@islog.com> Message-ID: Hi Arnaud, Arnaud Kapp writes: > The problem is, when targeting Postgre, an exception is thrown > when creating the second schema. The first one gets created ok, > then `42P07: ERROR: relation "schema_version" already exists` is > thrown. PostgreSQL prior to 9.1 doesn't have support for IF NOT EXISTS clause in CREATE TABLE. As a result, if targeting any PG version ODB can't do much about it. You can tell ODB you are using 9.1 or later with: --pgsql-server-version 9.1 Boris From arnaud.kapp at islog.com Tue Sep 13 05:39:50 2016 From: arnaud.kapp at islog.com (Arnaud Kapp) Date: Tue Sep 13 10:50:27 2016 Subject: [odb-users] Error: Relation "schema_version" already exists In-Reply-To: References: <64ce8aab-ecd1-f59c-ac5d-0819c4f25ab2@islog.com> Message-ID: Hello Boris, Oh, that makes sense now. Indeed all works great with --pgsql-server-version 9.1 Thank you very much ! On 09/12/2016 05:06 PM, Boris Kolpackov wrote: > Hi Arnaud, > > Arnaud Kapp writes: > >> The problem is, when targeting Postgre, an exception is thrown >> when creating the second schema. The first one gets created ok, >> then `42P07: ERROR: relation "schema_version" already exists` is >> thrown. > > PostgreSQL prior to 9.1 doesn't have support for IF NOT EXISTS clause > in CREATE TABLE. As a result, if targeting any PG version ODB can't > do much about it. You can tell ODB you are using 9.1 or later with: > > --pgsql-server-version 9.1 > > Boris > -- Best regards / Cordialement, Arnaud KAPP 13, rue du g?n?ral de Castelnau 67000 Strasbourg FRANCE http://www.islog.com From rosemberg at ymail.com Wed Sep 14 04:39:15 2016 From: rosemberg at ymail.com (Menashe Rosemberg) Date: Wed Sep 14 19:57:41 2016 Subject: [odb-users] warning: ignoring #pragma db object [-Wunknown-pramas] References: <107873186.817877.1473842355300.ref@mail.yahoo.com> Message-ID: <107873186.817877.1473842355300@mail.yahoo.com> Hi friends, I new with c++ and I wanted to use ODB like my way to access the MySQL database. I start to learn about it from odb-manual and I try to follow all steps described there. My enviroment is:Linux xenial1604x86 4.4.0-36-generic #55-Ubuntu SMP Thu Aug 11 18:01:55 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux Code::Blocks configured to:GNU GCC compiller (Have G++ follow the C++11 ISO C++ language standard) (build-essential)MySQL-Server and MySQL-Server and LibMYSQLClient-devODB 2.4 (intalled form apt-get command line) ?I've been stuck with this problem.?The GCC compiller simply ignore all #pragma statement. What I need to do to fix it? Bellow the log from Code::Blocks Build messages. Best regards,M.Rosemberg ||=== Build: Debug in ODBTest (compiler: GNU GCC Compiler) ===| /home/administrator/Desktop/ProjectS/ODBTest/Person.hxx|10|warning: ignoring #pragma db object [-Wunknown-pragmas]| /home/administrator/Desktop/ProjectS/ODBTest/Person.hxx|28|warning: ignoring #pragma db id [-Wunknown-pragmas]| /home/administrator/Desktop/ProjectS/ODBTest/Person.hxx|10|warning: ignoring #pragma db object [-Wunknown-pragmas]| /home/administrator/Desktop/ProjectS/ODBTest/Person.hxx|28|warning: ignoring #pragma db id [-Wunknown-pragmas]| obj/Debug/Person-odb.o||In function `odb::access::object_traits_impl::grow(odb::access::object_traits_impl::image_type&, char*)':| /home/administrator/Desktop/ProjectS/ODBTest/Person-odb.cxx|99|undefined reference to `odb::details::basic_buffer_base::capacity(unsigned long, unsigned long)'| /home/administrator/Desktop/ProjectS/ODBTest/Person-odb.cxx|107|undefined reference to `odb::details::basic_buffer_base::capacity(unsigned long, unsigned long)'| obj/Debug/Person-odb.o||In function `odb::access::object_traits_impl::init(odb::access::object_traits_impl::image_type&, person const&, odb::mysql::statement_kind)':| /home/administrator/Desktop/ProjectS/ODBTest/Person-odb.cxx|222|undefined reference to `odb::mysql::string_value_traits::set_image(odb::details::basic_buffer&, unsigned long&, bool&, std::__cxx11::basic_string, std::allocator > const&)'| /home/administrator/Desktop/ProjectS/ODBTest/Person-odb.cxx|243|undefined reference to `odb::mysql::string_value_traits::set_image(odb::details::basic_buffer&, unsigned long&, bool&, std::__cxx11::basic_string, std::allocator > const&)'| obj/Debug/Person-odb.o||In function `odb::access::object_traits_impl::persist(odb::database&, person&)':| /home/administrator/Desktop/ProjectS/ODBTest/Person-odb.cxx|399|undefined reference to `odb::mysql::transaction::current()'| /home/administrator/Desktop/ProjectS/ODBTest/Person-odb.cxx|435|undefined reference to `odb::mysql::insert_statement::execute()'| /home/administrator/Desktop/ProjectS/ODBTest/Person-odb.cxx|436|undefined reference to `typeinfo for odb::object_already_persistent'| obj/Debug/Person-odb.o||In function `odb::access::object_traits_impl::update(odb::database&, person const&)':| /home/administrator/Desktop/ProjectS/ODBTest/Person-odb.cxx|455|undefined reference to `odb::mysql::transaction::current()'| /home/administrator/Desktop/ProjectS/ODBTest/Person-odb.cxx|499|undefined reference to `odb::mysql::update_statement::execute()'| /home/administrator/Desktop/ProjectS/ODBTest/Person-odb.cxx|500|undefined reference to `typeinfo for odb::object_not_persistent'| obj/Debug/Person-odb.o||In function `odb::access::object_traits_impl::erase(odb::database&, unsigned long const&)':| /home/administrator/Desktop/ProjectS/ODBTest/Person-odb.cxx|514|undefined reference to `odb::mysql::transaction::current()'| /home/administrator/Desktop/ProjectS/ODBTest/Person-odb.cxx|529|undefined reference to `odb::mysql::delete_statement::execute()'| /home/administrator/Desktop/ProjectS/ODBTest/Person-odb.cxx|530|undefined reference to `typeinfo for odb::object_not_persistent'| obj/Debug/Person-odb.o||In function `odb::access::object_traits_impl::find(odb::database&, unsigned long const&)':| /home/administrator/Desktop/ProjectS/ODBTest/Person-odb.cxx|549|undefined reference to `odb::mysql::transaction::current()'| obj/Debug/Person-odb.o||In function `odb::access::object_traits_impl::find(odb::database&, unsigned long const&, person&)':| /home/administrator/Desktop/ProjectS/ODBTest/Person-odb.cxx|597|undefined reference to `odb::mysql::transaction::current()'| obj/Debug/Person-odb.o||In function `odb::access::object_traits_impl::reload(odb::database&, person&)':| /home/administrator/Desktop/ProjectS/ODBTest/Person-odb.cxx|630|undefined reference to `odb::mysql::transaction::current()'| obj/Debug/Person-odb.o||In function `odb::access::object_traits_impl::find_(odb::mysql::object_statements&, unsigned long const*)':| /home/administrator/Desktop/ProjectS/ODBTest/Person-odb.cxx|684|undefined reference to `odb::mysql::select_statement::execute()'| /home/administrator/Desktop/ProjectS/ODBTest/Person-odb.cxx|686|undefined reference to `odb::mysql::select_statement::fetch(bool)'| /home/administrator/Desktop/ProjectS/ODBTest/Person-odb.cxx|698|undefined reference to `odb::mysql::select_statement::refetch()'| obj/Debug/Person-odb.o||In function `odb::access::object_traits_impl::query(odb::database&, odb::mysql::query_base const&)':| /home/administrator/Desktop/ProjectS/ODBTest/Person-odb.cxx|714|undefined reference to `odb::mysql::transaction::current()'| /home/administrator/Desktop/ProjectS/ODBTest/Person-odb.cxx|734|undefined reference to `odb::mysql::query_base::clause[abi:cxx11]() const'| /home/administrator/Desktop/ProjectS/ODBTest/Person-odb.cxx|737|undefined reference to `odb::mysql::query_base::init_parameters() const'| /home/administrator/Desktop/ProjectS/ODBTest/Person-odb.cxx|745|undefined reference to `odb::details::shared'| /home/administrator/Desktop/ProjectS/ODBTest/Person-odb.cxx|745|undefined reference to `odb::mysql::select_statement::select_statement(odb::mysql::connection&, std::__cxx11::basic_string, std::allocator > const&, bool, bool, odb::mysql::binding&, odb::mysql::binding&)'| /home/administrator/Desktop/ProjectS/ODBTest/Person-odb.cxx|747|undefined reference to `odb::mysql::select_statement::execute()'| /home/administrator/Desktop/ProjectS/ODBTest/Person-odb.cxx|751|undefined reference to `odb::details::shared'| obj/Debug/Person-odb.o||In function `odb::access::object_traits_impl::erase_query(odb::database&, odb::mysql::query_base const&)':| /home/administrator/Desktop/ProjectS/ODBTest/Person-odb.cxx|762|undefined reference to `odb::mysql::transaction::current()'| /home/administrator/Desktop/ProjectS/ODBTest/Person-odb.cxx|768|undefined reference to `odb::mysql::query_base::clause[abi:cxx11]() const'| /home/administrator/Desktop/ProjectS/ODBTest/Person-odb.cxx|771|undefined reference to `odb::mysql::query_base::init_parameters() const'| /home/administrator/Desktop/ProjectS/ODBTest/Person-odb.cxx|775|undefined reference to `odb::mysql::delete_statement::delete_statement(odb::mysql::connection&, std::__cxx11::basic_string, std::allocator > const&, odb::mysql::binding&)'| /home/administrator/Desktop/ProjectS/ODBTest/Person-odb.cxx|777|undefined reference to `odb::mysql::delete_statement::execute()'| /home/administrator/Desktop/ProjectS/ODBTest/Person-odb.cxx|775|undefined reference to `odb::mysql::delete_statement::~delete_statement()'| /home/administrator/Desktop/ProjectS/ODBTest/Person-odb.cxx|775|undefined reference to `odb::mysql::delete_statement::~delete_statement()'| obj/Debug/Person-odb.o||In function `odb::details::shared_base::_dec_ref()':| /usr/include/odb/details/shared-ptr/base.ixx|57|undefined reference to `odb::details::shared_base::_dec_ref_callback()'| obj/Debug/Person-odb.o||In function `odb::mysql::auto_result::~auto_result()':| /usr/include/odb/mysql/statement.hxx|222|undefined reference to `odb::mysql::select_statement::free_result()'| obj/Debug/Person-odb.o||In function `odb::mysql::statements_base::statements_base(odb::mysql::connection&)':| /usr/include/odb/mysql/statements-base.hxx|53|undefined reference to `vtable for odb::mysql::statements_base'| obj/Debug/Person-odb.o||In function `odb::mysql::object_statements_base::object_statements_base(odb::mysql::connection&)':| /usr/include/odb/mysql/simple-object-statements.hxx|148|undefined reference to `vtable for odb::mysql::object_statements_base'| obj/Debug/Person-odb.o||In function `odb::object_already_persistent::object_already_persistent()':| /usr/include/odb/exceptions.hxx|133|undefined reference to `vtable for odb::object_already_persistent'| obj/Debug/Person-odb.o||In function `odb::object_not_persistent::object_not_persistent()':| /usr/include/odb/exceptions.hxx|124|undefined reference to `vtable for odb::object_not_persistent'| obj/Debug/Person-odb.o||In function `odb::object_traits_impl::statements_type& odb::mysql::statement_cache::find_object()':| /usr/include/odb/mysql/statement-cache.txx|36|undefined reference to `odb::details::shared'| obj/Debug/Person-odb.o||In function `odb::mysql::object_statements::persist_statement()':| /usr/include/odb/mysql/simple-object-statements.hxx|357|undefined reference to `odb::details::shared'| /usr/include/odb/mysql/simple-object-statements.hxx|357|undefined reference to `odb::mysql::insert_statement::insert_statement(odb::mysql::connection&, char const*, bool, odb::mysql::binding&, odb::mysql::binding*, bool)'| obj/Debug/Person-odb.o||In function `odb::mysql::object_statements::update_statement()':| /usr/include/odb/mysql/simple-object-statements.hxx|390|undefined reference to `odb::details::shared'| /usr/include/odb/mysql/simple-object-statements.hxx|390|undefined reference to `odb::mysql::update_statement::update_statement(odb::mysql::connection&, char const*, bool, odb::mysql::binding&, bool)'| obj/Debug/Person-odb.o||In function `odb::mysql::object_statements::erase_statement()':| /usr/include/odb/mysql/simple-object-statements.hxx|405|undefined reference to `odb::details::shared'| /usr/include/odb/mysql/simple-object-statements.hxx|405|undefined reference to `odb::mysql::delete_statement::delete_statement(odb::mysql::connection&, char const*, odb::mysql::binding&, bool)'| obj/Debug/Person-odb.o||In function `odb::mysql::object_statements::find_statement()':| /usr/include/odb/mysql/simple-object-statements.hxx|373|undefined reference to `odb::details::shared'| /usr/include/odb/mysql/simple-object-statements.hxx|373|undefined reference to `odb::mysql::select_statement::select_statement(odb::mysql::connection&, char const*, bool, bool, odb::mysql::binding&, odb::mysql::binding&, bool)'| obj/Debug/Person-odb.o||In function `odb::object_result_impl::~object_result_impl()':| /usr/include/odb/simple-object-result.hxx|26|undefined reference to `odb::result_impl::~result_impl()'| obj/Debug/Person-odb.o||In function `odb::mysql::object_statements::object_statements(odb::mysql::connection&)':| /usr/include/odb/mysql/simple-object-statements.txx|52|undefined reference to `odb::mysql::object_statements_base::~object_statements_base()'| ||More errors follow but not being shown.| ||Edit the max errors limit in compiler options...| ||=== Build failed: 50 error(s), 4 warning(s) (0 minute(s), 2 second(s)) ===| From boris at codesynthesis.com Wed Sep 14 20:34:09 2016 From: boris at codesynthesis.com (Boris Kolpackov) Date: Wed Sep 14 20:34:19 2016 Subject: [odb-users] warning: ignoring #pragma db object [-Wunknown-pramas] In-Reply-To: <107873186.817877.1473842355300@mail.yahoo.com> References: <107873186.817877.1473842355300.ref@mail.yahoo.com> <107873186.817877.1473842355300@mail.yahoo.com> Message-ID: Hi Menashe, Menashe Rosemberg writes: > /home/administrator/Desktop/ProjectS/ODBTest/Person.hxx|10|warning: ignoring #pragma db object [-Wunknown-pragmas]| > /home/administrator/Desktop/ProjectS/ODBTest/Person.hxx|28|warning: ignoring #pragma db id [-Wunknown-pragmas]| > /home/administrator/Desktop/ProjectS/ODBTest/Person.hxx|10|warning: ignoring #pragma db object [-Wunknown-pragmas]| > /home/administrator/Desktop/ProjectS/ODBTest/Person.hxx|28|warning: ignoring #pragma db id [-Wunknown-pragmas]| The C++ compiler should ignore ODB pragmas. They are only interpreted by the ODB compiler. You may want to add -Wno-unknown-pragmas option to suppress these warnings. > obj/Debug/Person-odb.o||In function `odb::access::object_traits_impl::grow(odb::access::object_traits_impl::image_type&, char*)':| > /home/administrator/Desktop/ProjectS/ODBTest/Person-odb.cxx|99|undefined reference to `odb::details::basic_buffer_base::capacity(unsigned long, unsigned long)'| And this is your actual problem: I believe you are not linking to libodb-mysql and libodb. Boris From dieter.govaerts at bricsys.com Thu Sep 15 08:17:24 2016 From: dieter.govaerts at bricsys.com (Dieter Govaerts) Date: Thu Sep 15 08:17:31 2016 Subject: [odb-users] Small documentation error Message-ID: <1473941844.42425047@apps.rackspace.com> Hello, I've found a small error in "7.3 Pointers and NULL Value Semantics" in the sample code for the nullable interface: // The same using the pointer interface. // if (ns) { // ... should be (condition negation): // The same using the pointer interface. // if (!ns) { // ... Regards, Dieter From rosemberg at ymail.com Thu Sep 15 06:15:35 2016 From: rosemberg at ymail.com (Menashe Rosemberg) Date: Thu Sep 15 16:44:18 2016 Subject: [odb-users] warning: ignoring #pragma db object [-Wunknown-pramas] In-Reply-To: References: <107873186.817877.1473842355300.ref@mail.yahoo.com> <107873186.817877.1473842355300@mail.yahoo.com> Message-ID: <1913104032.1483296.1473934535693@mail.yahoo.com> Hi Boris, Thanks for the fast response man. I installed the odb from command line and it didn't install "apt-get install odb" and I didn't find the libodb and libobd-mysql... at least I didn't find it on my pc. I checked the libodb-dev andlibodb-mysql-dev?packages and the apt-get?says I have installed the newest version. I know I can download the libs from ODB Download, but it a good practice to keep using the Ubuntu default installation in my opinion. | | | | | | | | | | | ODB Download ODB download page | | | | Can you help with that? And how to link it using the Code::Blocks IDE? May I suggest to include this solutions on your site? More specifically on Linux/UNIX? I think you will reach more users if you describe step by step how to work with ODB on ubuntu/Code::Blocks environment. Again, thanks for your attention and your work on this tool. Best regards, M.Rosemberg Em Quinta-feira, 15 de Setembro de 2016 3:34, Boris Kolpackov escreveu: Hi Menashe, Menashe Rosemberg writes: > /home/administrator/Desktop/ProjectS/ODBTest/Person.hxx|10|warning: ignoring #pragma db object [-Wunknown-pragmas]| > /home/administrator/Desktop/ProjectS/ODBTest/Person.hxx|28|warning: ignoring #pragma db id [-Wunknown-pragmas]| > /home/administrator/Desktop/ProjectS/ODBTest/Person.hxx|10|warning: ignoring #pragma db object [-Wunknown-pragmas]| > /home/administrator/Desktop/ProjectS/ODBTest/Person.hxx|28|warning: ignoring #pragma db id [-Wunknown-pragmas]| The C++ compiler should ignore ODB pragmas. They are only interpreted by the ODB compiler. You may want to add -Wno-unknown-pragmas option to suppress these warnings. > obj/Debug/Person-odb.o||In function `odb::access::object_traits_impl::grow(odb::access::object_traits_impl::image_type&, char*)':| > /home/administrator/Desktop/ProjectS/ODBTest/Person-odb.cxx|99|undefined reference to `odb::details::basic_buffer_base::capacity(unsigned long, unsigned long)'| And this is your actual problem: I believe you are not linking to libodb-mysql and libodb. Boris From boris at codesynthesis.com Thu Sep 15 16:55:53 2016 From: boris at codesynthesis.com (Boris Kolpackov) Date: Thu Sep 15 16:56:02 2016 Subject: [odb-users] Small documentation error In-Reply-To: <1473941844.42425047@apps.rackspace.com> References: <1473941844.42425047@apps.rackspace.com> Message-ID: Dieter, fixed, thanks for the report! Boris From sexymimi64 at gmail.com Sun Sep 18 13:32:52 2016 From: sexymimi64 at gmail.com (=?UTF-8?Q?Michael_Mart=C3=ADn_Moro?=) Date: Sun Sep 18 13:33:25 2016 Subject: [odb-users] Memory leaks when using odb::session Message-ID: Greetings, I had to use odb::session to get a bidirectional relationship working. I noticed that whenever there's an odb::session active in a query, I end up with a lot of memory leaks pointing at memory allocated through odb. There's one session and one transaction for each request. I've verified that the session was created before, and removed after the transaction. The application is multi-threaded, but each request is always handled by a single thread. Appart from that, I don't see what could've gone wrong. The leaks all look like this: ==3267== 1,728 bytes in 12 blocks are indirectly lost in loss record 81 of 92 ==3267== at 0x4C2B0D8: operator new(unsigned long) (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) ==3267== by 0x587750F: odb::access::object_traits_impl::find(odb::database&, unsigned long const&) (in /home/crails/crails-app/arch-docker/app-build/libcrails-app.so) ==3267== by 0x58A4E1D: odb::object_traits::pointer_type odb::database::load_(odb::object_traits::id_type const&) (in /home/crails/crails-app/arch-docker/app-build/libcrails-app.so) ==3267== by 0x5877C70: odb::access::object_traits_impl::student_groups_traits::init(unsigned long&, std::shared_ptr&, odb::access::object_traits_impl::student_groups_traits::data_image_type const&, odb::database*) (in /home/crails/crails-app/arch-docker/app-build/libcrails-app.so) ==3267== by 0x5877CEF: odb::access::object_traits_impl::student_groups_traits::select(unsigned long&, std::shared_ptr&, void*) (in /home/crails/crails-app/arch-docker/app-build/libcrails-app.so) ==3267== by 0x58503E3: odb::access::object_traits_impl::student_groups_traits::load(std::__cxx11::list, std::allocator > >&, odb::pgsql::container_statements::student_groups_traits>&) (in /home/crails/crails-app/arch-docker/app-build/libcrails-app.so) ==3267== by 0x5878BBD: odb::access::object_traits_impl::find(odb::database&, unsigned long const&) (in /home/crails/crails-app/arch-docker/app-build/libcrails-app.so) ==3267== by 0x58A557D: odb::object_traits::pointer_type odb::database::load_(odb::object_traits::id_type const&) (in /home/crails/crails-app/arch-docker/app-build/libcrails-app.so) ==3267== by 0x5878EB0: odb::access::object_traits_impl::init(Subject&, odb::access::object_traits_impl::image_type const&, odb::database*) (in /home/crails/crails-app/arch-docker/app-build/libcrails-app.so) ==3267== by 0x58A9F56: odb::pgsql::object_result_impl::load(Subject&, bool) (in /home/crails/crails-app/arch-docker/app-build/libcrails-app.so) ==3267== by 0x56E0D22: odb::object_result_impl::load() (in /home/crails/crails-app/arch-docker/app-build/libcrails-app.so) ==3267== by 0x56E0EC7: odb::result::one() (in /home/crails/crails-app/arch-docker/app-build/libcrails-app.so) Is there any reason why an odb::session would cause memory leaks ? Thanks for helping. -- *Micha?l Mart?n Moro* { Epitech. Tek4 } { UCA Cad?z - Computer Engineering } From boris at codesynthesis.com Sun Sep 18 17:43:11 2016 From: boris at codesynthesis.com (Boris Kolpackov) Date: Sun Sep 18 17:43:18 2016 Subject: [odb-users] Memory leaks when using odb::session In-Reply-To: References: Message-ID: Hi, Michael Mart?n Moro writes: > I had to use odb::session to get a bidirectional relationship working. I > noticed that whenever there's an odb::session active in a query, I end up > with a lot of memory leaks pointing at memory allocated through odb. You are probably using raw pointers for your objects. Use std::shared_ptr instead (Section 3.3, "Object and View Pointers" in the manual). Boris From michael at unetresgrossebite.com Mon Sep 19 09:28:57 2016 From: michael at unetresgrossebite.com (=?ISO-8859-1?Q?Micha=EBl_Mart=EDn?= Moro) Date: Mon Sep 19 21:46:08 2016 Subject: [odb-users] Memory leaks when using odb::session In-Reply-To: References: Message-ID: <9764269.uY55WZArDq@archnemesis> Thanks for taking care of me ! Most of the objects were using shared_ptr already, but I've noticed that I forgot to specify the pointer type on my views. So that helped ! After a much closer inspection, I've realized that this leak happens because the odb::database object is not deleted properly. I've been able to reproduce the same kind of memory leaks on a small project... but in that project, the issue only happens if odb::database isn't deleted after the odb::session. Considering the way it's stored (thread_local std::unique_ptr), it's a bit absurd that odb::database doesn't get deleted in my application... but the evidence is there, so I'll just assume that's what happens. Anyhow, the situation raises more questions. Does that mean that, between two requests, I should remove the odb::database object ? Does it mean that, as long as I don't remvoe the odb::database object, there's a cache stored somewhere ? Because I definitely do not want that. And yet, I do not want to disconnect and re-connect the database at every query. On domingo, 18 de septiembre de 2016 23:43:11 (CEST) you wrote: > Hi, > > Michael Mart?n Moro writes: > > I had to use odb::session to get a bidirectional relationship working. I > > noticed that whenever there's an odb::session active in a query, I end up > > with a lot of memory leaks pointing at memory allocated through odb. > > You are probably using raw pointers for your objects. Use std::shared_ptr > instead (Section 3.3, "Object and View Pointers" in the manual). > > Boris From ratkaisut at gmail.com Wed Sep 21 04:26:37 2016 From: ratkaisut at gmail.com (Sten Kultakangas) Date: Wed Sep 21 04:26:49 2016 Subject: [odb-users] mapping between long long and NUMERIC(18,0) type Message-ID: Hello We have legacy software that deals with MS SQL tables where primary key and other fields are defined as numeric(18,0) instead of bigint. I don't want to modify the definition of the tables. So far i have been accessing the table without any problems using the following model: PRAGMA_DB(object no_id schema("XXXDatabase.dbo")) struct XXXTable { //... PRAGMA_DB(type("bigint")) long long XXXduration; //... }; I do not read nor update the primary key so far. The question is: what is the best place in libodb code to implement a conversion routine between numeric(18,0) and "long long" ? It would be just a temporary solution. The generic solution would be to implement a generic conversion routine between an arbitrary precision NUMERIC and boost::multiprecision::number> type. Best regards, Sten Kultakangas From obermann.lukas at gmail.com Wed Sep 21 10:50:31 2016 From: obermann.lukas at gmail.com (Lukas Obermann) Date: Wed Sep 21 10:50:54 2016 Subject: [odb-users] GCC Headers on MacOS X Message-ID: Hi there, I am trying to build ODB on a Mac. I am integrating it into a existing build system, so I do want to avoid using the pre-built versions and get the build running, as it will also be build on Windows and Linux (will test those next). Building libcult was no issue, but on odb I now get following error on the configure: checking for GCC plugin headers... no configure: error: GCC plugin headers not found; consider installing GCC plugin development package make: *** [macosx10.11_x86_64-target] Error 1 Executing a gcc --version gives me following: $ gcc --version Configured with: --prefix=/Applications/Xcode.app/Contents/Developer/usr --with-gxx-include-dir=/usr/include/c++/4.2.1 Apple LLVM version 7.3.0 (clang-703.0.31) Target: x86_64-apple-darwin15.6.0 Thread model: posix InstalledDir: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin I already tryed goolgling for it, but I did not came up with a solutions. Would appreciate any hint on this on how to get this build going. Also let me know when you need any more details. Thanks, Lukas From boris at codesynthesis.com Wed Sep 21 21:17:53 2016 From: boris at codesynthesis.com (Boris Kolpackov) Date: Wed Sep 21 21:18:04 2016 Subject: [odb-users] GCC Headers on MacOS X In-Reply-To: References: Message-ID: Hi Lukas, Lukas Obermann writes: > I am trying to build ODB on a Mac. I am integrating it into a existing > build system, so I do want to avoid using the pre-built versions and get > the build running, as it will also be build on Windows and Linux (will test > those next). I must warn you, Windows will be really hard (as in "patching GCC" hard). > Executing a gcc --version gives me following: > > $ gcc --version > Configured with: --prefix=/Applications/Xcode.app/Contents/Developer/usr > --with-gxx-include-dir=/usr/include/c++/4.2.1 > Apple LLVM version 7.3.0 (clang-703.0.31) > Target: x86_64-apple-darwin15.6.0 > Thread model: posix > InstalledDir: > /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin This is actually not GCC, it is Apple's Clang pretending to be GCC. To build ODB from source on Mac OS you will need to build GCC with plugin support enabled (--enable-plugin configure option). You could also try GCC from homebrew though I am not sure if it's built with plugins enabled these days. Boris From boris at codesynthesis.com Wed Sep 21 21:31:46 2016 From: boris at codesynthesis.com (Boris Kolpackov) Date: Wed Sep 21 21:31:57 2016 Subject: [odb-users] mapping between long long and NUMERIC(18,0) type In-Reply-To: References: Message-ID: Hi Sten, Sten Kultakangas writes: > I do not read nor update the primary key so far. The question is: what > is the best place in libodb code to implement a conversion routine > between numeric(18,0) and "long long" ? It would be just a temporary > solution. You actually don't need to do it directly in libodb (actually it would have to be libodb-mssql) since ODB supports custom C++ to SQL type mapping, as described in this article: www.codesynthesis.com/~boris/blog/2012/10/16/custom-cxx-to-database-type-mapping-in-odb/ A few pointers about this specific case (all files mentioned are in libodb-mssql): 1. The SQL type is id_decimal (defined in traits.hxx). 2. The image type is struct decimal (defined in mssql-fwd.hxx). 3. The binary format should be described in MSDN (see SQL_DECIMAL, SQL_NUMERIC_STRUCT). Boris From odb at a-cunningham.com Wed Sep 21 21:43:12 2016 From: odb at a-cunningham.com (Andrew Cunningham) Date: Wed Sep 21 21:43:25 2016 Subject: [odb-users] GCC Headers on MacOS X In-Reply-To: References: Message-ID: Hi Lukas, I was able to build the ODB compiler on OS X using GCC 4.8 from MacPorts.... For example.... ./configure CXX=x86_64-apple-darwin15-c++-mp-4.8 Andrew On Wed, Sep 21, 2016 at 6:17 PM, Boris Kolpackov wrote: > > Hi Lukas, > > Lukas Obermann writes: > > > I am trying to build ODB on a Mac. I am integrating it into a existing > > build system, so I do want to avoid using the pre-built versions and get > > the build running, as it will also be build on Windows and Linux (will test > > those next). > > I must warn you, Windows will be really hard (as in "patching GCC" hard). > > > > Executing a gcc --version gives me following: > > > > $ gcc --version > > Configured with: --prefix=/Applications/Xcode.app/Contents/Developer/usr > > --with-gxx-include-dir=/usr/include/c++/4.2.1 > > Apple LLVM version 7.3.0 (clang-703.0.31) > > Target: x86_64-apple-darwin15.6.0 > > Thread model: posix > > InstalledDir: > > /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin > > This is actually not GCC, it is Apple's Clang pretending to be GCC. > > To build ODB from source on Mac OS you will need to build GCC with plugin > support enabled (--enable-plugin configure option). You could also try > GCC from homebrew though I am not sure if it's built with plugins enabled > these days. > > Boris > From obermann.lukas at gmail.com Thu Sep 22 03:27:54 2016 From: obermann.lukas at gmail.com (Lukas Obermann) Date: Thu Sep 22 03:28:19 2016 Subject: [odb-users] GCC Headers on MacOS X In-Reply-To: References: Message-ID: Hi Boris, thank you for the feedback. I have to admit that I was expecting that it will not be that easy :) I will try now to use the pre-built odb for windows, mac and linux and will have to see if I need to compile it myself for ARM and Android, but at least there I will have easier control over the gcc in the cross-compile environment (I hope ;) ) Unfortunately for Mac I can not use homebrew or macports atm. Thanks for now, I may get back later if needed ;) Lukas Boris Kolpackov schrieb am Do., 22. Sep. 2016 um 03:18 Uhr: > Hi Lukas, > > Lukas Obermann writes: > > > I am trying to build ODB on a Mac. I am integrating it into a existing > > build system, so I do want to avoid using the pre-built versions and get > > the build running, as it will also be build on Windows and Linux (will > test > > those next). > > I must warn you, Windows will be really hard (as in "patching GCC" hard). > > > > Executing a gcc --version gives me following: > > > > $ gcc --version > > Configured with: --prefix=/Applications/Xcode.app/Contents/Developer/usr > > --with-gxx-include-dir=/usr/include/c++/4.2.1 > > Apple LLVM version 7.3.0 (clang-703.0.31) > > Target: x86_64-apple-darwin15.6.0 > > Thread model: posix > > InstalledDir: > > > /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin > > This is actually not GCC, it is Apple's Clang pretending to be GCC. > > To build ODB from source on Mac OS you will need to build GCC with plugin > support enabled (--enable-plugin configure option). You could also try > GCC from homebrew though I am not sure if it's built with plugins enabled > these days. > > Boris > From leafless.matt at gmail.com Thu Sep 29 09:34:50 2016 From: leafless.matt at gmail.com (Matt Walker) Date: Thu Sep 29 10:26:56 2016 Subject: [odb-users] segfault in query in Fedora 24 Message-ID: Hi. I may be trying to get a little too bleeding edge here, but I thought I would try ;-) I'm attempting to integrate odb into a gtkmm3 application, no luck so far. I modified a snippet in the odb examples code, and and played around with things on a few different platforms to see where it was happy. I got it to run successfully on Centos 7, building libodb and libodb-mysql from source, with the packaged gcc 4.x. On Fedora 24, the odb dnf packages are available, and i installed libodb and libodb-mysql that way, but odb wanted a g++ downgrade (the default dnf version is 6.2.1), so I just grabbed the binary from code synthesis. I tried compiling in both C++11 and c++03 mode, it still seg faults on instantiating the query template object. I have attached the abrt backtrace to this email. void DataAccess::findAppUsers(string loginUser) { try { typedef odb::query query; typedef odb::result result; { transaction t (db->begin ()); db->query(query::ssoId == loginUser); result r (db->query(query::ssoId == loginUser)); for (result::iterator i (r.begin ()); i != r.end (); ++i) { cout << "Hello, " << i->getFirstName() << "!" << endl; } t.commit (); } } catch (const odb::exception& e) { cerr << "odb query is unhappy: " << e.what () << endl; } } The kernel version is 4.7.4-200. Any ideas? Thanks, Matt Walker -------------- next part -------------- A non-text attachment was scrubbed... Name: core_backtrace Type: application/octet-stream Size: 5371 bytes Desc: not available Url : http://codesynthesis.com/pipermail/odb-users/attachments/20160929/1cb3cefe/core_backtrace.obj From bruno at wexcedo.com Wed Sep 28 18:46:52 2016 From: bruno at wexcedo.com (Bruno Pereira) Date: Thu Sep 29 10:30:22 2016 Subject: [odb-users] Does odb iteract well with an async environment (boost::asio)? Message-ID: <15772faaaeb.fa20448a37721.2509359166776533752@wexcedo.com> I am currently working on a distributed systems project, that does heavy use of the boost::asio asynchronous functionality, as such i am looking for a way to interact with the database that fits well in this asynchronous environment, and uses modern c++11/14. I would like to know if odb has support for such an environment. Best Regards, Bruno Pereira From boris at codesynthesis.com Thu Sep 29 11:03:31 2016 From: boris at codesynthesis.com (Boris Kolpackov) Date: Thu Sep 29 11:03:41 2016 Subject: [odb-users] Does odb iteract well with an async environment (boost::asio)? In-Reply-To: <15772faaaeb.fa20448a37721.2509359166776533752@wexcedo.com> References: <15772faaaeb.fa20448a37721.2509359166776533752@wexcedo.com> Message-ID: Hi Bruno, Bruno Pereira writes: > I am currently working on a distributed systems project, that does heavy > use of the boost::asio asynchronous functionality, as such i am looking > for a way to interact with the database that fits well in this asynchronous > environment, and uses modern c++11/14. > > I would like to know if odb has support for such an environment. If you are looking for something like asynchronous database operation execution, then no, AFAIK, none of the database systems support by ODB expose anything like this in their low-level C APIs (recent versions of PG might, I vaguely remember reading something about that). But using ODB in async code itself should not cause any problems. Boris From boris at codesynthesis.com Thu Sep 29 11:18:28 2016 From: boris at codesynthesis.com (Boris Kolpackov) Date: Thu Sep 29 11:18:38 2016 Subject: [odb-users] segfault in query in Fedora 24 In-Reply-To: References: Message-ID: Hi Matt, Matt Walker writes: > On Fedora 24, the odb dnf packages are available, and i installed libodb > and libodb-mysql that way, but odb wanted a g++ downgrade (the default dnf > version is 6.2.1), so I just grabbed the binary from code synthesis. You mean you grabbed the ODB compiler binary, right? > I tried compiling in both C++11 and c++03 mode, it still seg faults on > instantiating the query template object. I have attached the abrt backtrace > to this email. This is a problem between your application and libodb* runtime libraries. I don't believe the ODB compiler is relevant here. And the stack trace looks like an ABI mismatch: https://gcc.gnu.org/onlinedocs/libstdc++/manual/using_dual_abi.html Can you make sure that your application and the libodb* libraries are compiler with the same version of GCC and with the same -std flag. As an aside, we like to make fun of Windows in this regard and look where we are. What a mess. Boris From leafless.matt at gmail.com Thu Sep 29 12:38:46 2016 From: leafless.matt at gmail.com (Matt Walker) Date: Thu Sep 29 12:44:41 2016 Subject: [odb-users] segfault in query in Fedora 24 In-Reply-To: References: Message-ID: Thanks Boris I grabbed the libodb and libodb-mysql source and built, now it works. That was pretty rude of the package maintainers at Fedora for not building on the default compiler ;-). I will try to find the appropriate mailing list and let them know. On Thu, Sep 29, 2016 at 10:18 AM, Boris Kolpackov wrote: > Hi Matt, > > Matt Walker writes: > > > On Fedora 24, the odb dnf packages are available, and i installed libodb > > and libodb-mysql that way, but odb wanted a g++ downgrade (the default > dnf > > version is 6.2.1), so I just grabbed the binary from code synthesis. > > You mean you grabbed the ODB compiler binary, right? > > > > I tried compiling in both C++11 and c++03 mode, it still seg faults on > > instantiating the query template object. I have attached the abrt > backtrace > > to this email. > > This is a problem between your application and libodb* runtime libraries. > I don't believe the ODB compiler is relevant here. And the stack trace > looks like an ABI mismatch: > > https://gcc.gnu.org/onlinedocs/libstdc++/manual/using_dual_abi.html > > Can you make sure that your application and the libodb* libraries are > compiler with the same version of GCC and with the same -std flag. > As an aside, we like to make fun of Windows in this regard and look > where we are. What a mess. > > Boris > From boris at codesynthesis.com Thu Sep 29 12:48:22 2016 From: boris at codesynthesis.com (Boris Kolpackov) Date: Thu Sep 29 12:48:37 2016 Subject: [odb-users] segfault in query in Fedora 24 In-Reply-To: References: Message-ID: Hi Matt, Matt Walker writes: > I grabbed the libodb and libodb-mysql source and built, now it works. That > was pretty rude of the package maintainers at Fedora for not building on > the default compiler ;-). Yeah, we seem to have the same issue with Ubuntu 16.04 packages. But soon it will all be behind us for good[1] ;-). > I will try to find the appropriate mailing list and let them know. The person you need is Dave Johansen (CC'ed). He maintains all the ODB packages for RH distributions. [1] https://build2.org/ Boris From leafless.matt at gmail.com Thu Sep 29 13:02:23 2016 From: leafless.matt at gmail.com (Matt Walker) Date: Thu Sep 29 13:17:56 2016 Subject: [odb-users] segfault in query in Fedora 24 In-Reply-To: References: Message-ID: Wow. That should make Poul-Henning Kamp and a bunch of other people very happy! Thanks again On Thu, Sep 29, 2016 at 11:48 AM, Boris Kolpackov wrote: > Hi Matt, > > Matt Walker writes: > > > I grabbed the libodb and libodb-mysql source and built, now it works. > That > > was pretty rude of the package maintainers at Fedora for not building on > > the default compiler ;-). > > Yeah, we seem to have the same issue with Ubuntu 16.04 packages. But soon > it will all be behind us for good[1] ;-). > > > > I will try to find the appropriate mailing list and let them know. > > The person you need is Dave Johansen (CC'ed). He maintains all the ODB > packages for RH distributions. > > > [1] https://build2.org/ > > Boris > From tiagomacarios at gmail.com Fri Sep 30 14:39:00 2016 From: tiagomacarios at gmail.com (Tiago Macarios) Date: Fri Sep 30 14:39:12 2016 Subject: [odb-users] Compilation errors Message-ID: Hi Boris, hope all is well. I am getting a compilation error on Windows, was wondering if you saw this before. odb\details\shared-ptr\base.cxx(57): error C2220: warning treated as error - no 'object' file generated odb\details\shared-ptr\base.cxx(57): warning C4290: C++ exception specification ignored except to indicate a function is not __declspec(nothrow) Here is the offending piece of code: void* operator new (size_t n, odb::details::share s) throw (std::bad_alloc) >From my naive googling around (please correct me if I am wrong), but looks like microsoft does not support that construct since it is not enforceable: https://msdn.microsoft.com/en-us/library/sa28fef8.aspx And the c++ standard deprecated that syntax in favor of noexcept: http://en.cppreference.com/w/cpp/language/function Thanks, Tiago