From d.patrushev at prosoftsystems.ru Thu Nov 2 09:23:49 2017 From: d.patrushev at prosoftsystems.ru (=?koi8-r?B?8MHU0tXbxdcg5MHOycwg4c7E0sXF18ne?=) Date: Thu Nov 2 09:24:09 2017 Subject: [odb-users] query crash Message-ID: Hi, we are developing an app which uses odb for database interaction. The problem that we facing is sporadic crashes with the stacktrace showing that the program stops inside odb :: pgsql :: query functions, specifically in code dealing with the "parameters_" class member. Here's the pattern we are using: 1) create a query object in thread number 1 2) create a functor (say, lambda) containing the code to execute a database request and copy the query object into the functor 3) launch a worker thread and call the functor within that thread's context. 4) pass the result back to thread number 1 Is it safe to use odb:: pgsql::query in this manner? ? ?????????, ???????-??????????? ??? ???????? ????? ????????? From boris at codesynthesis.com Thu Nov 2 09:33:45 2017 From: boris at codesynthesis.com (Boris Kolpackov) Date: Thu Nov 2 09:33:56 2017 Subject: [odb-users] query crash In-Reply-To: References: Message-ID: ???????? ????? ????????? writes: > 1) create a query object in thread number 1 > > 2) create a functor (say, lambda) containing the code to execute a database request and copy the query object into the functor > > 3) launch a worker thread and call the functor within that thread's context. > > 4) pass the result back to thread number 1 > > Is it safe to use odb:: pgsql::query in this manner? Probably not. To be more precise I would need more details (maybe code samples for each step). For example, what is a "query object"? A prepared query or just the query condition? Also, what's happening with transactions/connections during all of this? Are you passing them as well or create new ones in respective threads (the latter would definitely be a bad idea since the result is "bound" to the connection of the query). Boris From asnagni at yahoo.com Thu Nov 2 22:40:19 2017 From: asnagni at yahoo.com (Alain-SergeNagni) Date: Thu Nov 2 22:40:41 2017 Subject: [odb-users] Need help with ODB exception Message-ID: <87F52B9F-E2A0-49C1-85C4-8821F5504790@yahoo.com> Hi guys, I'm having some exceptions with ODB class mapping . I'm using Postgres for the database. This is the output of the exception: odb::exception 42601:ERROR: Syntax error at or near ")" Line 1: ... Le "index" = "CMe"."index" where "CMe"."strHasValue" IN () I'm not sure about the root cause of this his kind of problem. Any help would be appreciated. Thank you in advance. Alain-Serge Nagni Sent from my iPad From d.patrushev at prosoftsystems.ru Fri Nov 3 02:11:44 2017 From: d.patrushev at prosoftsystems.ru (=?koi8-r?B?8MHU0tXbxdcg5MHOycwg4c7E0sXF18ne?=) Date: Fri Nov 3 02:12:04 2017 Subject: [odb-users] query crash In-Reply-To: References: , Message-ID: <959b5f789ea44dcd8c27755722d9da5d@prosoftsystems.ru> > 1) create a query object in thread number 1 > > 2) create a functor (say, lambda) containing the code to execute a database request and copy the query object into the functor > > 3) launch a worker thread and call the functor within that thread's context. > > 4) pass the result back to thread number 1 > > Is it safe to use odb:: pgsql::query in this manner? >Probably not. To be more precise I would need more details (maybe code >samples for each step). For example, what is a "query object"? A prepared >query or just the query condition? > >Also, what's happening with transactions/connections during all of this? >Are you passing them as well or create new ones in respective threads >(the latter would definitely be a bad idea since the result is "bound" >to the connection of the query). Hi, Boris. I'll elaborate. We have a single instance of odb::pgsql::database. We have a custom connection pool, all it does is override the "create" method which creates a connection with the socket options that we need. 1) odb::query q(MYTABLE::rowid == 555); // create query in main thread 2) auto functor = [q](){//copy query into the lambda odb::database* db = database(); //single instance odb::transaction tran(db->begin()); auto result = db->query(q); //iterate over result and construct a list of db objects; tran.commit(); return list_of_db_objects; }; See, by result I mean a list of objects extracted from odb::result; 3) auto future = QtConcurrent::run(functor); //(I quess you are familiar with the Qt framework) We launch a worker thread and wait for the finished signal (the original query gets destroyed along the way) 4) The functor gets executed in the worker thread's context . After the finished signal is emitted, we extract the result from the future by calling future->result() in main thread; I quess that if odb::pgsql::query class is not thread-safe, then we are wrong to use it this way . BTW, in case I have broken any formatting conventions (I guess, I have), please, show me where I can read about them. Thank you. From boris at codesynthesis.com Fri Nov 3 05:23:42 2017 From: boris at codesynthesis.com (Boris Kolpackov) Date: Fri Nov 3 05:30:30 2017 Subject: [odb-users] query crash In-Reply-To: <959b5f789ea44dcd8c27755722d9da5d@prosoftsystems.ru> References: <959b5f789ea44dcd8c27755722d9da5d@prosoftsystems.ru> Message-ID: ???????? ????? ????????? writes: > We have a single instance of odb::pgsql::database. We have a custom > connection pool, all it does is override the "create" method which > creates a connection with the socket options that we need. > > 1) odb::query q(MYTABLE::rowid == 555); // create query in main thread > > 2) auto functor = [q](){//copy query into the lambda > odb::database* db = database(); //single instance > odb::transaction tran(db->begin()); > auto result = db->query(q); > //iterate over result and construct a list of db objects; > tran.commit(); > return list_of_db_objects; > }; > > See, by result I mean a list of objects extracted from odb::result; > > 3) auto future = QtConcurrent::run(functor); //(I quess you are familiar with the Qt framework) > We launch a worker thread and wait for the finished signal (the original > query gets destroyed along the way) > > 4) The functor gets executed in the worker thread's context. After the > finished signal is emitted, we extract the result from the future by > calling future->result() in main thread; > > I quess that if odb::pgsql::query class is not thread-safe, then we are > wrong to use it this way . No, this should work provided you don't have by-reference parameters in your query which you initialize concurrently from multiple threads. Quoting the manual, Section 4.3, "Executing a Query": "A named query instance that does not have any by-reference parameters is immutable and can be shared between multiple threads without synchronization. On the other hand, a query instance with by-reference parameters is modified every time it is executed. If such a query is shared among multiple threads, then access to this query instance must be synchronized from the execution point and until the completion of the iteration over the result." If this is not the issue, can you show the stack trace? Boris From d.patrushev at prosoftsystems.ru Fri Nov 3 07:58:34 2017 From: d.patrushev at prosoftsystems.ru (=?windows-1251?B?z+Dy8PP45eIgxODt6OsgwO3k8OXl4uj3?=) Date: Fri Nov 3 07:58:46 2017 Subject: [odb-users] query crash In-Reply-To: References: <959b5f789ea44dcd8c27755722d9da5d@prosoftsystems.ru>, Message-ID: <737a12ed09bb4240b8e925345df51cd9@prosoftsystems.ru> ? ?????????, ???????-??????????? ??? ????????-???????? ???????? ????? ????????? ________________________________________ ??: Boris Kolpackov ??????????: 3 ?????? 2017 ?. 14:23 ????: ???????? ????? ????????? ?????: odb-users@codesynthesis.com ????: Re: [odb-users] query crash ???????? ????? ????????? writes: > We have a single instance of odb::pgsql::database. We have a custom > connection pool, all it does is override the "create" method which > creates a connection with the socket options that we need. > > 1) odb::query q(MYTABLE::rowid == 555); // create query in main thread > > 2) auto functor = [q](){//copy query into the lambda > odb::database* db = database(); //single instance > odb::transaction tran(db->begin()); > auto result = db->query(q); > //iterate over result and construct a list of db objects; > tran.commit(); > return list_of_db_objects; > }; > > See, by result I mean a list of objects extracted from odb::result; > > 3) auto future = QtConcurrent::run(functor); //(I quess you are familiar with the Qt framework) > We launch a worker thread and wait for the finished signal (the original > query gets destroyed along the way) > > 4) The functor gets executed in the worker thread's context. After the > finished signal is emitted, we extract the result from the future by > calling future->result() in main thread; > > I quess that if odb::pgsql::query class is not thread-safe, then we are > wrong to use it this way . >No, this should work provided you don't have by-reference parameters >in your query which you initialize concurrently from multiple threads. >Quoting the manual, Section 4.3, "Executing a Query": >"A named query instance that does not have any by-reference parameters is >immutable and can be shared between multiple threads without >synchronization. On the other hand, a query instance with by-reference >parameters is modified every time it is executed. If such a query is shared >among multiple threads, then access to this query instance must be >synchronized from the execution point and until the completion of the >iteration over the result." > >If this is not the issue, can you show the stack trace? > > Boris Unfortunately, no exact stacktrace at hand. But I can say that the latest crash happened during the destruction of query_base, specifically its "parameters_" member, which is of std::vector > type, the topmost line in the trace being void dec (Y* p) { if (static_cast (p)->_dec_ref ()) delete p; } which is contained in file "odb/details/shared-ptr/base.txx" "delete p " is where the program crashed. So I thought that there just might be a problem with details::shared_ptr, something along the lines of thread-safe increment and decrement of the shared pointer's counter. Just a wild guess. Most of the previous crashes were in "init_parameters" of base_query (all query parameters taken by value, by the way). We checked and rechecked the code, but still have no idea why this is happening From boris at codesynthesis.com Fri Nov 3 08:54:33 2017 From: boris at codesynthesis.com (Boris Kolpackov) Date: Fri Nov 3 08:54:45 2017 Subject: [odb-users] query crash In-Reply-To: <737a12ed09bb4240b8e925345df51cd9@prosoftsystems.ru> References: <959b5f789ea44dcd8c27755722d9da5d@prosoftsystems.ru> <737a12ed09bb4240b8e925345df51cd9@prosoftsystems.ru> Message-ID: ???????? ????? ????????? writes: > Unfortunately, no exact stacktrace at hand. But I can say that the latest > crash happened during the destruction of query_base, specifically its > "parameters_" member, which is of std::vector > > type, the topmost line in the trace being > > void dec (Y* p) > { > if (static_cast (p)->_dec_ref ()) > delete p; > } > which is contained in file "odb/details/shared-ptr/base.txx" > > "delete p " is where the program crashed. > > So I thought that there just might be a problem with details::shared_ptr, > something along the lines of thread-safe increment and decrement of the > shared pointer's counter. Just a wild guess. Yes, this is helpful information, thanks. I will look closer into this. In the meantime, a temporary workaround could be to move the query condition into the lambda (so that you don't have copies). Boris From boris at codesynthesis.com Fri Nov 3 08:57:36 2017 From: boris at codesynthesis.com (Boris Kolpackov) Date: Fri Nov 3 08:57:47 2017 Subject: [odb-users] Need help with ODB exception In-Reply-To: <87F52B9F-E2A0-49C1-85C4-8821F5504790@yahoo.com> References: <87F52B9F-E2A0-49C1-85C4-8821F5504790@yahoo.com> Message-ID: Alain-SergeNagni writes: > Line 1: ... Le "index" = "CMe"."index" where "CMe"."strHasValue" IN () This is most likely caused by passing an empty container to the in_range() predicate. We have a fix for this for the next release. Boris From asnagni at yahoo.com Fri Nov 3 13:21:16 2017 From: asnagni at yahoo.com (Alain-Serge Magnitude) Date: Fri Nov 3 13:21:48 2017 Subject: [odb-users] Need help with ODB exception In-Reply-To: References: <87F52B9F-E2A0-49C1-85C4-8821F5504790@yahoo.com> Message-ID: <946347D8-0808-4927-91DB-F0855CC25891@yahoo.com> Hi Boris, Thank you for the reply. Do you know when the next release will be out? Thank you, Alain-Serge Sent from my iPhone > On Nov 3, 2017, at 8:57 AM, Boris Kolpackov wrote: > > Alain-SergeNagni writes: > >> Line 1: ... Le "index" = "CMe"."index" where "CMe"."strHasValue" IN () > > This is most likely caused by passing an empty container to the in_range() > predicate. We have a fix for this for the next release. > > Boris From topolewr at cooley.edu Sun Nov 5 22:33:50 2017 From: topolewr at cooley.edu (Richard Topolewski) Date: Sun Nov 5 22:34:11 2017 Subject: [odb-users] =?utf-8?q?ixx=3A_error=3A_no_matching_function_for_c?= =?utf-8?b?YWxsIHRvIOKAmG9kYjo6YWNjZXNzOjpvYmplY3RfdHJhaXRzPEJhc2U+?= =?utf-8?b?OjppZChjb25zdCBvYmplY3RfdHlwZSYp4oCZ?= Message-ID: I have been struggling with the problem all day. I can get various different errors depending on what includes I do, but the crux of what I believe I don't understand is why the compiling of a derived class complains it can?t find some ODB functions that it needs regarding the base class? In addition, I will mention that the derived class is to save someone ODB persistent objects, the details of which are excluded because I don't think they are relevant. If any further information is needed to help flush out this problem please let me know, I can provide them. -- Rich I have a base class Base.cpp with #pragma db object polymorphic and derived class is Base_plus.cpp with #pragma db object when compiling Base_plus.cpp it gives these error: In file included from Base_plus-odb.hxx:396:0, from Base_plus.h:25, from Base_plus.cpp:11: Base_plus-odb.ixx: In static member function ?static odb::access::object_traits::id_type odb::access::object_traits::id(const object_type&)?: Base_plus-odb.ixx:15:44: error: no matching function for call to ?odb::access::object_traits::id(const object_type&)? return object_traits< ::Base >::id (o); ^ In file included from Base-odb.hxx:332:0, from Base_plus-odb.hxx:22, from Base_plus.h:25, from Base_plus.cpp:11: Base-odb.ixx:12:3: note: candidate: static odb::access::object_traits::id_type odb::access::object_traits::id(const object_type&) access::object_traits< ::Base >:: ^ Base-odb.ixx:12:3: note: no known conversion for argument 1 from ?const object_type {aka const Base_plus}? to ?const object_type& {aka const Base&}? From boris at codesynthesis.com Mon Nov 6 06:52:01 2017 From: boris at codesynthesis.com (Boris Kolpackov) Date: Mon Nov 6 06:52:15 2017 Subject: [odb-users] query crash In-Reply-To: References: <959b5f789ea44dcd8c27755722d9da5d@prosoftsystems.ru> <737a12ed09bb4240b8e925345df51cd9@prosoftsystems.ru> Message-ID: ???????? ????? ????????? writes: > So I thought that there just might be a problem with details::shared_ptr, > something along the lines of thread-safe increment and decrement of the > shared pointer's counter. Just a wild guess. Ok, I've pushed the fix to libodb: https://git.codesynthesis.com/cgit/odb/libodb/commit/?id=702c5756d5a2050327603cb9e507c839f928a7a3 It is a small patch (use the 'patch' link next to the commit id) and you should be able to apply it to the current version of libodb. Alternatively, I can build you a pre-release. Let me know if there are still any issues and thanks for the bug report as well as the analysis! Boris From boris at codesynthesis.com Mon Nov 6 07:00:53 2017 From: boris at codesynthesis.com (Boris Kolpackov) Date: Mon Nov 6 07:01:03 2017 Subject: [odb-users] Need help with ODB exception In-Reply-To: <946347D8-0808-4927-91DB-F0855CC25891@yahoo.com> References: <87F52B9F-E2A0-49C1-85C4-8821F5504790@yahoo.com> <946347D8-0808-4927-91DB-F0855CC25891@yahoo.com> Message-ID: Alain-Serge Magnitude writes: > Do you know when the next release will be out? We are working on it but there is no definitive time-frame. Probably early next year. Pre-releases are available, however (latest is b.3): https://codesynthesis.com/~boris/tmp/odb/pre-release/ Boris From asnagni at yahoo.com Mon Nov 6 12:48:03 2017 From: asnagni at yahoo.com (Alain-Serge Magnitude) Date: Mon Nov 6 12:48:27 2017 Subject: [odb-users] Need help with ODB exception In-Reply-To: References: <87F52B9F-E2A0-49C1-85C4-8821F5504790@yahoo.com> <946347D8-0808-4927-91DB-F0855CC25891@yahoo.com> Message-ID: <3807102B-43F3-4608-866D-C3DAD2317A62@yahoo.com> Hi Boris, Thank you for the information. Alain-Serge Sent from my iPhone > On Nov 6, 2017, at 7:00 AM, Boris Kolpackov wrote: > > Alain-Serge Magnitude writes: > >> Do you know when the next release will be out? > > We are working on it but there is no definitive time-frame. Probably > early next year. Pre-releases are available, however (latest is b.3): > > https://codesynthesis.com/~boris/tmp/odb/pre-release/ > > Boris From topolewr at cooley.edu Tue Nov 7 06:47:17 2017 From: topolewr at cooley.edu (Richard Topolewski) Date: Tue Nov 7 06:47:37 2017 Subject: [odb-users] RE: ixx: error: no matching function for call to ?odb::access::object_traits::id(const object_type&)? Message-ID: > I don't understand is why the compiling of a derived class > complains it can?t find some ODB functions that it needs regarding the base > class? > I have a base class Base.cpp with #pragma db object polymorphic > and derived class is Base_plus.cpp with #pragma db object > when compiling Base_plus.cpp it gives these error: ... > In file included from Base-odb.hxx:332:0, > from Base_plus-odb.hxx:22, > from Base_plus.h:25, > from Base_plus.cpp:11: > Base-odb.ixx:12:3: note: candidate: static > odb::access::object_traits::id_type > odb::access::object_traits::id(const object_type&) > access::object_traits< ::Base >:: > Base-odb.ixx:12:3: note: no known conversion for argument 1 from ?const > object_type {aka const Base_plus}? to ?const object_type& {aka const Base&}? I was able to resolve this by moving the include of the Base-odb.hxx and the Base-plus-odb.hxx to the bottom of my header file. I believe I had a forward class definition (i.e. "class Base;") as opposed to the complete class definition at the point where the -odb.hxx was being included that was causing problems. Moving the include till after the header definition of the class seemed to resolve the issue. From ps.georgiou at gmail.com Tue Nov 7 07:28:30 2017 From: ps.georgiou at gmail.com (Panayiotis Georgiou) Date: Tue Nov 7 07:28:48 2017 Subject: [odb-users] using ODB for interactive access Message-ID: Hello, We are developing a GUI application with Qt which uses an sqlite database mapped with ODB. The application is developed using Qt's Model/View Delegate approach, where the View corresponds to the forms/dialogs presented to the user and the Model's handle the data presented by the views. In order to avoid having multiple copies (possibly out-of-sync) of the data in memory the models do not hold any data but directly operate on the database. For example when a view requests a particular record, then the model will load it and pass it to the view. Similarly, if the view edits a record, then the model will directly apply the changes to the database and then trigger a refresh of the view. Although this approach keeps the data presented by the view always in sync with the database, this approach seems very slow for interactive use. For example. clicking on a cell on the table-view to edit it might take maybe 1-2 seconds to respond. So my question is: How can this be made faster for interactive use? Is there a way of keeping the database open in main-memory for faster access (our database is relatively small)? Any suggestions will be appreciated. Thanks for your help, Panayiotis. From christ_emily at 163.com Tue Nov 7 07:17:07 2017 From: christ_emily at 163.com (christ_emily) Date: Tue Nov 7 08:35:36 2017 Subject: [odb-users] ODB PostGIS? Message-ID: <4a1b5c.13137.15f9669a6cf.Coremail.christ_emily@163.com> Hello, I am learning ODB these days. My application need to store spatial data, but from ODB manual I can't find the example for that. If ODB support the spatial data in PostGIS, please send me the examples. Thanks very much! emily From boris at codesynthesis.com Tue Nov 7 08:42:05 2017 From: boris at codesynthesis.com (Boris Kolpackov) Date: Tue Nov 7 08:42:16 2017 Subject: [odb-users] using ODB for interactive access In-Reply-To: References: Message-ID: Panayiotis Georgiou writes: > Although this approach keeps the data presented by the view always in sync > with the database, this approach seems very slow for interactive use. For > example. clicking on a cell on the table-view to edit it might take maybe > 1-2 seconds to respond. > > [...] (our database is relatively small) I am very surprised by this. With SQLite a read operation on a small database definitely shouldn't take seconds. I think there is something else going on. The only plausible explanation that I can think of would be locking in heavy concurrent access but I doubt you have that. Try to isolate the equivalent database access logic into a separate test and see how it measures. Boris From boris at codesynthesis.com Tue Nov 7 08:45:50 2017 From: boris at codesynthesis.com (Boris Kolpackov) Date: Tue Nov 7 08:46:03 2017 Subject: [odb-users] ODB PostGIS? In-Reply-To: <4a1b5c.13137.15f9669a6cf.Coremail.christ_emily@163.com> References: <4a1b5c.13137.15f9669a6cf.Coremail.christ_emily@163.com> Message-ID: christ_emily writes: > My application need to store spatial data, but from ODB manual I can't > find the example for that. If ODB support the spatial data in PostGIS, > please send me the examples. ODB doesn't have out-of-the-box support for PostGIS though you can map suitable C++ types to PostGIS types as described in this article: https://www.codesynthesis.com/~boris/blog/2012/07/18/custom-database-to-cxx-type-mapping-in-odb/ See also the pgsql/custom/ test in the odb-tests package for some examples. Boris From d.patrushev at prosoftsystems.ru Tue Nov 7 10:39:58 2017 From: d.patrushev at prosoftsystems.ru (=?koi8-r?B?8MHU0tXbxdcg5MHOycwg4c7E0sXF18ne?=) Date: Tue Nov 7 10:40:19 2017 Subject: [odb-users] query crash In-Reply-To: References: <959b5f789ea44dcd8c27755722d9da5d@prosoftsystems.ru> <737a12ed09bb4240b8e925345df51cd9@prosoftsystems.ru> , Message-ID: <96a11ff163aa4563bed2de893683a355@prosoftsystems.ru> >Ok, I've pushed the fix to libodb: > >https://git.codesynthesis.com/cgit/odb/libodb/commit/?id=702c5756d5a2050327603cb9e507c839f928a7a3 > >It is a small patch (use the 'patch' link next to the commit id) and you >should be able to apply it to the current version of libodb. Alternatively, >I can build you a pre-release. > >Let me know if there are still any issues and thanks for the bug report >as well as the analysis! > >Boris Hi, Boris. Thank you so much for the job. We have incorporated your fix, and will now be watching closely if anything comes up. From ps.georgiou at gmail.com Tue Nov 7 12:10:47 2017 From: ps.georgiou at gmail.com (Panayiotis Georgiou) Date: Tue Nov 7 12:11:06 2017 Subject: [odb-users] using ODB for interactive access In-Reply-To: References: Message-ID: Hi Boris, Thanks for the reply. I have profiled my code to get some sense what is the increase in time when operating directly on the database compared to holding the data in memory in a data-structure for a simple table. From the test, it seems that the database access is not the bottleneck causing the issue although there is some expected increase in times. For comparison here are the results: The functions affected by the implementation of our QAbstractItemModel were the rowCount() [counts the records in a query] and data() [reads the data at a particular column of a record]. * For 1000 records accessed directly from the database: rowCount() - 190ms data() - 160ms * For 1000 records accessed from a dynamic data-structure in-memory: rowCount() - 0.003ms data() - 5ms As you can see, there is an increase but it should be negligible for a single access (order of 0.2ms per request ). I think it's in fact Qt that makes unnecessarily large amounts of requests. Running the code in Release rather than debug and outside VisualStudio has also helped significantly. Thanks, Panayiotis. On Tue, Nov 7, 2017 at 1:42 PM, Boris Kolpackov wrote: > Panayiotis Georgiou writes: > > > Although this approach keeps the data presented by the view always in > sync > > with the database, this approach seems very slow for interactive use. For > > example. clicking on a cell on the table-view to edit it might take maybe > > 1-2 seconds to respond. > > > > [...] (our database is relatively small) > > I am very surprised by this. With SQLite a read operation on a small > database definitely shouldn't take seconds. I think there is something > else going on. The only plausible explanation that I can think of would > be locking in heavy concurrent access but I doubt you have that. > > Try to isolate the equivalent database access logic into a separate > test and see how it measures. > > Boris > From d.patrushev at prosoftsystems.ru Wed Nov 8 05:20:21 2017 From: d.patrushev at prosoftsystems.ru (=?koi8-r?B?8MHU0tXbxdcg5MHOycwg4c7E0sXF18ne?=) Date: Wed Nov 8 05:20:34 2017 Subject: [odb-users] strange lazy section Message-ID: <60961745d6a0462aaa0986331605cfad@prosoftsystems.ru> Hi, we are observing strange behavior of lazy loaded sections. The content of a lazy loaded QByteArray, in case its length exceeds 256 bytes, seems to be corrupted. With eager loading enabled, the section is loaded as expected. Code: #pragma db object struct DbObject { #pragma db id auto quint64 id; #pragma db load(lazy) odb::section extras_; #pragma db section(extras_) QByteArray content; }; void persist(DbObject& obj1, DbObject& obj2) { odb::pgsql::database connection(//database connection details); odb::transaction tran(connection.begin()); connection.persist(obj1); connection.persist(obj2); tran.commit(); } void read() { odb::pgsql::database connection(//database connection details); odb::transaction tran(connection.begin()); odb::result result(connection.query()); std::vector object_list; for(const auto& obj : result) object_list.push_back(obj); tran.commit(); //load section, print size, first and last byte of array // short array (less than 256) - 's' first, 't' last //long array (over 256) - should be 'a' first, 'z' last, but it's not the case auto load_section_func = [&connection](DbObject& b){ odb::transaction tran(connection.begin()); connection.load(b, b.extras_); qDebug()< References: <60961745d6a0462aaa0986331605cfad@prosoftsystems.ru> Message-ID: ???????? ????? ????????? writes: > Hi, we are observing strange behavior of lazy loaded sections. The > content of a lazy loaded QByteArray, in case its length exceeds 256 > bytes, seems to be corrupted. With eager loading enabled, the section > is loaded as expected. This is a known bug that has been fixed for the next release. You can get the pre-release with the fix here: https://codesynthesis.com/~boris/tmp/odb/pre-release/b.3/ Note that you will still need to apply that shared_ptr patch we discussed earlier. Boris From boris at codesynthesis.com Wed Nov 8 07:49:13 2017 From: boris at codesynthesis.com (Boris Kolpackov) Date: Wed Nov 8 07:49:24 2017 Subject: [odb-users] using ODB for interactive access In-Reply-To: References: Message-ID: Panayiotis Georgiou writes: > The functions affected by the implementation of our QAbstractItemModel were > the rowCount() [counts the records in a query] and data() [reads the data > at a particular column of a record]. > > * For 1000 records accessed directly from the database: > rowCount() - 190ms > data() - 160ms FWIW, these still look rather high to me, especially if this is for an optimized build. For comparison, running the hello example, as in, the entire executable, which creates the database and performs a bunch of database operations and queries -- all that takes 50ms on my machine. Boris From d.patrushev at prosoftsystems.ru Wed Nov 8 08:01:31 2017 From: d.patrushev at prosoftsystems.ru (=?koi8-r?B?8MHU0tXbxdcg5MHOycwg4c7E0sXF18ne?=) Date: Wed Nov 8 08:01:42 2017 Subject: [odb-users] strange lazy section In-Reply-To: References: <60961745d6a0462aaa0986331605cfad@prosoftsystems.ru>, Message-ID: <79e4df5e05124eb09a3ff85269584b87@prosoftsystems.ru> > Hi, we are observing strange behavior of lazy loaded sections. The > content of a lazy loaded QByteArray, in case its length exceeds 256 > bytes, seems to be corrupted. With eager loading enabled, the section > is loaded as expected. >This is a known bug that has been fixed for the next release. You can >get the pre-release with the fix here: > >https://codesynthesis.com/~boris/tmp/odb/pre-release/b.3/ > >Note that you will still need to apply that shared_ptr patch we discussed >earlier. > >Boris Got it. Thanks, Boris From obermann.lukas at gmail.com Wed Nov 8 08:09:30 2017 From: obermann.lukas at gmail.com (Lukas Obermann) Date: Wed Nov 8 08:09:50 2017 Subject: [odb-users] MySQL 5.7 ORDER BY clause is not in SELECT list Message-ID: Hello, I have a big view which joins in a lot of tables and just return the id of the ?main? table. But, I need to order the response based on different values which are joined in. So I just append ?ORDER BY ?+column to the query. Now, since MySQL 5.7 there was a constraint added that the field used in the order by must be present in the select list. So the query resulsts in following error: 3065 (HY000): Expression #1 of ORDER BY clause is not in SELECT list, references column 'common.fileView.lastPlayed_ulong_date' which is not in SELECT list; this is incompatible with DISTINCT Is there a way to work around this without having to modify the mysql mode on the server? So to either dynamically add the field to the select list or is there a special call to use for ordering? Of course I do not want to add all the fields to the select list as it would take forever to query then. Thanks, Lukas From boris at codesynthesis.com Wed Nov 8 09:04:34 2017 From: boris at codesynthesis.com (Boris Kolpackov) Date: Wed Nov 8 09:04:45 2017 Subject: [odb-users] MySQL 5.7 ORDER BY clause is not in SELECT list In-Reply-To: References: Message-ID: Lukas Obermann writes: > I have a big view which joins in a lot of tables and just return the id > of the ?main? table. But, I need to order the response based on different > values which are joined in. So I just append ?ORDER BY ?+column to the > query. > > Now, since MySQL 5.7 there was a constraint added that the field used in > the order by must be present in the select list. Uh, that's quite user-unfriendly of them. > Is there a way to work around this without having to modify the mysql > mode on the server? You mean you can change the MySQL configuration to allow this? If so, this is the best solution, IMO. > So to either dynamically add the field to the select list or is there > a special call to use for ordering? No, there is nothing like this. And it is unlikely we will be trying to work around this in ODB in the future. This is just MySQL brain-death. > Of course I do not want to add all the fields to the select list as > it would take forever to query then. The only other option is to create a separate view for each column that you want to order by. Boris From lists at tinloaf.de Wed Nov 8 09:11:41 2017 From: lists at tinloaf.de (Lukas Barth) Date: Wed Nov 8 09:12:02 2017 Subject: [odb-users] Query on many-to-one for "contains an object with property X" Message-ID: <7df5a5bc-f99f-f15f-5062-e7f24794d76e@tinloaf.de> Hi, in my database model I have a many-to-one relationship between A and B, with multiple B being associated with one A. The inverse field is declared, something along the lines of: ==================== snip ==================== #pragma db object class B { int value; #pragma db not_null shared_ptr a; ? }; #pragma db object class A { #pragma db inverse(a) std::vector> bs; ? }; ==================== snip ==================== I now want to query for all As that have a B with a value of 42 associated with them. I can't find the syntax for that (if that's possible) in the documentation. I would assume that I can access "bs" as as a field of A, but then I would need a "contains" operator and something to build the nested query, something along the lines of this: db.query (query::bs->contains( query(query::value == 42) )) Is something like this possible? Thanks a lot! Lukas From ps.georgiou at gmail.com Wed Nov 8 09:15:49 2017 From: ps.georgiou at gmail.com (Panayiotis Georgiou) Date: Wed Nov 8 09:16:07 2017 Subject: [odb-users] using ODB for interactive access In-Reply-To: References: Message-ID: Hi Boris, The timings I have mentioned are for 1000 calls to each function. A single call to rowCount() performs a "select all" query, and a single call to data() performs a "select all" query and then returns the N-th record from the query result. So a single call to each of this functions takes less than ~0.2ms. Is this still too high? Thanks. On Wed, Nov 8, 2017 at 12:49 PM, Boris Kolpackov wrote: > Panayiotis Georgiou writes: > > > The functions affected by the implementation of our QAbstractItemModel > were > > the rowCount() [counts the records in a query] and data() [reads the data > > at a particular column of a record]. > > > > * For 1000 records accessed directly from the database: > > rowCount() - 190ms > > data() - 160ms > > FWIW, these still look rather high to me, especially if this is for an > optimized build. For comparison, running the hello example, as in, the > entire executable, which creates the database and performs a bunch of > database operations and queries -- all that takes 50ms on my machine. > > Boris > > From boris at codesynthesis.com Wed Nov 8 11:16:48 2017 From: boris at codesynthesis.com (Boris Kolpackov) Date: Wed Nov 8 11:17:01 2017 Subject: [odb-users] using ODB for interactive access In-Reply-To: References: Message-ID: Panayiotis Georgiou writes: > The timings I have mentioned are for 1000 calls to each function. A single > call to rowCount() performs a "select all" query, and a single call to > data() performs a "select all" query and then returns the N-th record from > the query result. So a single call to each of this functions takes less > than ~0.2ms. Is this still too high? No, now it makes sense. I thought there were 1000 records in the database. Boris From boris at codesynthesis.com Wed Nov 8 11:28:10 2017 From: boris at codesynthesis.com (Boris Kolpackov) Date: Wed Nov 8 11:28:20 2017 Subject: [odb-users] Query on many-to-one for "contains an object with property X" In-Reply-To: <7df5a5bc-f99f-f15f-5062-e7f24794d76e@tinloaf.de> References: <7df5a5bc-f99f-f15f-5062-e7f24794d76e@tinloaf.de> Message-ID: Lukas Barth writes: > #pragma db object > class B > { > int value; > > #pragma db not_null > shared_ptr a; > ? > }; > > #pragma db object > class A > { > #pragma db inverse(a) > std::vector> bs; > ? > }; > > I now want to query for all As that have a B with a value of 42 associated > with them. I can't find the syntax for that (if that's possible) in the > documentation. I would assume that I can access "bs" as as a field of A, but > then I would need a "contains" operator and something to build the nested > query, something along the lines of this: > > db.query (query::bs->contains( query(query::value == 42) )) Yes, using containers in query conditions is not yet supported (though it's on a TODO list). The way you can achieve this now is with an object loading view. I.e., join the two objects in a view, load A, and in the query condition use B::value. Plus you will probably want the distinct clause. The manual has more information and some examples. Boris From dieter.govaerts at bricsys.com Thu Nov 9 04:45:45 2017 From: dieter.govaerts at bricsys.com (Dieter Govaerts) Date: Thu Nov 9 04:46:04 2017 Subject: [odb-users] Query only intermediate polymorphic objects Message-ID: <1510220745.21044691@apps.rackspace.com> Hello, Assume I have following persistent class hierarchy: Base (abstract) | +- DerivedA | +- DerivedB How can I query (with and without view) only the objects of type "DerivedA"? For example, I would like to query all ids of objects of type DerivedA but not of type DerivedB (explicitly excluding objects of type DerivedB is not an option as the hierarchy much more complex and under development): #pragma db view object(DerivedA) struct DerivedAIdView { unsigned id; }; odb::result r(db()->query()); Regards, Dieter From boris at codesynthesis.com Thu Nov 9 10:29:53 2017 From: boris at codesynthesis.com (Boris Kolpackov) Date: Thu Nov 9 10:30:05 2017 Subject: [odb-users] Query only intermediate polymorphic objects In-Reply-To: <1510220745.21044691@apps.rackspace.com> References: <1510220745.21044691@apps.rackspace.com> Message-ID: Dieter Govaerts writes: > Base (abstract) > | > +- DerivedA > | > +- DerivedB > > How can I query (with and without view) only the objects of type "DerivedA"? > > For example, I would like to query all ids of objects of type DerivedA but > not of type DerivedB: > > #pragma db view object(DerivedA) > struct DerivedAIdView > { > unsigned id; > }; > > odb::result r(db()->query()); At the end of Section 8.2, "Polymorphism Inheritance" there is this sentence: "Currently, the discriminator column is always called typeid and contains a namespace-qualified class name (for example, 'employee' or 'hr::employee')." This is undocumented, but that column is also available in the query object and is called 'typeid_'. You can use this information to restrict the types of objects you are getting, for example: using DerivedAIdQuery = odb::query odb::result r( db()->query( DerivedAIdQuery::typeid_ == "DerivedA")); Boris From dieter.govaerts at bricsys.com Thu Nov 9 11:27:12 2017 From: dieter.govaerts at bricsys.com (Dieter Govaerts) Date: Thu Nov 9 11:27:30 2017 Subject: [odb-users] Query only intermediate polymorphic objects In-Reply-To: References: <1510220745.21044691@apps.rackspace.com> Message-ID: <1510244832.964312771@apps.rackspace.com> On Thursday, 9 November, 2017 16:29, "Boris Kolpackov" said: > This is undocumented, but that column is also available in the > query object and is called 'typeid_'. You can use this information > to restrict the types of objects you are getting, for example: > > using DerivedAIdQuery = odb::query > > odb::result r( > db()->query( > DerivedAIdQuery::typeid_ == "DerivedA")); Thank you Boris. Is that discriminator string value somewhere available? Something like odb::object_traits::discriminator ? Dieter From boris at codesynthesis.com Fri Nov 10 07:11:33 2017 From: boris at codesynthesis.com (Boris Kolpackov) Date: Fri Nov 10 07:11:45 2017 Subject: [odb-users] Query only intermediate polymorphic objects In-Reply-To: <1510244832.964312771@apps.rackspace.com> References: <1510220745.21044691@apps.rackspace.com> <1510244832.964312771@apps.rackspace.com> Message-ID: Dieter Govaerts writes: > Is that discriminator string value somewhere available? Something like > odb::object_traits::discriminator ? https://www.codesynthesis.com/pipermail/odb-users/2016-April/003209.html Boris From otheontelth at protonmail.com Sun Nov 12 16:36:27 2017 From: otheontelth at protonmail.com (Otheontelth) Date: Sun Nov 12 16:36:49 2017 Subject: [odb-users] Problem with schema_catalog::migrate and postgresql Message-ID: Hello, i got the following problem: I am trying to create a database schema with odb::schema_catalog::migrate(*db). Note: There are no tables on the database. The code i use is: { odb :: transaction t ( db -> begin ()); odb :: schema_catalog :: migrate (* db ); t . commit (); } I get the following exception: terminate called after throwing an instance of 'odb::pgsql::database_exception' what(): 25P02: ERROR: current transaction is aborted, commands ignored until end of transaction block Stack trace (most recent call last): #14 Object ", at 0xffffffffffffffff, in #13 Object "/home/jr/src/csec/csec-dbg, at 0x43de79, in _start #12 Source "../csu/libc-start.c", line 308, in __libc_start_main [0x7f4e6c1e21c0] #11 Source "src/driver.cpp", line 36, in main [0x449f4e] 33: // if (!odb::schema_catalog::exists(*db)) { 34: // odb::schema_catalog::drop_schema(*db); 35: // odb::schema_catalog::create_schema(*db); > 36: odb::schema_catalog::migrate(*db); 37: //} 38: t.commit(); 39: } #10 Object "/usr/lib/x86_64-linux-gnu/libodb-2.4.so, at 0x7f4e706fbb3b, in odb::schema_catalog::migrate(odb::database&, unsigned long long, std::__cxx11::basic_string, std::allocator > const&) #9 Object "/usr/lib/x86_64-linux-gnu/libodb-2.4.so, at 0x7f4e706fb7e8, in odb::schema_catalog::create_schema(odb::database&, std::__cxx11::basic_string, std::allocator > const&, bool) #8 Source "src/db/db-odb.cpp", line 929, in create_schema [0x43f853] 926: { 927: case 1: 928: { > 929: db.execute ("CREATE TABLE \"func\" (\n" 930: " \"id\" SERIAL NOT NULL PRIMARY KEY,\n" 931: " \"name\" TEXT NOT NULL,\n" 932: " \"args\" INTEGER NOT NULL,\n" #7 Object "/usr/lib/x86_64-linux-gnu/libodb-pgsql-2.4.so, at 0x7f4e70918b52, in odb::pgsql::connection::execute(char const*, unsigned long) #6 Object "/usr/lib/x86_64-linux-gnu/libodb-pgsql-2.4.so, at 0x7f4e7091eb97, in odb::pgsql::translate_error(odb::pgsql::connection&, pg_result*) #5 Object "/usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.24, at 0x7f4e6cb9df13, in __cxa_throw #4 Object "/usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.24, at 0x7f4e6cb9dcd0, in std::terminate() #3 Object "/usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.24, at 0x7f4e6cb9dc85, in #2 Object "/usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.24, at 0x7f4e6cba0094, in __gnu_cxx::__verbose_terminate_handler() #1 Source "/build/glibc-CxtIbX/glibc-2.26/stdlib/abort.c", line 90, in abort [0x7f4e6c1f9f5c] #0 Source "../sysdeps/unix/sysv/linux/raise.c", line 51, in raise [0x7f4e6c1f80bb] Aborted (Signal sent by tkill() 11534 1000) The database log: 2017-11-12 22:31:23 CET [11535]: [1-1] user=[unknown],db=[unknown],app=[unknown],client=127.0.0.1 LOG: connection received: host=127.0.0.1 port=50072 2017-11-12 22:31:23 CET [11535]: [2-1] user=odb,db=odbdb,app=[unknown],client=127.0.0.1 LOG: connection authorized: user=odb database=odbdb SSL enabled (protocol=TLSv1.2, cipher=ECDHE-RSA-AES256-GCM-SHA384, compression=off) 2017-11-12 22:31:23 CET [11535]: [3-1] user=odb,db=odbdb,app=[unknown],client=127.0.0.1 LOG: duration: 0.037 ms statement: begin 2017-11-12 22:31:23 CET [11535]: [4-1] user=odb,db=odbdb,app=[unknown],client=127.0.0.1 ERROR: relation "schema_version" does not exist at character 36 2017-11-12 22:31:23 CET [11535]: [5-1] user=odb,db=odbdb,app=[unknown],client=127.0.0.1 STATEMENT: SELECT "version", "migration" FROM "schema_version" WHERE "name" = $1 2017-11-12 22:31:23 CET [11535]: [6-1] user=odb,db=odbdb,app=[unknown],client=127.0.0.1 ERROR: current transaction is aborted, commands ignored until end of transaction block 2017-11-12 22:31:23 CET [11535]: [7-1] user=odb,db=odbdb,app=[unknown],client=127.0.0.1 STATEMENT: CREATE TABLE "func" ( "id" SERIAL NOT NULL PRIMARY KEY, "name" TEXT NOT NULL, "args" INTEGER NOT NULL, "system" BOOLEAN NOT NULL) 2017-11-12 22:31:23 CET [11535]: [8-1] user=odb,db=odbdb,app=[unknown],client=127.0.0.1 LOG: could not receive data from client: Connection reset by peer 2017-11-12 22:31:23 CET [11535]: [9-1] user=odb,db=odbdb,app=[unknown],client=127.0.0.1 LOG: disconnection: session time: 0:00:00.151 user=odb database=odbdb host=127.0.0.1 port=50072 Its interesting that the code works when i change it to: { odb :: transaction t ( db -> begin ()); odb :: schema_catalog :: drop_schema (* db ); odb :: schema_catalog :: migrate (* db ); t . commit (); } Thank you From boris at codesynthesis.com Mon Nov 13 04:53:17 2017 From: boris at codesynthesis.com (Boris Kolpackov) Date: Mon Nov 13 04:53:29 2017 Subject: [odb-users] Problem with schema_catalog::migrate and postgresql In-Reply-To: References: Message-ID: Otheontelth writes: > Its interesting that the code works when i change it to: > > { > > odb > > :: > > transaction > > t > > ( > > db > > -> > > begin > > ()); > > odb > > :: > > schema_catalog > > :: > > drop_schema > > (* > > db > > ); > > odb > > :: > > schema_catalog > > :: > > migrate > > (* > > db > > ); > > t > > . > > commit > > (); > > } For some reason PostgreSQL does not provide any information for what caused the error. Could it be that you already have a table with this name in the database? P.S. You should really fix your mailer, your email was very unpleasant to read. Boris From otheontelth at protonmail.com Mon Nov 13 15:43:52 2017 From: otheontelth at protonmail.com (Otheontelth) Date: Mon Nov 13 15:44:16 2017 Subject: [odb-users] Problem with schema_catalog::migrate and postgresql In-Reply-To: References: Message-ID: I created a small project that shows the problem: https://gitlab.com/snsmac/odbmin db log: 2017-11-13 21:38:50 CET [28665]: [1-1] user=[unknown],db=[unknown],app=[unknown],client=127.0.0.1 LOG: connection received: host=127.0.0.1 port=52300 2017-11-13 21:38:50 CET [28665]: [2-1] user=odb,db=odbdb,app=[unknown],client=127.0.0.1 LOG: connection authorized: user=odb database=odbdb SSL enabled (protocol=TLSv1.2, cipher=ECDHE-RSA-AES256-GCM-SHA384, compression=off) 2017-11-13 21:38:50 CET [28665]: [3-1] user=odb,db=odbdb,app=[unknown],client=127.0.0.1 LOG: duration: 0.057 ms statement: begin 2017-11-13 21:38:50 CET [28665]: [4-1] user=odb,db=odbdb,app=[unknown],client=127.0.0.1 ERROR: relation "schema_version" does not exist at character 36 2017-11-13 21:38:50 CET [28665]: [5-1] user=odb,db=odbdb,app=[unknown],client=127.0.0.1 STATEMENT: SELECT "version", "migration" FROM "schema_version" WHERE "name" = $1 2017-11-13 21:38:50 CET [28665]: [6-1] user=odb,db=odbdb,app=[unknown],client=127.0.0.1 ERROR: current transaction is aborted, commands ignored until end of transaction block 2017-11-13 21:38:50 CET [28665]: [7-1] user=odb,db=odbdb,app=[unknown],client=127.0.0.1 STATEMENT: SELECT "version", "migration" FROM "schema_version" WHERE "name" = $1 2017-11-13 21:38:50 CET [28665]: [8-1] user=odb,db=odbdb,app=[unknown],client=127.0.0.1 LOG: could not receive data from client: Connection reset by peer 2017-11-13 21:38:50 CET [28665]: [9-1] user=odb,db=odbdb,app=[unknown],client=127.0.0.1 LOG: disconnection: session time: 0:00:00.121 user=odb database=odbdb host=127.0.0.1 port=52300 From boris at codesynthesis.com Wed Nov 15 10:53:13 2017 From: boris at codesynthesis.com (Boris Kolpackov) Date: Wed Nov 15 10:53:26 2017 Subject: [odb-users] Problem with schema_catalog::migrate and postgresql In-Reply-To: References: Message-ID: Ok, I've investigated this further and it appears to be due to PG's habit of poisoning transactions. The comment from the path explains: // If we are in the user's transaction then things are complicated. When // we try to execute SELECT on a non-existent table, PG "poisons" the // transaction (those "current transaction is aborted, commands ignored // until end of transaction block" messages in the log). Which means all // the user's schema creation statements that are likely to follow will // fail. // // There doesn't seem to be a better way to solve this than to check for // the table's existence. It is relatively easy to do with to_regclass() // in 9.4+ and a real pain in earlier versions. So we are going to do // this for 9.4+ and for older versions the workaround is to "pre-call" // database::schema_version() outside of any transaction. I've committed the workaround for the next release: https://git.codesynthesis.com/cgit/odb/libodb-pgsql/commit/?id=5f24741c88cf4e86dc7c9f3d8dd967a4a7f04bcf You should be able to apply the patch to the current version. Thanks for the report! Boris From otheontelth at protonmail.com Wed Nov 15 15:24:10 2017 From: otheontelth at protonmail.com (Otheontelth) Date: Wed Nov 15 15:24:38 2017 Subject: [odb-users] Problem with schema_catalog::migrate and postgresql In-Reply-To: References: Message-ID: <3eL2t7E8JHkMIH48Jn0wqI8aVuoH2ysmpTOVo-CmeSUjknfbboZLIC5YyV92N_FhkKVWy-Sy_uzwm5P2q_FjLOdidTKeC1JnfJHnOzUfRjg=@protonmail.com> Thanks for the fast help and generally for this great library Sent with [ProtonMail](https://protonmail.com) Secure Email. > -------- Original Message -------- > Subject: Re: [odb-users] Problem with schema_catalog::migrate and postgresql > Local Time: 15 November 2017 4:53 PM > UTC Time: 15 November 2017 15:53 > From: boris@codesynthesis.com > To: Otheontelth > odb-users@codesynthesis.com > > Ok, I've investigated this further and it appears to be due to PG's habit > of poisoning transactions. The comment from the path explains: > > // If we are in the user's transaction then things are complicated. When > // we try to execute SELECT on a non-existent table, PG "poisons" the > // transaction (those "current transaction is aborted, commands ignored > // until end of transaction block" messages in the log). Which means all > // the user's schema creation statements that are likely to follow will > // fail. > // > // There doesn't seem to be a better way to solve this than to check for > // the table's existence. It is relatively easy to do with to_regclass() > // in 9.4+ and a real pain in earlier versions. So we are going to do > // this for 9.4+ and for older versions the workaround is to "pre-call" > // database::schema_version() outside of any transaction. > > I've committed the workaround for the next release: > > https://git.codesynthesis.com/cgit/odb/libodb-pgsql/commit/?id=5f24741c88cf4e86dc7c9f3d8dd967a4a7f04bcf > > You should be able to apply the patch to the current version. > > Thanks for the report! > > Boris From alessandro.volz at gmail.com Tue Nov 21 06:05:53 2017 From: alessandro.volz at gmail.com (Alessandro Volz) Date: Tue Nov 21 06:06:13 2017 Subject: [odb-users] invalid paths during headers compilation on macOS 10.13 In-Reply-To: References: <95E666A8-1459-44B4-A64B-5DA4DF3624EE@gmail.com> Message-ID: <54271CB8-5FBD-41B0-8BCB-AF1B82832914@gmail.com> Confirmed, that was it. After upgrading to the new macOS 10.13, the CLT were no longer available and required a manual install. Thank you! Alessandro > On Sep 30, 2017, at 1:18 AM, Boris Kolpackov wrote: > > Alessandro Volz writes: > >> /Users/ale/my/path/to/odb-2.4.0-i686-macosx/lib/odb/i686-apple-darwin10/ >> include/c++/4.9.3/cwchar:44:19: fatal error: wchar.h: No such file or >> directory > > This sounds like you don't have system headers installed which are > part of the Command Line Tools, as discussed here: > > http://www.codesynthesis.com/products/odb/doc/install-macosx.xhtml > > Boris From shprotello at mail.ru Tue Nov 28 05:35:51 2017 From: shprotello at mail.ru (=?UTF-8?B?0KHQtdGA0LPQtdC5INCd0LjQutC+0L3QvtCy?=) Date: Tue Nov 28 05:36:12 2017 Subject: [odb-users] std bad allocation Message-ID: <1511865351.437739545@f487.i.mail.ru> Hello, I receive the std::bad_allocation exception when try to update a BLOB field in the persistent object with two BLOBs put in two sections: #pragma db object ??? class product ??? { ??? public: ????? typedef std::uint64_t id_t; ????? typedef std::vector image_t; ????? typedef std::vector bson_t; ????? product(); ????? ~product() {} ????? id_t id() const { return m_id; } ????? const odb::section& image_section() const { return m_image_section; } ????? odb::section& image_section() { return m_image_section; } ????? const odb::section& bson_section() const { return m_bson_section; } ????? odb::section& bson_section() { return m_bson_section; } ????? // ... ??? private: ????? friend class odb::access; ????? product() : m_id(0) {} ??? private: #pragma db id auto ????? id_t m_id; #pragma db load(lazy) update(manual) ????? odb::section m_image_section; #pragma db null type("BYTEA") section(m_image_section) ????? image_t m_image; #pragma db load(lazy) update(manual) ????? odb::section m_bson_section; #pragma db null type("BYTEA") section(m_bson_section) ????? image_t m_bson; ??? }; This is a sample code that generates the exception: auto product = db.load(product_id); // The line below throws std::bad_alloc db.load(*product, product->bson_section()); // ------------------------------------------------------- product->bson(buffer); db.update(*product, product->bson_section()); This is the place in the generated code that throws the exception. i.m_image_size here is 14829735431805717965, but at the same time i.m_image_null is true (m_image field is NULL in the database). The error takes place if the m_bson field isn't NULL in the database. bool access::object_traits_impl< ::product, id_pgsql >::bson_section_traits:: ? grow (image_type& i, ??????? bool* t) ? { ??? ODB_POTENTIALLY_UNUSED (i); ??? ODB_POTENTIALLY_UNUSED (t); ??? bool grew (false); ??? // m_id ??? // ??? t[0UL] = 0; ??? // m_owner ??? // ??? t[1UL] = 0; ??? // m_item ??? // ??? if (t[2UL]) ??? { ????? i.m_item_value.capacity (i.m_item_size); ????? grew = true; ??? } ??? // m_image ??? // ??? if (t[3UL]) ??? { ????? i.m_image_value.capacity (i.m_image_size); ????? grew = true; ??? } ??? // m_bson ??? // ??? if (t[4UL]) ??? { ????? i.m_bson_value.capacity (i.m_bson_size); ????? grew = true; ??? } ??? return grew; ? } Similar error happens from time to time for other classes in similar situations. Regards, Sergey From boris at codesynthesis.com Wed Nov 29 03:22:42 2017 From: boris at codesynthesis.com (Boris Kolpackov) Date: Wed Nov 29 03:22:54 2017 Subject: [odb-users] std bad allocation In-Reply-To: <1511865351.437739545@f487.i.mail.ru> References: <1511865351.437739545@f487.i.mail.ru> Message-ID: Hi Sergey, Thanks for the report and analysis. I am pretty sure this has been fixed in master by these two[1][2] commits. Could you try 2.5.0-b.3 to confirm? https://codesynthesis.com/~boris/tmp/odb/pre-release/b.3/ [1] https://git.codesynthesis.com/cgit/odb/odb/commit/?id=5d969f916178eb5e223d658dd55f5f2bc9ab526d [2] https://git.codesynthesis.com/cgit/odb/odb/commit/?id=7ebcc590a5ca302f35805a025545a8d10ce4cf5f Thanks, Boris