From boris at codesynthesis.com Sat Oct 1 11:55:36 2016 From: boris at codesynthesis.com (Boris Kolpackov) Date: Sat Oct 1 11:55:46 2016 Subject: [odb-users] Compilation errors In-Reply-To: References: Message-ID: Hi Tiago, Tiago Macarios writes: > 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) Yes, we've fixed that in 2.5.0-a9: http://codesynthesis.com/~boris/tmp/odb/pre-release/a9/ Boris From tiagomacarios at gmail.com Sat Oct 1 19:57:08 2016 From: tiagomacarios at gmail.com (Tiago Macarios) Date: Sat Oct 1 19:57:20 2016 Subject: [odb-users] Compilation errors In-Reply-To: References: Message-ID: Hey Boris, Awesome! Thanks for the fast reply. I updated to 2.5 (still playing with it). Now I am getting a warning on gcc: libodb/odb/details/posix/thread.ixx: In destructor ?odb::details::thread::~thread()?: libodb/odb/details/posix/thread.ixx:17:35: warning: throw will always call terminate() [-Wterminate] throw posix_exception (e); ^ libodb/odb/details/posix/thread.ixx:17:35: note: in C++11 destructors default to noexcept I changed that destructor noexcept(false) to keep the old behavior. Tiago On Sat, Oct 1, 2016 at 8:55 AM, Boris Kolpackov wrote: > Hi Tiago, > > Tiago Macarios writes: > > > 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) > > Yes, we've fixed that in 2.5.0-a9: > > http://codesynthesis.com/~boris/tmp/odb/pre-release/a9/ > > Boris > From boris at codesynthesis.com Mon Oct 3 10:59:00 2016 From: boris at codesynthesis.com (Boris Kolpackov) Date: Mon Oct 3 10:59:12 2016 Subject: [odb-users] Compilation errors In-Reply-To: References: Message-ID: Hi Tiago, Tiago Macarios writes: > I changed that destructor noexcept(false) to keep the old behavior. Thanks for the report. I've changed it not to throw so we don't go against the modern C++ grain ;-) http://scm.codesynthesis.com/?p=odb/libodb.git;a=commit;h=8689838a9c90699f1cfede7fd549a2945b9295db Boris From tiagomacarios at gmail.com Mon Oct 3 20:40:47 2016 From: tiagomacarios at gmail.com (Tiago Macarios) Date: Mon Oct 3 20:40:59 2016 Subject: [odb-users] Compilation errors In-Reply-To: References: Message-ID: Hey Boris thanks again for the fast reply! FYI: I applied your patch, but I think you forgot a semi-colon pthread_detach (id_); I am integrating ODB to our build system, so I will be reporting a couple more things. Hope you don't mind. 1 - When compiling libodb on Visual Studio I am getting: condition.obj : warning LNK4221: This object file does not define any previously undefined public symbols, so it will not be used by any link operation that consumes this library I had a look at condition.cxx and it seems like it is empty on purpose, but I don't really understand why (even though there is some text trying to explain, sorry about that). If the file is really to be kept empty, this seems to be the "best" solution I found to get rid of the warning: http://stackoverflow.co m/a/1822931/997527 wdyt? 2 - In the mapping example examples/mapping/traits-sqlite.hxx, shouldn't #include "person.hxx" // date be between a "pre" and "post"? #include #include "person.hxx" // date #include The above fixes a couple of unknown pragma issues. 3 - More of a question, but on the examples and tests why do you include the files on this order: #include "person.hxx" #include "person-odb.hxx" I guess you wouldn't even need the "person.hxx" since "person-odb.hxx" includes "person.hxx", but in case you keep both, why not flip the order: #include "person-odb.hxx" #include "person.hxx" This prevents a couple of unknown pragma errors. 4 - When using GCC I get a fair bit of warnings on the examples about the use of auto_ptr, ex: libtool: compile: g++ -DHAVE_CONFIG_H -I../../libcommon -I../../libcommon -DLIBCOMMON_DYNAMIC_LIB -I/mnt/c/Users/tmc/Downloads/libodb-2.5.0-a9 -I/mnt/c/Users/tmc/Downloads/libodb-sqlite-2.5.0-a9 -g -O2 -D_REENTRANT -MT common.lo -MD -MP -MF .deps/common.Tpo -c common.cxx -fPIC -DPIC -o .libs/common.o In file included from common.cxx:12:0: ../../libcommon/common/common.hxx:22:23: warning: 'template class std::auto_ptr' is deprecated [-Wdeprecated-declarations] LIBCOMMON_EXPORT std::auto_ptr ^~~~~~~~ In file included from /usr/include/c++/6/memory:81:0, from /mnt/c/Users/tmc/Downloads/libodb-2.5.0-a9/odb/database.hxx:14, from common.cxx:9: /usr/include/c++/6/bits/unique_ptr.h:49:28: note: declared here template class auto_ptr; ^~~~~~~~ I had a look at the code and I guess one could run it through clang-tidy, but I see that you use #IFDEF HAVE_CXX11. Not sure clang-tidy will honor that, but if you are open to patches I can give it a try. http://clang.llvm.org/extra/clang-tidy/checks/modernize-replace-auto-ptr.html On Mon, Oct 3, 2016 at 7:59 AM, Boris Kolpackov wrote: > Hi Tiago, > > Tiago Macarios writes: > > > I changed that destructor noexcept(false) to keep the old behavior. > > Thanks for the report. I've changed it not to throw so we don't go against > the modern C++ grain ;-) > > http://scm.codesynthesis.com/?p=odb/libodb.git;a=commit;h= > 8689838a9c90699f1cfede7fd549a2945b9295db > > Boris > From anaswara.nn at gmail.com Tue Oct 4 04:13:11 2016 From: anaswara.nn at gmail.com (Anaswara Nair) Date: Tue Oct 4 04:13:23 2016 Subject: [odb-users] Database schema from sql file Message-ID: Hi, I am new to ODB. I have used ODB in my program with sqlite database. I created standalone SQL file using --schema-format sql option. Now how can I create the schema using this sql file in my database? From leafless.matt at gmail.com Mon Oct 3 16:37:56 2016 From: leafless.matt at gmail.com (Matt Walker) Date: Tue Oct 4 09:05:09 2016 Subject: [odb-users] specifying column and table names for many-to-many join tables Message-ID: I am dealing with an existing schema, so I cannot use ODB to generate the sql. I have looked at the documentaion and don't see any way to specify the particulars with pragmas. E.G., Hibernate allows you to annotate a field in an entity with the name of the join table and column. Is this possible? Thanks, Matt Walker From leafless.matt at gmail.com Mon Oct 3 17:14:39 2016 From: leafless.matt at gmail.com (Matt Walker) Date: Tue Oct 4 09:05:10 2016 Subject: [odb-users] Re: specifying column and table names for many-to-many join tables In-Reply-To: References: Message-ID: Ok, I played with the xx_column pragmas and field name and got it to generate DDL that looked like what I'm dealing with. In case any one finds it helpful... use: class UserProfile {....}; class AppUser { .... #pragma db value_column("*USER_PROFILE_ID*") id_column("*USER_ID*") vector> *USER_PROFILE*_; }; generates: CREATE TABLE `APP_USER_USER_PROFILE` ( `USER_ID` INT(11) NOT NULL, `USER_PROFILE_ID` INT(11) NOT NULL, CONSTRAINT `APP_USER_USER_PROFILE_USER_ID_fk` FOREIGN KEY (`USER_ID`) REFERENCES `APP_USER` (`id`) ON DELETE CASCADE /* CONSTRAINT `APP_USER_USER_PROFILE_USER_PROFILE_ID_fk` FOREIGN KEY (`USER_PROFILE_ID`) REFERENCES `USER_PROFILE` (`id`) */) ENGINE=InnoDB; On Mon, Oct 3, 2016 at 3:37 PM, Matt Walker wrote: > I am dealing with an existing schema, so I cannot use ODB to generate the > sql. I have looked at the documentaion and don't see any way to specify the > particulars with pragmas. E.G., Hibernate allows you to annotate a field in > an entity with the name of the join table and column. Is this possible? > > Thanks, > > Matt Walker > From Nageswar.Rao at fs.utc.com Tue Oct 4 09:22:33 2016 From: Nageswar.Rao at fs.utc.com (Rao, Nageswara UTC CCS) Date: Tue Oct 4 09:24:21 2016 Subject: [odb-users] Using Index name in odb query Message-ID: <0285A0946964DE4AB640FF3823F15B5DAC4459@UUSNWE28.global.utcmail.com> Hi, Need to your help in using the index name in the odb query. In Sqlite, we can have query command like "selct * from Table INDEXED BY indexname where age>30; How do we use the same in odb query? Thanks & Regards Nageswara Rao B From boris at codesynthesis.com Tue Oct 4 09:27:38 2016 From: boris at codesynthesis.com (Boris Kolpackov) Date: Tue Oct 4 09:27:48 2016 Subject: [odb-users] Database schema from sql file In-Reply-To: References: Message-ID: Hi Anaswara, Anaswara Nair writes: > I have used ODB in my program with sqlite database. I created standalone > SQL file using --schema-format sql option. Now how can I create the schema > using this sql file in my database? With SQLite you normally use embedded (in C++) schema and then use the odb::schema_catalog API to apply it to the database. But if you want to use standalone SQL, you should be able to do it using the sqlite3(1) driver. Boris From abv150ci at gmail.com Tue Oct 4 10:05:30 2016 From: abv150ci at gmail.com (=?UTF-8?Q?Aar=C3=B3n_Bueno_Villares?=) Date: Tue Oct 4 10:06:24 2016 Subject: [odb-users] Query with conditional parts Message-ID: Suppose I have to construct a query depending on some external conditions, in such a way I need to construct a query in different steps or parts, like: using q_vw_t = my_view; using q_t = odb::query; auto query = q_t::field_1.is_not_null(); if (some_condition) query = query and q_t::field_2 == 5; else query = query and q_t::field_2.is_null(); There's no comments or examples in the ODB's documentation telling if that can be done or what is the type of `q_t::field_1` or `q_t::field_1 == 5`. I know, reading the ODB source code, that every operation over a column (`.is_null()`, `and`, or whichever it is), returns a `query_base` oject (which isn't parametric). So, I know every operation returns and object of a same type, and thus, I can reuse the same variable and the type is constant through any composition chain. But because I'm not allow to know any implementation detail of how query works (for example, if the implementation changes), I've created a "functional" method to compose simple queries trying to avoid any asumption about types. My method is: I receive a callable object, and a list of pair of values, and I pass each pair to the callable object, composing the returned objects of each call with `and`s (no 100% generic of course, but enough for my specific case; I would just need a `comb` callable object to specify what to do with results instead of `and`). Each pair is suppossed to be a column and a value to be compared with the column, but in fact, can be anything accepted by the `cond`ition. Case-base: template auto conditional_query(cond_t const& cond, col_t const& col, mo_t const& mo) -> decltype(cond(col, mo)) { return cond(col, mo); } General-case: template auto conditional_query(cond_t const& cond, col_t const& col, mo_t const& mo, more_t&&... more) -> typename std::enable_if< (sizeof...(more) > 1), decltype(cond(col, mo) and conditional_query (cond, std::forward(more)...))>::type { return cond(col, mo) and conditional_query(cond, std::forward(more)...); } So, my conditional query is safe in the sense that its type is just the result of the composition. There' s any asumption about common types between operations or something. That function is correct without considering if I've read the source code or not. However, the "hole" lives in the "condition": // mo_t is just a wrapper of mine of a shared_ptr containing a instance of a // persistent class. `valid` is true if the `shared_ptr` owns an object, and `.id()` // returns the primary key as integer of the object otherwise. struct q_branch { template auto operator()(col_t const& col, mo_t const& mo) const -> decltype(col.is_null()) { return mo.valid() ? col == mo.id() : col.is_null(); } }; I assume here that the types of `col == mo.id()` and `col.is_null()` are the same (which in fact they are, but it's a thing I know because I've read the source code). My question is: can ODB officially say that queries can be composed in steps? Because, if the answer is yes, I could simply do: using q_vw_t = my_view; using q_t = odb::query; auto query = q_t::field_1.is_not_null(); if (some_condition) query = query and q_t::field_2 == 5; else query = query and q_t::field_2.is_null(); My above method `conditional_query` is just to "carry" my "discoveries/assumptions" to a focused place (the condition object) in case of problems. Is there other way of doing what I'm doing? Apart from creating new views, of course, because there could be a lot of them. From boris at codesynthesis.com Tue Oct 4 10:32:33 2016 From: boris at codesynthesis.com (Boris Kolpackov) Date: Tue Oct 4 10:32:44 2016 Subject: [odb-users] Query with conditional parts In-Reply-To: References: Message-ID: Hi Aar?n, Aar?n Bueno Villares writes: > There's no comments or examples in the ODB's documentation telling if that > can be done or what is the type of `q_t::field_1` or `q_t::field_1 == 5`. There is an example in Section 4.3, "Executing a Query". > My question is: can ODB officially say that queries can be composed in > steps? Yes. We haven't specified the query_base type yet, but at this stage it is safe to assume it's not going anywhere. But if you can use C++11 auto, then it's even better. Boris From boris at codesynthesis.com Tue Oct 4 10:54:56 2016 From: boris at codesynthesis.com (Boris Kolpackov) Date: Tue Oct 4 10:55:06 2016 Subject: [odb-users] Compilation errors In-Reply-To: References: Message-ID: Hi Tiago, Tiago Macarios writes: > FYI: I applied your patch, but I think you forgot a semi-colon > > pthread_detach (id_); Right, I thought I've tested it but turns out it was C++11 threads configuration. > I am integrating ODB to our build system, so I will be reporting a couple > more things. Hope you don't mind. Sure, we always appreciate bug reports. > 1 - When compiling libodb on Visual Studio I am getting: > > condition.obj : warning LNK4221: This object file does not define any > previously undefined public symbols, so it will not be used by any link > operation that consumes this library > > I had a look at condition.cxx and it seems like it is empty on purpose, but > I don't really understand why (even though there is some text trying to > explain, sorry about that). This is the Windows DLL symbol exporting "brain-death". Currently the ODB approach is to export inline functions which sometimes requires having a dummy source file so that they are actually "seen" and exported by the compiler. In build2 builds we have switched to not exporting inline functions by default. We are probably not going to back-port it to the VC projects since there is no guarantee all the old version of VC will be happy. But this warning is harmless and you can ignore it. > 2 - In the mapping example examples/mapping/traits-sqlite.hxx, shouldn't > > #include "person.hxx" // date > > be between a "pre" and "post"? > > #include > #include "person.hxx" // date > #include > > The above fixes a couple of unknown pragma issues. We try to keep examples as pure as possible so that the code can be used directly in user applications. In build2 we will suppress them with cl option from buildfile. > 3 - More of a question, but on the examples and tests why do you include > the files on this order: > > #include "person.hxx" > #include "person-odb.hxx" > > I guess you wouldn't even need the "person.hxx" since "person-odb.hxx" > includes "person.hxx", but in case you keep both, why not flip the order: > > #include "person-odb.hxx" > #include "person.hxx" Flipping the order is a matter of style. We try to include more general headers first. As for why include both, again, our style is to explicitly include everything we use. > 4 - When using GCC I get a fair bit of warnings on the examples about the > use of auto_ptr, Yes, this can only get fixed once we drop C++98 support, which we plan to do as soon as we release the next version. Boris From boris at codesynthesis.com Tue Oct 4 10:57:42 2016 From: boris at codesynthesis.com (Boris Kolpackov) Date: Tue Oct 4 10:57:53 2016 Subject: [odb-users] Using Index name in odb query In-Reply-To: <0285A0946964DE4AB640FF3823F15B5DAC4459@UUSNWE28.global.utcmail.com> References: <0285A0946964DE4AB640FF3823F15B5DAC4459@UUSNWE28.global.utcmail.com> Message-ID: Hi Nageswara, Rao, Nageswara UTC CCS writes: > In Sqlite, we can have query command like "selct * from Table INDEXED BY indexname where age>30; > How do we use the same in odb query? You will have to use a native query in a view (potentially object-loading view). See Chapter 10, "Views". Boris From tiagomacarios at gmail.com Tue Oct 4 20:45:41 2016 From: tiagomacarios at gmail.com (Tiago Macarios) Date: Tue Oct 4 20:45:53 2016 Subject: [odb-users] Compilation errors In-Reply-To: References: Message-ID: Cool! Thanks Boris =) On Tue, Oct 4, 2016 at 7:54 AM, Boris Kolpackov wrote: > Hi Tiago, > > Tiago Macarios writes: > > > FYI: I applied your patch, but I think you forgot a semi-colon > > > > pthread_detach (id_); > > Right, I thought I've tested it but turns out it was C++11 threads > configuration. > > > > I am integrating ODB to our build system, so I will be reporting a couple > > more things. Hope you don't mind. > > Sure, we always appreciate bug reports. > > > > 1 - When compiling libodb on Visual Studio I am getting: > > > > condition.obj : warning LNK4221: This object file does not define any > > previously undefined public symbols, so it will not be used by any link > > operation that consumes this library > > > > I had a look at condition.cxx and it seems like it is empty on purpose, > but > > I don't really understand why (even though there is some text trying to > > explain, sorry about that). > > This is the Windows DLL symbol exporting "brain-death". Currently the ODB > approach is to export inline functions which sometimes requires having a > dummy source file so that they are actually "seen" and exported by the > compiler. > > In build2 builds we have switched to not exporting inline functions by > default. We are probably not going to back-port it to the VC projects > since there is no guarantee all the old version of VC will be happy. > > But this warning is harmless and you can ignore it. > > > > 2 - In the mapping example examples/mapping/traits-sqlite.hxx, shouldn't > > > > #include "person.hxx" // date > > > > be between a "pre" and "post"? > > > > #include > > #include "person.hxx" // date > > #include > > > > The above fixes a couple of unknown pragma issues. > > We try to keep examples as pure as possible so that the code can be used > directly in user applications. In build2 we will suppress them with cl > option from buildfile. > > > > 3 - More of a question, but on the examples and tests why do you include > > the files on this order: > > > > #include "person.hxx" > > #include "person-odb.hxx" > > > > I guess you wouldn't even need the "person.hxx" since "person-odb.hxx" > > includes "person.hxx", but in case you keep both, why not flip the order: > > > > #include "person-odb.hxx" > > #include "person.hxx" > > Flipping the order is a matter of style. We try to include more general > headers first. As for why include both, again, our style is to explicitly > include everything we use. > > > > 4 - When using GCC I get a fair bit of warnings on the examples about the > > use of auto_ptr, > > Yes, this can only get fixed once we drop C++98 support, which we plan to > do as soon as we release the next version. > > Boris > From Nageswar.Rao at fs.utc.com Tue Oct 4 13:50:43 2016 From: Nageswar.Rao at fs.utc.com (Rao, Nageswara UTC CCS) Date: Wed Oct 5 08:34:24 2016 Subject: [External] Re: [odb-users] Using Index name in odb query In-Reply-To: References: <0285A0946964DE4AB640FF3823F15B5DAC4459@UUSNWE28.global.utcmail.com> Message-ID: <0285A0946964DE4AB640FF3823F15B5DAC4539@UUSNWE28.global.utcmail.com> Thanks Boris, For the quick reply. It is working. Regards, Rao -----Original Message----- From: Boris Kolpackov [mailto:boris@codesynthesis.com] Sent: Tuesday, October 04, 2016 8:28 PM To: Rao, Nageswara UTC CCS Cc: odb-users@codesynthesis.com Subject: [External] Re: [odb-users] Using Index name in odb query Hi Nageswara, Rao, Nageswara UTC CCS writes: > In Sqlite, we can have query command like "selct * from Table INDEXED > BY indexname where age>30; How do we use the same in odb query? You will have to use a native query in a view (potentially object-loading view). See Chapter 10, "Views". Boris From anaswara.nn at gmail.com Thu Oct 6 06:40:48 2016 From: anaswara.nn at gmail.com (Anaswara Nair) Date: Thu Oct 6 06:41:01 2016 Subject: [odb-users] Defining the foreign key Message-ID: Hi, I have two classes A and B. I defined `pragma db object` above the class declaration of both the classes. Now I want to declare the primary key of A(an integer value) as B's foreign key. On searching I found `shared_ptr` can be used for the purpose. Can you make it more clear. Thankyou From teratux at gmail.com Thu Oct 6 17:17:26 2016 From: teratux at gmail.com (=?UTF-8?Q?Roberto_Alejandro_Esp=C3=AD_Mu=C3=B1oz?=) Date: Thu Oct 6 17:17:38 2016 Subject: [odb-users] problem dereferncing result pointer ... Message-ID: Hi ... I wrote a simple program that connects to a PGSQL database and persists and executes a query later on, following up on the provided examples. The part where I persist works perfectly: boost::shared_ptr< Guest > g ( new Guest() ); boost::shared_ptr< Hotel > l ( new Hotel() ); boost::shared_ptr< Room > r ( new Room() ); l->Rooms_.push_back ( r ); boost::shared_ptr< Stay > s1 ( new Stay ); s1->Guests_.push_back ( g ); s1->Rooms_.push_back ( r ); g->Stay_ = s1; r->Stay_ = s1; r->Location_ = l; { odb::transaction t ( Central::getInstance()->getDB()->begin() ); Central::getInstance()->getDB()->persist ( l ); Central::getInstance()->getDB()->persist ( s1 ); Central::getInstance()->getDB()->persist ( g ); Central::getInstance()->getDB()->persist ( r ); t.commit(); } Up to here everything perfect. When I execute a query I experience an interesting behaviour: typedef odb::query< Location > query; typedef odb::result< Location > result; { odb::transaction t ( Central::getInstance()->getDB()->begin() ); result r = Central::getInstance()->getDB()->query< Location > (); if ( !r.empty() ) { for ( auto i ( r.begin() ); i != r.end(); ++i ) { std::cout << "ID " << i.id() << std::endl; //(*i); } } t.commit(); } Notice the //(*i) part? If I run it with that line commented, I get a correct std::cout with the id of the results, if I uncomment it then my programs hangs in that line and later crashes. I don't think there's a problem with my entities since I managed to persist them ok. Any advice?, thanks in advance -- teratux ------------ From anaswara.nn at gmail.com Fri Oct 7 02:01:07 2016 From: anaswara.nn at gmail.com (Anaswara Nair) Date: Fri Oct 7 02:01:20 2016 Subject: [odb-users] Unknown database schema in Visual Studio project Message-ID: Hi, In my Visual Studio solution, I have two different projects of which one is built as a static library and the other one as the executable. The ODB related code like creating the database and all are in the library. I linked this library to my executable. But when I debug the executable code, I get the error "unknown database schema" in the call create_schema(). What am I doing wrong? Please help. Thankyou. From obermann.lukas at gmail.com Fri Oct 7 05:29:03 2016 From: obermann.lukas at gmail.com (Lukas Obermann) Date: Fri Oct 7 05:29:27 2016 Subject: [odb-users] Querying on Containers Message-ID: Hi there, is it still true that querying on containers directly (without a view on top) is not possible? Asking cause I have a object with ~10 containers and I imagine it not very efficient creating a view that basically "unwinds"/"projects" all those containers so that a object can be loaded in one query. Thanks, Lukas From boris at codesynthesis.com Fri Oct 7 10:28:22 2016 From: boris at codesynthesis.com (Boris Kolpackov) Date: Fri Oct 7 10:28:31 2016 Subject: [odb-users] problem dereferncing result pointer ... In-Reply-To: References: Message-ID: Hi Roberto, Roberto Alejandro Esp? Mu?oz writes: > boost::shared_ptr< Guest > g ( new Guest() ); > boost::shared_ptr< Hotel > l ( new Hotel() ); > boost::shared_ptr< Room > r ( new Room() ); > l->Rooms_.push_back ( r ); > boost::shared_ptr< Stay > s1 ( new Stay ); > s1->Guests_.push_back ( g ); > s1->Rooms_.push_back ( r ); > g->Stay_ = s1; > r->Stay_ = s1; > r->Location_ = l; > > { > odb::transaction t ( Central::getInstance()->getDB()->begin() ); > Central::getInstance()->getDB()->persist ( l ); > Central::getInstance()->getDB()->persist ( s1 ); > Central::getInstance()->getDB()->persist ( g ); > Central::getInstance()->getDB()->persist ( r ); > t.commit(); > } > > Up to here everything perfect. I am guessing you are using auto-assigned object ids. If that's the case then you need to persist object in the correct order. See a note at the end of the introduction to Chapter 6, "Relationships". > When I execute a query I experience an interesting behaviour: One thing I noticed about your code is that you are not using a session. You seem to have circular relationships in your model in which case a session is required. Boris From boris at codesynthesis.com Fri Oct 7 10:30:40 2016 From: boris at codesynthesis.com (Boris Kolpackov) Date: Fri Oct 7 10:30:50 2016 Subject: [odb-users] Unknown database schema in Visual Studio project In-Reply-To: References: Message-ID: Hi Anaswara, Anaswara Nair writes: > In my Visual Studio solution, I have two different projects of which one is > built as a static library and the other one as the executable. This post explains the potential problem with static libraries: http://www.codesynthesis.com/pipermail/odb-users/2013-May/001286.html While this post explains how to fix it in VC: http://www.codesynthesis.com/pipermail/odb-users/2013-May/001289.html Boris From boris at codesynthesis.com Fri Oct 7 10:34:48 2016 From: boris at codesynthesis.com (Boris Kolpackov) Date: Fri Oct 7 10:34:58 2016 Subject: [odb-users] Querying on Containers In-Reply-To: References: Message-ID: Hi Lukas, Lukas Obermann writes: > is it still true that querying on containers directly (without a view on > top) is not possible? Yes, that's true. > Asking cause I have a object with ~10 containers and I imagine it not > very efficient creating a view that basically "unwinds"/"projects" all > those containers so that a object can be loaded in one query. If you create such as view, you don't have to load the container columns as part of it (i.e., you would use the container columns in the JOIN/WHERE clauses only). Boris From obermann.lukas at gmail.com Fri Oct 7 10:55:11 2016 From: obermann.lukas at gmail.com (Lukas Obermann) Date: Fri Oct 7 10:55:35 2016 Subject: [odb-users] Querying on Containers In-Reply-To: References: Message-ID: Hi Boris, thank you. But maybe you can help me out with the view, as I also have some issues creating it. So, lets assume following classes: class main { odb::lazy_shared_ptr ptr_a; std::vector< odb::lazy_shared_ptr > list_a; std::vector< odb::lazy_shared_ptr > ptr_b } class ClassA { std::string iNeedToBeQueried; } class ClassB { std::string iNeedToBeQueried; odb::lazy_shared_ptr ptr_c; } class ClassC { std::string iNeedToBeQueried; } So, ptr_a is no issue, but I am not able to figure out how to add the two vectors to the view and also access ClassC, all at the same time. Those 3 cases are basically all the cases I have in that class i try to query. Is this doable via a View or do I have to fallback to native queries? Thanks, Lukas Boris Kolpackov schrieb am Fr., 7. Okt. 2016 um 16:34 Uhr: > Hi Lukas, > > Lukas Obermann writes: > > > is it still true that querying on containers directly (without a view on > > top) is not possible? > > Yes, that's true. > > > > Asking cause I have a object with ~10 containers and I imagine it not > > very efficient creating a view that basically "unwinds"/"projects" all > > those containers so that a object can be loaded in one query. > > If you create such as view, you don't have to load the container columns > as part of it (i.e., you would use the container columns in the JOIN/WHERE > clauses only). > > Boris > From raespi at icid.cu Fri Oct 7 10:37:39 2016 From: raespi at icid.cu (Roberto Alejandro Espi Munoz) Date: Fri Oct 7 10:59:06 2016 Subject: [odb-users] problem dereferncing result pointer ... In-Reply-To: References: Message-ID: <57F7B333.2090207@icid.cu> On 10/07/2016 10:28 AM, Boris Kolpackov wrote: > Hi Roberto, > > Roberto Alejandro Esp? Mu?oz writes: > >> boost::shared_ptr< Guest > g ( new Guest() ); >> boost::shared_ptr< Hotel > l ( new Hotel() ); >> boost::shared_ptr< Room > r ( new Room() ); >> l->Rooms_.push_back ( r ); >> boost::shared_ptr< Stay > s1 ( new Stay ); >> s1->Guests_.push_back ( g ); >> s1->Rooms_.push_back ( r ); >> g->Stay_ = s1; >> r->Stay_ = s1; >> r->Location_ = l; >> >> { >> odb::transaction t ( Central::getInstance()->getDB()->begin() ); >> Central::getInstance()->getDB()->persist ( l ); >> Central::getInstance()->getDB()->persist ( s1 ); >> Central::getInstance()->getDB()->persist ( g ); >> Central::getInstance()->getDB()->persist ( r ); >> t.commit(); >> } >> >> Up to here everything perfect. > I am guessing you are using auto-assigned object ids. If that's the case > then you need to persist object in the correct order. See a note at the > end of the introduction to Chapter 6, "Relationships". Yes this was one of the issues at the beginning when persisting. I kept getting a NULL::pointer exception until I managed to persist them in the correct order. > > >> When I execute a query I experience an interesting behaviour: > One thing I noticed about your code is that you are not using a session. > You seem to have circular relationships in your model in which case > a session is required. > > Boris Yes this did the trick, tried it this morning. A simple "odb::session s;" at the beggining of the context. If I might suggest something, is there any way that you can throw an exception in this point that warns users about circular relationships and not using session objects at runtime? It's very hard to capture this problem since the application behaviour is to just hang and wait to crash. The produced framestack is also useless btw. Thank you From boris at codesynthesis.com Fri Oct 7 11:07:45 2016 From: boris at codesynthesis.com (Boris Kolpackov) Date: Fri Oct 7 11:07:55 2016 Subject: [odb-users] Querying on Containers In-Reply-To: References: Message-ID: Hi Lukas, Lukas Obermann writes: > class main > { > odb::lazy_shared_ptr ptr_a; > std::vector< odb::lazy_shared_ptr > list_a; > std::vector< odb::lazy_shared_ptr > ptr_b > } > > class ClassA > { > std::string iNeedToBeQueried; > } > > class ClassB > { > std::string iNeedToBeQueried; > odb::lazy_shared_ptr ptr_c; > } > > class ClassC > { > std::string iNeedToBeQueried; > } So you have containers of pointers -- this is even easier. > So, ptr_a is no issue, but I am not able to figure out how to add the two > vectors to the view and also access ClassC, all at the same time. You just add their classes to the view. Check this earlier thread, it is exactly the same problem: http://codesynthesis.com/pipermail/odb-users/2016-August/003412.html Boris From boris at codesynthesis.com Fri Oct 7 11:14:37 2016 From: boris at codesynthesis.com (Boris Kolpackov) Date: Fri Oct 7 11:14:47 2016 Subject: [odb-users] problem dereferncing result pointer ... In-Reply-To: <57F7B333.2090207@icid.cu> References: <57F7B333.2090207@icid.cu> Message-ID: Hi Roberto, Roberto Alejandro Espi Munoz writes: > If I might suggest something, is there any way that you can throw an > exception in this point that warns users about circular relationships and > not using session objects at runtime? I don't think there is an easy way to detect infinite recursion. > It's very hard to capture this problem since the application behaviour > is to just hang and wait to crash. The produced framestack is also > useless btw. I think the stack trace will have a large number of repeating fragments which always indicates an infinite recursion. This should be a good hint. Boris From obermann.lukas at gmail.com Fri Oct 7 11:21:33 2016 From: obermann.lukas at gmail.com (Lukas Obermann) Date: Fri Oct 7 11:21:56 2016 Subject: [odb-users] Querying on Containers In-Reply-To: References: Message-ID: Thanks, about the distinct, do I have to place this once at the end or after each object? Boris Kolpackov schrieb am Fr., 7. Okt. 2016 um 17:07 Uhr: > Hi Lukas, > > Lukas Obermann writes: > > > class main > > { > > odb::lazy_shared_ptr ptr_a; > > std::vector< odb::lazy_shared_ptr > list_a; > > std::vector< odb::lazy_shared_ptr > ptr_b > > } > > > > class ClassA > > { > > std::string iNeedToBeQueried; > > } > > > > class ClassB > > { > > std::string iNeedToBeQueried; > > odb::lazy_shared_ptr ptr_c; > > } > > > > class ClassC > > { > > std::string iNeedToBeQueried; > > } > > So you have containers of pointers -- this is even easier. > > > > So, ptr_a is no issue, but I am not able to figure out how to add the two > > vectors to the view and also access ClassC, all at the same time. > > You just add their classes to the view. Check this earlier thread, it > is exactly the same problem: > > http://codesynthesis.com/pipermail/odb-users/2016-August/003412.html > > Boris > From tiagomacarios at gmail.com Sat Oct 8 18:56:35 2016 From: tiagomacarios at gmail.com (Tiago Macarios) Date: Sat Oct 8 18:56:48 2016 Subject: [odb-users] ODB + filesystem Message-ID: Hi, I am porting some of our code to use ODB and I hit a problem. Some of the code uses the header and this causes the ODB compiler to halt: fatal error: filesystem: No such file or directory #include ^ compilation terminated. I guess it is because the ODB compiler is based on GCC 4.9.3 and the filesystem libraries are only available after 5.3. What is the best thing to do here? Is there a windows build of the compiler on a more updated version of GCC (say 6.2)? Tiago From ratkaisut at gmail.com Sun Oct 9 00:39:50 2016 From: ratkaisut at gmail.com (Sten Kultakangas) Date: Sun Oct 9 00:40:02 2016 Subject: [odb-users] using ODB with cross-compiler x86_64-linux-gnu -> i686-w64-mingw Message-ID: Hello I have built ODB to be used with the cross-compiler, however, ODB doesn't seem to pass the required parameters to the g++ plugin interface. I have checked that /i686-w64-mingw32/lib/gcc/i686-w64-mingw32/6.2.0/plugin/i686-w64-mingw32-odb.so is actually ELF file, not MZ. Another possibility is that the plugin interface in gcc 6.2.0 is broken. BTW i had to make a symbolic link from the original odb.so file to i686-w64-mingw32-odb.so Until that it reported error "no ODB plugin in GCC plugin directory" despite the --program-prefix configuration option. Also i had to make some changes before i managed to compile it with gcc 6.2.0. Namely it plugin API had somewhat changed and coretypes.h must not anymore be included directly with C-linkage but rather gcc-plugin.h must be included instead. Also ANON_AGGRNAME_P is not a valid symbol anymore but rather anon_aggrname_p shall be used. Also there where a conflict between toupper, tolower etc macros with the corresponding STL class member functions so i had to #undef them before #include . Also i had to change new_node to new_node in parser.cxx. But it's a different story In the end of this email you will find the output of the readelf tool. Here's the output of the ODB: user@chronoscepter:~/workspace/ICCBackend$ /i686-w64-mingw32/bin/i686-w64-mingw32-odb -v --database mssql --std c++11 --profile boost/date-time/posix-time --generate-query -DPRODUCT_ID=1 --output-dir generated iCCSettings_model.h Profile search paths: /i686-w64-mingw32/lib/gcc/i686-w64-mingw32/6.2.0/include/c++ /i686-w64-mingw32/lib/gcc/i686-w64-mingw32/6.2.0/include/c++/i686-w64-mingw32 /i686-w64-mingw32/lib/gcc/i686-w64-mingw32/6.2.0/include/c++/backward /i686-w64-mingw32/lib/gcc/i686-w64-mingw32/6.2.0/include /i686-w64-mingw32//include /i686-w64-mingw32/lib/gcc/i686-w64-mingw32/6.2.0/include-fixed /i686-w64-mingw32/lib/gcc/i686-w64-mingw32/6.2.0/../../../../i686-w64-mingw32/include Compiling iCCSettings_model.h i686-w64-mingw32-g++ -x c++ -std=gnu++0x -S -Wunknown-pragmas -Wno-deprecated -fplugin=/i686-w64-mingw32/lib/gcc/i686-w64-mingw32/6.2.0/plugin/i686-w64-mingw32-odb.so -v -DPRODUCT_ID=1 -fplugin-arg-odb-svc-path=/i686-w64-mingw32/lib/gcc/i686-w64-mingw32/6.2.0/include/c++ -fplugin-arg-odb-svc-path=/i686-w64-mingw32/lib/gcc/i686-w64-mingw32/6.2.0/include/c++/i686-w64-mingw32 -fplugin-arg-odb-svc-path=/i686-w64-mingw32/lib/gcc/i686-w64-mingw32/6.2.0/include/c++/backward -fplugin-arg-odb-svc-path=/i686-w64-mingw32/lib/gcc/i686-w64-mingw32/6.2.0/include -fplugin-arg-odb-svc-path=/i686-w64-mingw32//include -fplugin-arg-odb-svc-path=/i686-w64-mingw32/lib/gcc/i686-w64-mingw32/6.2.0/include-fixed -fplugin-arg-odb-svc-path=/i686-w64-mingw32/lib/gcc/i686-w64-mingw32/6.2.0/../../../../i686-w64-mingw32/include -DODB_COMPILER -DODB_COMPILER_VERSION=2040000 -DODB_DATABASE_MSSQL -fplugin-arg-odb-database=mssql -fplugin-arg-odb-std=c++11 -fplugin-arg-odb-profile=boost/date-time/posix-time -fplugin-arg-odb-generate-query -fplugin-arg-odb-output-dir=generated -fplugin-arg-odb-svc-file=iCCSettings_model.h - Using built-in specs. COLLECT_GCC=i686-w64-mingw32-g++ Target: i686-w64-mingw32 Configured with: ../gcc-6.2.0/configure --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=i686-w64-mingw32 --prefix=/i686-w64-mingw32 --with-sysroot=/i686-w64-mingw32 --disable-multilib --enable-languages=c,c++ --enable-lto --with-dwarf2 --enable-fully-dynamic-string --enable-version-specific-runtime-libs --enable-libgomp --disable-nls --enable-checking=release --disable-win32-registry --disable-libgcj --with-local-prefix=/ --enable-plugin --enable-threads=win32 --enable-__cxa_atexit --enable-default-ssp --disable-shared --enable-static Thread model: win32 gcc version 6.2.0 (GCC) COLLECT_GCC_OPTIONS='-std=gnu++11' '-S' '-Wunknown-pragmas' '-Wno-deprecated' '-fplugin=/i686-w64-mingw32/lib/gcc/i686-w64-mingw32/6.2.0/plugin/i686-w64-mingw32-odb.so' '-v' '-D' 'PRODUCT_ID=1' '-fplugin-arg-odb-svc-path=/i686-w64-mingw32/lib/gcc/i686-w64-mingw32/6.2.0/include/c++' '-fplugin-arg-odb-svc-path=/i686-w64-mingw32/lib/gcc/i686-w64-mingw32/6.2.0/include/c++/i686-w64-mingw32' '-fplugin-arg-odb-svc-path=/i686-w64-mingw32/lib/gcc/i686-w64-mingw32/6.2.0/include/c++/backward' '-fplugin-arg-odb-svc-path=/i686-w64-mingw32/lib/gcc/i686-w64-mingw32/6.2.0/include' '-fplugin-arg-odb-svc-path=/i686-w64-mingw32//include' '-fplugin-arg-odb-svc-path=/i686-w64-mingw32/lib/gcc/i686-w64-mingw32/6.2.0/include-fixed' '-fplugin-arg-odb-svc-path=/i686-w64-mingw32/lib/gcc/i686-w64-mingw32/6.2.0/../../../../i686-w64-mingw32/include' '-D' 'ODB_COMPILER' '-D' 'ODB_COMPILER_VERSION=2040000' '-D' 'ODB_DATABASE_MSSQL' '-fplugin-arg-odb-database=mssql' '-fplugin-arg-odb-std=c++11' '-fplugin-arg-odb-profile=boost/date-time/posix-time' '-fplugin-arg-odb-generate-query' '-fplugin-arg-odb-output-dir=generated' '-fplugin-arg-odb-svc-file=iCCSettings_model.h' '-mtune=generic' '-march=pentiumpro' /i686-w64-mingw32/libexec/gcc/i686-w64-mingw32/6.2.0/cc1plus -quiet -v -iplugindir=/i686-w64-mingw32/lib/gcc/i686-w64-mingw32/6.2.0/plugin -U_REENTRANT -D PRODUCT_ID=1 -D ODB_COMPILER -D ODB_COMPILER_VERSION=2040000 -D ODB_DATABASE_MSSQL - -iplugindir=/i686-w64-mingw32/lib/gcc/i686-w64-mingw32/6.2.0/plugin -quiet -dumpbase - -mtune=generic -march=pentiumpro -auxbase - -Wunknown-pragmas -Wno-deprecated -std=gnu++11 -version -fplugin=/i686-w64-mingw32/lib/gcc/i686-w64-mingw32/6.2.0/plugin/i686-w64-mingw32-odb.so -fplugin-arg-odb-svc-path=/i686-w64-mingw32/lib/gcc/i686-w64-mingw32/6.2.0/include/c++ -fplugin-arg-odb-svc-path=/i686-w64-mingw32/lib/gcc/i686-w64-mingw32/6.2.0/include/c++/i686-w64-mingw32 -fplugin-arg-odb-svc-path=/i686-w64-mingw32/lib/gcc/i686-w64-mingw32/6.2.0/include/c++/backward -fplugin-arg-odb-svc-path=/i686-w64-mingw32/lib/gcc/i686-w64-mingw32/6.2.0/include -fplugin-arg-odb-svc-path=/i686-w64-mingw32//include -fplugin-arg-odb-svc-path=/i686-w64-mingw32/lib/gcc/i686-w64-mingw32/6.2.0/include-fixed -fplugin-arg-odb-svc-path=/i686-w64-mingw32/lib/gcc/i686-w64-mingw32/6.2.0/../../../../i686-w64-mingw32/include -fplugin-arg-odb-database=mssql -fplugin-arg-odb-std=c++11 -fplugin-arg-odb-profile=boost/date-time/posix-time -fplugin-arg-odb-generate-query -fplugin-arg-odb-output-dir=generated -fplugin-arg-odb-svc-file=iCCSettings_model.h -o -.s cc1plus: error: plugin odb should be specified before -fplugin-arg-odb-svc-path=/i686-w64-mingw32/lib/gcc/i686-w64-mingw32/6.2.0/include/c++ in the command line cc1plus: error: plugin odb should be specified before -fplugin-arg-odb-svc-path=/i686-w64-mingw32/lib/gcc/i686-w64-mingw32/6.2.0/include/c++/i686-w64-mingw32 in the command line cc1plus: error: plugin odb should be specified before -fplugin-arg-odb-svc-path=/i686-w64-mingw32/lib/gcc/i686-w64-mingw32/6.2.0/include/c++/backward in the command line cc1plus: error: plugin odb should be specified before -fplugin-arg-odb-svc-path=/i686-w64-mingw32/lib/gcc/i686-w64-mingw32/6.2.0/include in the command line cc1plus: error: plugin odb should be specified before -fplugin-arg-odb-svc-path=/i686-w64-mingw32//include in the command line cc1plus: error: plugin odb should be specified before -fplugin-arg-odb-svc-path=/i686-w64-mingw32/lib/gcc/i686-w64-mingw32/6.2.0/include-fixed in the command line cc1plus: error: plugin odb should be specified before -fplugin-arg-odb-svc-path=/i686-w64-mingw32/lib/gcc/i686-w64-mingw32/6.2.0/../../../../i686-w64-mingw32/include in the command line cc1plus: error: plugin odb should be specified before -fplugin-arg-odb-database=mssql in the command line cc1plus: error: plugin odb should be specified before -fplugin-arg-odb-std=c++11 in the command line cc1plus: error: plugin odb should be specified before -fplugin-arg-odb-profile=boost/date-time/posix-time in the command line cc1plus: error: plugin odb should be specified before -fplugin-arg-odb-generate-query in the command line cc1plus: error: plugin odb should be specified before -fplugin-arg-odb-output-dir=generated in the command line cc1plus: error: plugin odb should be specified before -fplugin-arg-odb-svc-file=iCCSettings_model.h in the command line cc1plus: plugin.cxx:348: int plugin_init(plugin_name_args*, plugin_gcc_version*): Assertion `ops.database_specified ()' failed. (null):0: confused by earlier errors, bailing out Here's the output of the readelf tool. BTW all the mentioned DLLs are valid host platform dlls, they are not target platform binaries of course. user@chronoscepter:/i686-w64-mingw32/lib/gcc/i686-w64-mingw32/6.2.0/plugin$ readelf -d i686-w64-mingw32-odb.so Is it possible that the problem is because of "Library soname" which is different from the filename ? Dynamic section at offset 0x6e8f68 contains 28 entries: Tag Type Name/Value 0x0000000000000001 (NEEDED) Shared library: [libcutl-1.10.so] 0x0000000000000001 (NEEDED) Shared library: [libstdc++.so.6] 0x0000000000000001 (NEEDED) Shared library: [libc.so.6] 0x0000000000000001 (NEEDED) Shared library: [libgcc_s.so.1] 0x000000000000000e (SONAME) Library soname: [odb.so] 0x000000000000000c (INIT) 0x250d98 0x000000000000000d (FINI) 0x54bde8 0x0000000000000019 (INIT_ARRAY) 0x818c30 0x000000000000001b (INIT_ARRAYSZ) 792 (bytes) 0x000000000000001a (FINI_ARRAY) 0x818f48 0x000000000000001c (FINI_ARRAYSZ) 8 (bytes) 0x000000006ffffef5 (GNU_HASH) 0x1f0 0x0000000000000005 (STRTAB) 0x573c0 0x0000000000000006 (SYMTAB) 0x14e38 0x000000000000000a (STRSZ) 727718 (bytes) 0x000000000000000b (SYMENT) 24 (bytes) 0x0000000000000003 (PLTGOT) 0x8ed000 0x0000000000000002 (PLTRELSZ) 54312 (bytes) 0x0000000000000014 (PLTREL) RELA 0x0000000000000017 (JMPREL) 0x243970 0x0000000000000007 (RELA) 0x10e7f0 0x0000000000000008 (RELASZ) 1266048 (bytes) 0x0000000000000009 (RELAENT) 24 (bytes) 0x000000006ffffffe (VERNEED) 0x10e6e0 0x000000006fffffff (VERNEEDNUM) 3 0x000000006ffffff0 (VERSYM) 0x108e66 0x000000006ffffff9 (RELACOUNT) 8587 0x0000000000000000 (NULL) 0x0 Best regards, Sten Kultakangas From ratkaisut at gmail.com Sun Oct 9 09:43:42 2016 From: ratkaisut at gmail.com (Sten Kultakangas) Date: Sun Oct 9 09:43:54 2016 Subject: [odb-users] Re: using ODB with cross-compiler x86_64-linux-gnu -> i686-w64-mingw In-Reply-To: References: Message-ID: Hello I made a workaround so that the name of the plugin now matches the filename and it gets loaded. However, it does not generate output files. So the main cause is that GCC plugin API was changed in version 6.2.0 and ODB is not compatible with it anymore ? Or can you suggest a quick fix so i can edit ODB and/or GCC source code to make the tandem working ? user@chronoscepter:~/workspace/ICCBackend$ /i686-w64-mingw32/bin/i686-w64-mingw32-odb -v --database mssql --std c++11 --profile boost/date-time/posix-time --generate-query -DPRODUCT_ID=1 --output-dir generated iCCSettings_model.h Profile search paths: /i686-w64-mingw32/lib/gcc/i686-w64-mingw32/6.2.0/include/c++ /i686-w64-mingw32/lib/gcc/i686-w64-mingw32/6.2.0/include/c++/i686-w64-mingw32 /i686-w64-mingw32/lib/gcc/i686-w64-mingw32/6.2.0/include/c++/backward /i686-w64-mingw32/lib/gcc/i686-w64-mingw32/6.2.0/include /i686-w64-mingw32//include /i686-w64-mingw32/lib/gcc/i686-w64-mingw32/6.2.0/include-fixed /i686-w64-mingw32/lib/gcc/i686-w64-mingw32/6.2.0/../../../../i686-w64-mingw32/include Compiling iCCSettings_model.h i686-w64-mingw32-g++ -x c++ -std=gnu++0x -S -Wunknown-pragmas -Wno-deprecated -fplugin=/i686-w64-mingw32/lib/gcc/i686-w64-mingw32/6.2.0/plugin/i686-w64-mingw32-odb.so -v -DPRODUCT_ID=1 -fplugin-arg-odb-svc-path=/i686-w64-mingw32/lib/gcc/i686-w64-mingw32/6.2.0/include/c++ -fplugin-arg-odb-svc-path=/i686-w64-mingw32/lib/gcc/i686-w64-mingw32/6.2.0/include/c++/i686-w64-mingw32 -fplugin-arg-odb-svc-path=/i686-w64-mingw32/lib/gcc/i686-w64-mingw32/6.2.0/include/c++/backward -fplugin-arg-odb-svc-path=/i686-w64-mingw32/lib/gcc/i686-w64-mingw32/6.2.0/include -fplugin-arg-odb-svc-path=/i686-w64-mingw32//include -fplugin-arg-odb-svc-path=/i686-w64-mingw32/lib/gcc/i686-w64-mingw32/6.2.0/include-fixed -fplugin-arg-odb-svc-path=/i686-w64-mingw32/lib/gcc/i686-w64-mingw32/6.2.0/../../../../i686-w64-mingw32/include -DODB_COMPILER -DODB_COMPILER_VERSION=2040000 -DODB_DATABASE_MSSQL -fplugin-arg-odb-database=mssql -fplugin-arg-odb-std=c++11 -fplugin-arg-odb-profile=boost/date-time/posix-time -fplugin-arg-odb-generate-query -fplugin-arg-odb-output-dir=generated -fplugin-arg-odb-svc-file=iCCSettings_model.h - Using built-in specs. COLLECT_GCC=i686-w64-mingw32-g++ Target: i686-w64-mingw32 Configured with: ../gcc-6.2.0/configure --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=i686-w64-mingw32 --prefix=/i686-w64-mingw32 --with-sysroot=/i686-w64-mingw32 --disable-multilib --enable-languages=c,c++ --enable-lto --with-dwarf2 --enable-fully-dynamic-string --enable-version-specific-runtime-libs --enable-libgomp --disable-nls --enable-checking=release --disable-win32-registry --disable-libgcj --with-local-prefix=/ --enable-plugin --enable-threads=win32 --enable-__cxa_atexit --enable-default-ssp --disable-shared --enable-static Thread model: win32 gcc version 6.2.0 (GCC) COLLECT_GCC_OPTIONS='-std=gnu++11' '-S' '-Wunknown-pragmas' '-Wno-deprecated' '-fplugin=/i686-w64-mingw32/lib/gcc/i686-w64-mingw32/6.2.0/plugin/i686-w64-mingw32-odb.so' '-v' '-D' 'PRODUCT_ID=1' '-fplugin-arg-odb-svc-path=/i686-w64-mingw32/lib/gcc/i686-w64-mingw32/6.2.0/include/c++' '-fplugin-arg-odb-svc-path=/i686-w64-mingw32/lib/gcc/i686-w64-mingw32/6.2.0/include/c++/i686-w64-mingw32' '-fplugin-arg-odb-svc-path=/i686-w64-mingw32/lib/gcc/i686-w64-mingw32/6.2.0/include/c++/backward' '-fplugin-arg-odb-svc-path=/i686-w64-mingw32/lib/gcc/i686-w64-mingw32/6.2.0/include' '-fplugin-arg-odb-svc-path=/i686-w64-mingw32//include' '-fplugin-arg-odb-svc-path=/i686-w64-mingw32/lib/gcc/i686-w64-mingw32/6.2.0/include-fixed' '-fplugin-arg-odb-svc-path=/i686-w64-mingw32/lib/gcc/i686-w64-mingw32/6.2.0/../../../../i686-w64-mingw32/include' '-D' 'ODB_COMPILER' '-D' 'ODB_COMPILER_VERSION=2040000' '-D' 'ODB_DATABASE_MSSQL' '-fplugin-arg-odb-database=mssql' '-fplugin-arg-odb-std=c++11' '-fplugin-arg-odb-profile=boost/date-time/posix-time' '-fplugin-arg-odb-generate-query' '-fplugin-arg-odb-output-dir=generated' '-fplugin-arg-odb-svc-file=iCCSettings_model.h' '-mtune=generic' '-march=pentiumpro' /i686-w64-mingw32/libexec/gcc/i686-w64-mingw32/6.2.0/cc1plus -quiet -v -iplugindir=/i686-w64-mingw32/lib/gcc/i686-w64-mingw32/6.2.0/plugin -U_REENTRANT -D PRODUCT_ID=1 -D ODB_COMPILER -D ODB_COMPILER_VERSION=2040000 -D ODB_DATABASE_MSSQL - -iplugindir=/i686-w64-mingw32/lib/gcc/i686-w64-mingw32/6.2.0/plugin -quiet -dumpbase - -mtune=generic -march=pentiumpro -auxbase - -Wunknown-pragmas -Wno-deprecated -std=gnu++11 -version -fplugin=/i686-w64-mingw32/lib/gcc/i686-w64-mingw32/6.2.0/plugin/i686-w64-mingw32-odb.so -fplugin-arg-odb-svc-path=/i686-w64-mingw32/lib/gcc/i686-w64-mingw32/6.2.0/include/c++ -fplugin-arg-odb-svc-path=/i686-w64-mingw32/lib/gcc/i686-w64-mingw32/6.2.0/include/c++/i686-w64-mingw32 -fplugin-arg-odb-svc-path=/i686-w64-mingw32/lib/gcc/i686-w64-mingw32/6.2.0/include/c++/backward -fplugin-arg-odb-svc-path=/i686-w64-mingw32/lib/gcc/i686-w64-mingw32/6.2.0/include -fplugin-arg-odb-svc-path=/i686-w64-mingw32//include -fplugin-arg-odb-svc-path=/i686-w64-mingw32/lib/gcc/i686-w64-mingw32/6.2.0/include-fixed -fplugin-arg-odb-svc-path=/i686-w64-mingw32/lib/gcc/i686-w64-mingw32/6.2.0/../../../../i686-w64-mingw32/include -fplugin-arg-odb-database=mssql -fplugin-arg-odb-std=c++11 -fplugin-arg-odb-profile=boost/date-time/posix-time -fplugin-arg-odb-generate-query -fplugin-arg-odb-output-dir=generated -fplugin-arg-odb-svc-file=iCCSettings_model.h -o -.s GNU C++11 (GCC) version 6.2.0 (i686-w64-mingw32) compiled by GNU C version 6.2.0 20160901, GMP version 5.1.3, MPFR version 3.1.3, MPC version 1.0.1, isl version 0.15 GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 Versions of loaded plugins: i686-w64-mingw32-odb: 2.4.0 ignoring duplicate directory "/i686-w64-mingw32/mingw/include" #include "..." search starts here: #include <...> search starts here: /i686-w64-mingw32/lib/gcc/i686-w64-mingw32/6.2.0/include/c++ /i686-w64-mingw32/lib/gcc/i686-w64-mingw32/6.2.0/include/c++/i686-w64-mingw32 /i686-w64-mingw32/lib/gcc/i686-w64-mingw32/6.2.0/include/c++/backward /i686-w64-mingw32/lib/gcc/i686-w64-mingw32/6.2.0/include /i686-w64-mingw32//include /i686-w64-mingw32/lib/gcc/i686-w64-mingw32/6.2.0/include-fixed /i686-w64-mingw32/lib/gcc/i686-w64-mingw32/6.2.0/../../../../i686-w64-mingw32/include End of search list. GNU C++11 (GCC) version 6.2.0 (i686-w64-mingw32) compiled by GNU C version 6.2.0 20160901, GMP version 5.1.3, MPFR version 3.1.3, MPC version 1.0.1, isl version 0.15 GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 Versions of loaded plugins: i686-w64-mingw32-odb: 2.4.0 Compiler executable checksum: 8111d2c49b90085811565993673d80e9 *** WARNING *** there are active plugins, do not report this as a bug unless you can reproduce it without enabling any plugins. Event | Plugins PLUGIN_START_UNIT | i686-w64-mingw32-odb PLUGIN_PRAGMAS | i686-w64-mingw32-odb PLUGIN_OVERRIDE_GATE | i686-w64-mingw32-odb In file included from /i686-w64-mingw32/include/odb/container-traits.hxx:217:0, from :9: /i686-w64-mingw32/include/odb/std-unordered-set-traits.hxx:122:1: internal compiler error: Segmentation fault } ^ 0x7f0d8d63602c cutl::fs::basic_path::basic_path(char const*) /usr/include/cutl/fs/path.hxx:164 0x7f0d8d63602c generate_impl /toolchain/odb-2.4.0/odb/include.cxx:558 0x7f0d8d674655 generator::generate(options const&, features&, semantics::unit&, cutl::fs::basic_path const&, std::vector, std::allocator > > const&) /toolchain/odb-2.4.0/odb/generator.cxx:518 0x7f0d8d693684 gate_callback /toolchain/odb-2.4.0/odb/plugin.cxx:222 Please submit a full bug report, with preprocessed source if appropriate. Please include the complete backtrace with any bug report. See for instructions. On Sun, Oct 9, 2016 at 7:39 AM, Sten Kultakangas wrote: > Hello > > I have built ODB to be used with the cross-compiler, however, ODB > doesn't seem to pass the required parameters to the g++ plugin > interface. I have checked that > /i686-w64-mingw32/lib/gcc/i686-w64-mingw32/6.2.0/plugin/i686-w64-mingw32-odb.so > is actually ELF file, not MZ. > > Another possibility is that the plugin interface in gcc 6.2.0 is broken. > > BTW i had to make a symbolic link from the original odb.so file to > i686-w64-mingw32-odb.so > Until that it reported error "no ODB plugin in GCC plugin directory" > despite the --program-prefix configuration option. Also i had to make > some changes before i managed to compile it with gcc 6.2.0. Namely it > plugin API had somewhat changed and coretypes.h must not anymore be > included directly with C-linkage but rather gcc-plugin.h must be > included instead. Also ANON_AGGRNAME_P is not a valid symbol anymore > but rather anon_aggrname_p shall be used. Also there where a conflict > between toupper, tolower etc macros with the corresponding STL class > member functions so i had to #undef them before #include . > Also i had to change new_node to new_node in > parser.cxx. But it's a different story > > > In the end of this email you will find the output of the readelf tool. > Here's the output of the ODB: > > > user@chronoscepter:~/workspace/ICCBackend$ > /i686-w64-mingw32/bin/i686-w64-mingw32-odb -v --database mssql --std > c++11 --profile boost/date-time/posix-time --generate-query > -DPRODUCT_ID=1 --output-dir generated iCCSettings_model.h > Profile search paths: > /i686-w64-mingw32/lib/gcc/i686-w64-mingw32/6.2.0/include/c++ > /i686-w64-mingw32/lib/gcc/i686-w64-mingw32/6.2.0/include/c++/i686-w64-mingw32 > /i686-w64-mingw32/lib/gcc/i686-w64-mingw32/6.2.0/include/c++/backward > /i686-w64-mingw32/lib/gcc/i686-w64-mingw32/6.2.0/include > /i686-w64-mingw32//include > /i686-w64-mingw32/lib/gcc/i686-w64-mingw32/6.2.0/include-fixed > /i686-w64-mingw32/lib/gcc/i686-w64-mingw32/6.2.0/../../../../i686-w64-mingw32/include > Compiling iCCSettings_model.h > i686-w64-mingw32-g++ -x c++ -std=gnu++0x -S -Wunknown-pragmas > -Wno-deprecated > -fplugin=/i686-w64-mingw32/lib/gcc/i686-w64-mingw32/6.2.0/plugin/i686-w64-mingw32-odb.so > -v -DPRODUCT_ID=1 > -fplugin-arg-odb-svc-path=/i686-w64-mingw32/lib/gcc/i686-w64-mingw32/6.2.0/include/c++ > -fplugin-arg-odb-svc-path=/i686-w64-mingw32/lib/gcc/i686-w64-mingw32/6.2.0/include/c++/i686-w64-mingw32 > -fplugin-arg-odb-svc-path=/i686-w64-mingw32/lib/gcc/i686-w64-mingw32/6.2.0/include/c++/backward > -fplugin-arg-odb-svc-path=/i686-w64-mingw32/lib/gcc/i686-w64-mingw32/6.2.0/include > -fplugin-arg-odb-svc-path=/i686-w64-mingw32//include > -fplugin-arg-odb-svc-path=/i686-w64-mingw32/lib/gcc/i686-w64-mingw32/6.2.0/include-fixed > -fplugin-arg-odb-svc-path=/i686-w64-mingw32/lib/gcc/i686-w64-mingw32/6.2.0/../../../../i686-w64-mingw32/include > -DODB_COMPILER -DODB_COMPILER_VERSION=2040000 -DODB_DATABASE_MSSQL > -fplugin-arg-odb-database=mssql -fplugin-arg-odb-std=c++11 > -fplugin-arg-odb-profile=boost/date-time/posix-time > -fplugin-arg-odb-generate-query -fplugin-arg-odb-output-dir=generated > -fplugin-arg-odb-svc-file=iCCSettings_model.h - > Using built-in specs. > COLLECT_GCC=i686-w64-mingw32-g++ > Target: i686-w64-mingw32 > Configured with: ../gcc-6.2.0/configure --build=x86_64-linux-gnu > --host=x86_64-linux-gnu --target=i686-w64-mingw32 > --prefix=/i686-w64-mingw32 --with-sysroot=/i686-w64-mingw32 > --disable-multilib --enable-languages=c,c++ --enable-lto --with-dwarf2 > --enable-fully-dynamic-string --enable-version-specific-runtime-libs > --enable-libgomp --disable-nls --enable-checking=release > --disable-win32-registry --disable-libgcj --with-local-prefix=/ > --enable-plugin --enable-threads=win32 --enable-__cxa_atexit > --enable-default-ssp --disable-shared --enable-static > Thread model: win32 > gcc version 6.2.0 (GCC) > COLLECT_GCC_OPTIONS='-std=gnu++11' '-S' '-Wunknown-pragmas' > '-Wno-deprecated' > '-fplugin=/i686-w64-mingw32/lib/gcc/i686-w64-mingw32/6.2.0/plugin/i686-w64-mingw32-odb.so' > '-v' '-D' 'PRODUCT_ID=1' > '-fplugin-arg-odb-svc-path=/i686-w64-mingw32/lib/gcc/i686-w64-mingw32/6.2.0/include/c++' > '-fplugin-arg-odb-svc-path=/i686-w64-mingw32/lib/gcc/i686-w64-mingw32/6.2.0/include/c++/i686-w64-mingw32' > '-fplugin-arg-odb-svc-path=/i686-w64-mingw32/lib/gcc/i686-w64-mingw32/6.2.0/include/c++/backward' > '-fplugin-arg-odb-svc-path=/i686-w64-mingw32/lib/gcc/i686-w64-mingw32/6.2.0/include' > '-fplugin-arg-odb-svc-path=/i686-w64-mingw32//include' > '-fplugin-arg-odb-svc-path=/i686-w64-mingw32/lib/gcc/i686-w64-mingw32/6.2.0/include-fixed' > '-fplugin-arg-odb-svc-path=/i686-w64-mingw32/lib/gcc/i686-w64-mingw32/6.2.0/../../../../i686-w64-mingw32/include' > '-D' 'ODB_COMPILER' '-D' 'ODB_COMPILER_VERSION=2040000' '-D' > 'ODB_DATABASE_MSSQL' '-fplugin-arg-odb-database=mssql' > '-fplugin-arg-odb-std=c++11' > '-fplugin-arg-odb-profile=boost/date-time/posix-time' > '-fplugin-arg-odb-generate-query' > '-fplugin-arg-odb-output-dir=generated' > '-fplugin-arg-odb-svc-file=iCCSettings_model.h' '-mtune=generic' > '-march=pentiumpro' > /i686-w64-mingw32/libexec/gcc/i686-w64-mingw32/6.2.0/cc1plus -quiet > -v -iplugindir=/i686-w64-mingw32/lib/gcc/i686-w64-mingw32/6.2.0/plugin > -U_REENTRANT -D PRODUCT_ID=1 -D ODB_COMPILER -D > ODB_COMPILER_VERSION=2040000 -D ODB_DATABASE_MSSQL - > -iplugindir=/i686-w64-mingw32/lib/gcc/i686-w64-mingw32/6.2.0/plugin > -quiet -dumpbase - -mtune=generic -march=pentiumpro -auxbase - > -Wunknown-pragmas -Wno-deprecated -std=gnu++11 -version > -fplugin=/i686-w64-mingw32/lib/gcc/i686-w64-mingw32/6.2.0/plugin/i686-w64-mingw32-odb.so > -fplugin-arg-odb-svc-path=/i686-w64-mingw32/lib/gcc/i686-w64-mingw32/6.2.0/include/c++ > -fplugin-arg-odb-svc-path=/i686-w64-mingw32/lib/gcc/i686-w64-mingw32/6.2.0/include/c++/i686-w64-mingw32 > -fplugin-arg-odb-svc-path=/i686-w64-mingw32/lib/gcc/i686-w64-mingw32/6.2.0/include/c++/backward > -fplugin-arg-odb-svc-path=/i686-w64-mingw32/lib/gcc/i686-w64-mingw32/6.2.0/include > -fplugin-arg-odb-svc-path=/i686-w64-mingw32//include > -fplugin-arg-odb-svc-path=/i686-w64-mingw32/lib/gcc/i686-w64-mingw32/6.2.0/include-fixed > -fplugin-arg-odb-svc-path=/i686-w64-mingw32/lib/gcc/i686-w64-mingw32/6.2.0/../../../../i686-w64-mingw32/include > -fplugin-arg-odb-database=mssql -fplugin-arg-odb-std=c++11 > -fplugin-arg-odb-profile=boost/date-time/posix-time > -fplugin-arg-odb-generate-query -fplugin-arg-odb-output-dir=generated > -fplugin-arg-odb-svc-file=iCCSettings_model.h -o -.s > cc1plus: error: plugin odb should be specified before > -fplugin-arg-odb-svc-path=/i686-w64-mingw32/lib/gcc/i686-w64-mingw32/6.2.0/include/c++ > in the command line > cc1plus: error: plugin odb should be specified before > -fplugin-arg-odb-svc-path=/i686-w64-mingw32/lib/gcc/i686-w64-mingw32/6.2.0/include/c++/i686-w64-mingw32 > in the command line > cc1plus: error: plugin odb should be specified before > -fplugin-arg-odb-svc-path=/i686-w64-mingw32/lib/gcc/i686-w64-mingw32/6.2.0/include/c++/backward > in the command line > cc1plus: error: plugin odb should be specified before > -fplugin-arg-odb-svc-path=/i686-w64-mingw32/lib/gcc/i686-w64-mingw32/6.2.0/include > in the command line > cc1plus: error: plugin odb should be specified before > -fplugin-arg-odb-svc-path=/i686-w64-mingw32//include in the command > line > cc1plus: error: plugin odb should be specified before > -fplugin-arg-odb-svc-path=/i686-w64-mingw32/lib/gcc/i686-w64-mingw32/6.2.0/include-fixed > in the command line > cc1plus: error: plugin odb should be specified before > -fplugin-arg-odb-svc-path=/i686-w64-mingw32/lib/gcc/i686-w64-mingw32/6.2.0/../../../../i686-w64-mingw32/include > in the command line > cc1plus: error: plugin odb should be specified before > -fplugin-arg-odb-database=mssql in the command line > cc1plus: error: plugin odb should be specified before > -fplugin-arg-odb-std=c++11 in the command line > cc1plus: error: plugin odb should be specified before > -fplugin-arg-odb-profile=boost/date-time/posix-time in the command > line > cc1plus: error: plugin odb should be specified before > -fplugin-arg-odb-generate-query in the command line > cc1plus: error: plugin odb should be specified before > -fplugin-arg-odb-output-dir=generated in the command line > cc1plus: error: plugin odb should be specified before > -fplugin-arg-odb-svc-file=iCCSettings_model.h in the command line > cc1plus: plugin.cxx:348: int plugin_init(plugin_name_args*, > plugin_gcc_version*): Assertion `ops.database_specified ()' failed. > (null):0: confused by earlier errors, bailing out > > > > Here's the output of the readelf tool. BTW all the mentioned DLLs are > valid host platform dlls, they are not target platform binaries of > course. > > > user@chronoscepter:/i686-w64-mingw32/lib/gcc/i686-w64-mingw32/6.2.0/plugin$ > readelf -d i686-w64-mingw32-odb.so Is it possible that the problem is > because of "Library soname" which is different from the filename ? > > Dynamic section at offset 0x6e8f68 contains 28 entries: > Tag Type Name/Value > 0x0000000000000001 (NEEDED) Shared library: [libcutl-1.10.so] > 0x0000000000000001 (NEEDED) Shared library: [libstdc++.so.6] > 0x0000000000000001 (NEEDED) Shared library: [libc.so.6] > 0x0000000000000001 (NEEDED) Shared library: [libgcc_s.so.1] > 0x000000000000000e (SONAME) Library soname: [odb.so] > 0x000000000000000c (INIT) 0x250d98 > 0x000000000000000d (FINI) 0x54bde8 > 0x0000000000000019 (INIT_ARRAY) 0x818c30 > 0x000000000000001b (INIT_ARRAYSZ) 792 (bytes) > 0x000000000000001a (FINI_ARRAY) 0x818f48 > 0x000000000000001c (FINI_ARRAYSZ) 8 (bytes) > 0x000000006ffffef5 (GNU_HASH) 0x1f0 > 0x0000000000000005 (STRTAB) 0x573c0 > 0x0000000000000006 (SYMTAB) 0x14e38 > 0x000000000000000a (STRSZ) 727718 (bytes) > 0x000000000000000b (SYMENT) 24 (bytes) > 0x0000000000000003 (PLTGOT) 0x8ed000 > 0x0000000000000002 (PLTRELSZ) 54312 (bytes) > 0x0000000000000014 (PLTREL) RELA > 0x0000000000000017 (JMPREL) 0x243970 > 0x0000000000000007 (RELA) 0x10e7f0 > 0x0000000000000008 (RELASZ) 1266048 (bytes) > 0x0000000000000009 (RELAENT) 24 (bytes) > 0x000000006ffffffe (VERNEED) 0x10e6e0 > 0x000000006fffffff (VERNEEDNUM) 3 > 0x000000006ffffff0 (VERSYM) 0x108e66 > 0x000000006ffffff9 (RELACOUNT) 8587 > 0x0000000000000000 (NULL) 0x0 > > > > Best regards, > Sten Kultakangas From obermann.lukas at gmail.com Sun Oct 9 10:43:24 2016 From: obermann.lukas at gmail.com (Lukas Obermann) Date: Sun Oct 9 10:43:49 2016 Subject: [odb-users] Querying on Containers In-Reply-To: References: Message-ID: Hi Boris, so, object loading works like a charm on the vectors. Thanks! But still can't figure out how to access the element in ClassC in the query. Can you help on that? Thanks, Lukas Lukas Obermann schrieb am Fr., 7. Okt. 2016 um 17:21 Uhr: > Thanks, > > about the distinct, do I have to place this once at the end or after each > object? > > > > Boris Kolpackov schrieb am Fr., 7. Okt. 2016 um > 17:07 Uhr: > > Hi Lukas, > > Lukas Obermann writes: > > > class main > > { > > odb::lazy_shared_ptr ptr_a; > > std::vector< odb::lazy_shared_ptr > list_a; > > std::vector< odb::lazy_shared_ptr > ptr_b > > } > > > > class ClassA > > { > > std::string iNeedToBeQueried; > > } > > > > class ClassB > > { > > std::string iNeedToBeQueried; > > odb::lazy_shared_ptr ptr_c; > > } > > > > class ClassC > > { > > std::string iNeedToBeQueried; > > } > > So you have containers of pointers -- this is even easier. > > > > So, ptr_a is no issue, but I am not able to figure out how to add the two > > vectors to the view and also access ClassC, all at the same time. > > You just add their classes to the view. Check this earlier thread, it > is exactly the same problem: > > http://codesynthesis.com/pipermail/odb-users/2016-August/003412.html > > Boris > > From boris at codesynthesis.com Sun Oct 9 12:45:56 2016 From: boris at codesynthesis.com (Boris Kolpackov) Date: Sun Oct 9 12:46:06 2016 Subject: [odb-users] Re: using ODB with cross-compiler x86_64-linux-gnu -> i686-w64-mingw In-Reply-To: References: Message-ID: Hi Sten, So you are trying to use a cross-compiler as the underlying C++ compiler. I don't think anyone tried this but I don't see why it shouldn't work. Once you make it work, a summary of steps involved would be much appreciated. Sten Kultakangas writes: > So the main cause is that GCC plugin API was changed in version 6.2.0 > and ODB is not compatible with it anymore? Yes, that's the standard story with each major GCC version. Can you try the latest pre-release which has GCC 6 compatibility fixes? http://codesynthesis.com/~boris/tmp/odb/pre-release/a9/ Boris From ratkaisut at gmail.com Sun Oct 9 15:42:55 2016 From: ratkaisut at gmail.com (Sten Kultakangas) Date: Sun Oct 9 15:43:07 2016 Subject: [odb-users] Re: using ODB with cross-compiler x86_64-linux-gnu -> i686-w64-mingw In-Reply-To: References: Message-ID: Hello Boris I have just made the ODB working with the underlying cross-compiler x86_64-linux-gnu->i686-w64-mingw. I downloaded and built the latest tools from your GIT and configured ODB with ./configure --build=x86_64-linux-gnu --host=x86_64-linux-gnu --prefix=/i686-w64-mingw32 --with-gxx-name=/i686-w64-mingw32/bin/i686-w64-mingw32-g++ --with-gcc-plugin-dir=/i686-w64-mingw32/lib/gcc/i686-w64-mingw32/6.2.0/plugin CPPFLAGS='-fmax-errors=1 -I/i686-w64-mingw32/lib/gcc/i686-w64-mingw32/6.2.0/plugin/include' (note: i did not use program-prefix anymore) Also configured libodb, libodb-mssql and libodb-boost with ./configure --build=x86_64-linux-gnu --host=i686-w64-mingw32 --prefix=/i686-w64-mingw32 --disable-shared --enable-static All the ODB components worked out of the box without needing to modify the sources. The hardest problem was to build libboost using the cross-compiler as it did not produce libboost_thread by default because of a bug in boost_1_62_0/libs/thread/build/Jamfile.v2 A quickfix was to make the following modification: local rule default_threadapi ( ) { local api = pthread ; #if [ os.name ] = "NT" { api = win32 ; } api = win32 ; #xxxxx return $(api) ; } Anyways libboost_thread is not needed by ODB but it was needed by ICCBackend being developed so i could not proceed with testing without libboost_thread. Now I uploaded the executable to a Windows server and got the following output: C:\Users\Administrator\Desktop\ICCBackend>ICCBackend.exe 35:17.621164 main Starting backend 35:17.628000 ...ICCBackend Registering handler for signal 2 35:17.628977 ...ICCBackend Registering handler for signal 21 35:17.628977 ...ICCBackend Registering handler for signal 15 35:17.628977 ...ICCBackend Attempting to bind to 127.0.0.1:8090 35:17.629953 ...ICCBackend Attempting to bind to [::1]:8090 35:17.630930 ...ICCBackend Attempting to bind to 127.0.0.1:59402 35:17.631907 ...ICCBackend Attempting to bind to [::1]:59402 35:17.631907 ...Run Running backend 35:22.632099 ...RefreshData Instantiating database connector 35:22.636005 ...RefreshData Caught signal 11 (invalid memory access) 35:22.683858 ...RefreshData 0xffffffff: ??? 35:22.684835 ...RefreshData 0xffffffff: ??? 35:22.684835 ...RefreshData 0x00000001: ??? 35:22.685812 ...RefreshData 0x0000000c: ??? 35:22.685812 ...RefreshData 0x00000001: ??? 35:22.685812 ...RefreshData 0x00000003: ??? 35:22.686788 ...RefreshData 0x00000004: ??? 35:22.686788 ...RefreshData 0xffffffff: ??? The exception was caused by the following code: void ICCBackend::RefreshData() { LogScope(); filter2iccSettings.clear(); id2skillList.clear(); extension2skillList.clear(); id2agentMonitor.clear(); id2agentList.clear(); kampanjaQueueSummary.clear(); iccSettings.clear(); iccWallboard.clear(); skillList.clear(); skillMonitor.clear(); agentMonitor.clear(); agentList.clear(); Log(trace) << "Instantiating database connector"; unique_ptr db(new odb::mssql::database("testbench", "test12345", "", "testbench\\SQLEXPRESS2005")); odb::transaction t(db->begin()); Log(trace) << "Refreshing iCCSettings data"; for(const auto& i : db->query()) { iccSettings.push_back(i); filter2iccSettings[i.Filter_lcase] = &iccSettings.back(); } //... } So the good news is that the problem is not with the code synthesized by ODB (at least yet), but rather somewhere between libodb-mssql and odbc32.dll The bad news is that i don't have Windows locally and the remote testbench doesn't have any debugger. Sadly libbacktrace compiled with the cross-compiler didn't produce a correct output. I'll investigate the problem tomorrow when i get to the Windows workstation. Best regards, Sten Kultakangas On Sun, Oct 9, 2016 at 7:45 PM, Boris Kolpackov wrote: > Hi Sten, > > So you are trying to use a cross-compiler as the underlying C++ compiler. > I don't think anyone tried this but I don't see why it shouldn't work. Once > you make it work, a summary of steps involved would be much appreciated. > > Sten Kultakangas writes: > >> So the main cause is that GCC plugin API was changed in version 6.2.0 >> and ODB is not compatible with it anymore? > > Yes, that's the standard story with each major GCC version. Can you try > the latest pre-release which has GCC 6 compatibility fixes? > > http://codesynthesis.com/~boris/tmp/odb/pre-release/a9/ > > Boris From odb at a-cunningham.com Sun Oct 9 17:04:14 2016 From: odb at a-cunningham.com (Andrew Cunningham) Date: Sun Oct 9 17:04:28 2016 Subject: [odb-users] Re: using ODB with cross-compiler x86_64-linux-gnu -> i686-w64-mingw In-Reply-To: References: Message-ID: Hi Sten, I am confused as to why you are trying to do this when the ODB compiler and libraries are available on Windows. Maybe you can explain what the goal is? Andrew On Sun, Oct 9, 2016 at 12:42 PM, Sten Kultakangas wrote: > Hello Boris > > I have just made the ODB working with the underlying cross-compiler > x86_64-linux-gnu->i686-w64-mingw. I downloaded and built the latest > tools from your GIT and configured ODB with > > ./configure --build=x86_64-linux-gnu --host=x86_64-linux-gnu > --prefix=/i686-w64-mingw32 > --with-gxx-name=/i686-w64-mingw32/bin/i686-w64-mingw32-g++ > --with-gcc-plugin-dir=/i686-w64-mingw32/lib/gcc/i686-w64- > mingw32/6.2.0/plugin > CPPFLAGS='-fmax-errors=1 > -I/i686-w64-mingw32/lib/gcc/i686-w64-mingw32/6.2.0/plugin/include' > > (note: i did not use program-prefix anymore) > > Also configured libodb, libodb-mssql and libodb-boost with > ./configure --build=x86_64-linux-gnu --host=i686-w64-mingw32 > --prefix=/i686-w64-mingw32 --disable-shared --enable-static > > All the ODB components worked out of the box without needing to modify > the sources. The hardest problem was to build libboost using the > cross-compiler as it did not produce libboost_thread by default > because of a bug in > boost_1_62_0/libs/thread/build/Jamfile.v2 > > A quickfix was to make the following modification: > > local rule default_threadapi ( ) > { > local api = pthread ; > #if [ os.name ] = "NT" { api = win32 ; } > api = win32 ; #xxxxx > return $(api) ; > } > > Anyways libboost_thread is not needed by ODB but it was needed by > ICCBackend being developed so i could not proceed with testing without > libboost_thread. > > Now I uploaded the executable to a Windows server and got the following > output: > > C:\Users\Administrator\Desktop\ICCBackend>ICCBackend.exe > 35:17.621164 main Starting backend > 35:17.628000 ...ICCBackend Registering handler for signal 2 > 35:17.628977 ...ICCBackend Registering handler for signal 21 > 35:17.628977 ...ICCBackend Registering handler for signal 15 > 35:17.628977 ...ICCBackend Attempting to bind to 127.0.0.1:8090 > 35:17.629953 ...ICCBackend Attempting to bind to [::1]:8090 > 35:17.630930 ...ICCBackend Attempting to bind to 127.0.0.1:59402 > 35:17.631907 ...ICCBackend Attempting to bind to [::1]:59402 > 35:17.631907 ...Run Running backend > 35:22.632099 ...RefreshData Instantiating database connector > 35:22.636005 ...RefreshData Caught signal 11 (invalid memory access) > 35:22.683858 ...RefreshData 0xffffffff: ??? > 35:22.684835 ...RefreshData 0xffffffff: ??? > 35:22.684835 ...RefreshData 0x00000001: ??? > 35:22.685812 ...RefreshData 0x0000000c: ??? > 35:22.685812 ...RefreshData 0x00000001: ??? > 35:22.685812 ...RefreshData 0x00000003: ??? > 35:22.686788 ...RefreshData 0x00000004: ??? > 35:22.686788 ...RefreshData 0xffffffff: ??? > > The exception was caused by the following code: > > void ICCBackend::RefreshData() > { > LogScope(); > > filter2iccSettings.clear(); > id2skillList.clear(); > extension2skillList.clear(); > id2agentMonitor.clear(); > id2agentList.clear(); > kampanjaQueueSummary.clear(); > > iccSettings.clear(); > iccWallboard.clear(); > skillList.clear(); > skillMonitor.clear(); > agentMonitor.clear(); > agentList.clear(); > > Log(trace) << "Instantiating database connector"; > unique_ptr db(new odb::mssql::database("testbench", > "test12345", "", "testbench\\SQLEXPRESS2005")); > odb::transaction t(db->begin()); > > Log(trace) << "Refreshing iCCSettings data"; > for(const auto& i : db->query()) { > iccSettings.push_back(i); > filter2iccSettings[i.Filter_lcase] = &iccSettings.back(); > } > //... > } > > So the good news is that the problem is not with the code synthesized > by ODB (at least yet), but rather somewhere between libodb-mssql and > odbc32.dll > The bad news is that i don't have Windows locally and the remote > testbench doesn't have any debugger. Sadly libbacktrace compiled with > the cross-compiler didn't produce a correct output. I'll investigate > the problem tomorrow when i get to the Windows workstation. > > Best regards, > Sten Kultakangas > > > > > On Sun, Oct 9, 2016 at 7:45 PM, Boris Kolpackov > wrote: > > Hi Sten, > > > > So you are trying to use a cross-compiler as the underlying C++ compiler. > > I don't think anyone tried this but I don't see why it shouldn't work. > Once > > you make it work, a summary of steps involved would be much appreciated. > > > > Sten Kultakangas writes: > > > >> So the main cause is that GCC plugin API was changed in version 6.2.0 > >> and ODB is not compatible with it anymore? > > > > Yes, that's the standard story with each major GCC version. Can you try > > the latest pre-release which has GCC 6 compatibility fixes? > > > > http://codesynthesis.com/~boris/tmp/odb/pre-release/a9/ > > > > Boris > > From boris at codesynthesis.com Mon Oct 10 09:45:06 2016 From: boris at codesynthesis.com (Boris Kolpackov) Date: Mon Oct 10 09:45:17 2016 Subject: [odb-users] Querying on Containers In-Reply-To: References: Message-ID: Hi Lukas, Lukas Obermann writes: > But still can't figure out how to access the element in ClassC in > the query. You should be able to just join it to the view since it has an unambigous relationship (main->ptr_b->ptr_c). What exactly have you tried and what doesn't work? Boris From boris at codesynthesis.com Mon Oct 10 09:59:18 2016 From: boris at codesynthesis.com (Boris Kolpackov) Date: Mon Oct 10 09:59:29 2016 Subject: [odb-users] ODB + filesystem In-Reply-To: References: Message-ID: Hi Tiago, Tiago Macarios writes: > #include > > I guess it is because the ODB compiler is based on GCC 4.9.3 and the > filesystem libraries are only available after 5.3. What is the best thing > to do here? > > Is there a windows build of the compiler on a more updated version of GCC > (say 6.2)? No, not yet. Updating GCC for the Windows build of ODB is a bit of a procedure. Are you actually persisting any types from in the database? If not, then perhaps you could exclude it from the ODB compilation (ODB_COMPILER macro) or provide a dummy one? Boris From boris at codesynthesis.com Mon Oct 10 10:01:29 2016 From: boris at codesynthesis.com (Boris Kolpackov) Date: Mon Oct 10 10:01:39 2016 Subject: [odb-users] Re: using ODB with cross-compiler x86_64-linux-gnu -> i686-w64-mingw In-Reply-To: References: Message-ID: Hi Sten, Sten Kultakangas writes: > I have just made the ODB working with the underlying cross-compiler > x86_64-linux-gnu->i686-w64-mingw. I downloaded and built the latest > tools from your GIT [...] Great, thanks for the feedback. So looks like no patching of ODB is necessary to make this setup work. Boris From boris at codesynthesis.com Mon Oct 10 10:06:13 2016 From: boris at codesynthesis.com (Boris Kolpackov) Date: Mon Oct 10 10:06:23 2016 Subject: [odb-users] Re: using ODB with cross-compiler x86_64-linux-gnu -> i686-w64-mingw In-Reply-To: References: Message-ID: Hi Andrew, Andrew Cunningham writes: > I am confused as to why you are trying to do this when the ODB compiler > and libraries are available on Windows. Some of us prefer not to leave the comfort of our Linux/Emacs and use cross-compilers for Windows ;-). What Sten is trying to do is use the GCC cross-compiler as the underlying compiler for ODB. This can become important if you include some Windows- specific stuff (e.g., ) in headers that you compile with ODB; if you were to use a native (e.g., Linux-targeting) ODB build, then it won't be able to compile such headers. Boris From tiagomacarios at gmail.com Mon Oct 10 16:53:10 2016 From: tiagomacarios at gmail.com (Tiago Macarios) Date: Mon Oct 10 16:53:23 2016 Subject: [odb-users] ODB + filesystem In-Reply-To: References: Message-ID: Hi Boris, Andrew, Yup I ended up "faking" the header. Seems to be working. Let me know when you update the compiler so I can revert the changes I made =) Tiago On Mon, Oct 10, 2016 at 6:59 AM, Boris Kolpackov wrote: > Hi Tiago, > > Tiago Macarios writes: > > > #include > > > > I guess it is because the ODB compiler is based on GCC 4.9.3 and the > > filesystem libraries are only available after 5.3. What is the best thing > > to do here? > > > > Is there a windows build of the compiler on a more updated version of GCC > > (say 6.2)? > > No, not yet. Updating GCC for the Windows build of ODB is a bit of a > procedure. > > Are you actually persisting any types from in the database? > If not, then perhaps you could exclude it from the ODB compilation > (ODB_COMPILER macro) or provide a dummy one? > > Boris > > From haupt.wolfgang at gmail.com Thu Oct 13 14:05:52 2016 From: haupt.wolfgang at gmail.com (Wolfgang Haupt) Date: Thu Oct 13 14:06:16 2016 Subject: [odb-users] Linker error on Ubuntu 16.04.1 LTS Message-ID: Hi, i found some people posting issues about linker errors on Ubuntu with apt installed odb. Seems like I'm experiencing the same issues at the moment: My Linker line includes: -lodb -lodb-sqlite -lodb-mysql The libs are definitely there, but I get undefined references to: odb::statement::process_update(char const*, void const* const*, unsigned long, unsigned long, char, std::__cxx11::basic_string, std::allocator >&)' undefined reference to 'odb::query_base::operator+=(std::__cxx11::basic_string, std::allocator > const&)' etc. Someone else having the same issues? It works fine if I use the odb.tar.gz though. Thanks for any hints. Best Regards, Wolfgang From sean.clarke at sec-consulting.co.uk Thu Oct 13 14:38:11 2016 From: sean.clarke at sec-consulting.co.uk (Sean Clarke) Date: Thu Oct 13 14:38:26 2016 Subject: [odb-users] Linker error on Ubuntu 16.04.1 LTS In-Reply-To: References: Message-ID: Hi, I believe this is related to the libs not being compiled with the C++11 flags, hence the ABI errors. Regards Sean Clarke On 13 Oct 2016 7:08 pm, "Wolfgang Haupt" wrote: > Hi, > > i found some people posting issues about linker errors on Ubuntu with apt > installed odb. > Seems like I'm experiencing the same issues at the moment: > > My Linker line includes: -lodb -lodb-sqlite -lodb-mysql > The libs are definitely there, but I get undefined references to: > odb::statement::process_update(char const*, void const* const*, unsigned > long, unsigned long, char, std::__cxx11::basic_string std::char_traits, std::allocator >&)' > > undefined reference to > 'odb::query_base::operator+=(std::__cxx11::basic_string std::char_traits, std::allocator > const&)' > > etc. > > Someone else having the same issues? > It works fine if I use the odb.tar.gz though. > Thanks for any hints. > > > Best Regards, > Wolfgang > From haupt.wolfgang at gmail.com Thu Oct 13 14:40:09 2016 From: haupt.wolfgang at gmail.com (Wolfgang Haupt) Date: Thu Oct 13 14:40:33 2016 Subject: [odb-users] Linker error on Ubuntu 16.04.1 LTS In-Reply-To: References: Message-ID: You mean the libs shipped with Ubuntu are not compiled with the C++11 flags? Good point, thanks. Sean Clarke schrieb am Do., 13. Okt. 2016 um 20:38 Uhr: > Hi, > I believe this is related to the libs not being compiled with the > C++11 flags, hence the ABI errors. > > Regards > > > Sean Clarke > > On 13 Oct 2016 7:08 pm, "Wolfgang Haupt" wrote: > > Hi, > > i found some people posting issues about linker errors on Ubuntu with apt > installed odb. > Seems like I'm experiencing the same issues at the moment: > > My Linker line includes: -lodb -lodb-sqlite -lodb-mysql > The libs are definitely there, but I get undefined references to: > odb::statement::process_update(char const*, void const* const*, unsigned > long, unsigned long, char, std::__cxx11::basic_string std::char_traits, std::allocator >&)' > > undefined reference to > 'odb::query_base::operator+=(std::__cxx11::basic_string std::char_traits, std::allocator > const&)' > > etc. > > Someone else having the same issues? > It works fine if I use the odb.tar.gz though. > Thanks for any hints. > > > Best Regards, > Wolfgang > > From sean.clarke at sec-consulting.co.uk Thu Oct 13 14:42:08 2016 From: sean.clarke at sec-consulting.co.uk (Sean Clarke) Date: Thu Oct 13 14:42:22 2016 Subject: [odb-users] Linker error on Ubuntu 16.04.1 LTS In-Reply-To: References: Message-ID: or perhaps with the use old ABI flags enabled. I could compile myself from the same source and it would work fine. Regards Sean Clarke On 13 Oct 2016 7:40 pm, "Wolfgang Haupt" wrote: > You mean the libs shipped with Ubuntu are not compiled with the C++11 > flags? > Good point, thanks. > > Sean Clarke schrieb am Do., 13. Okt. > 2016 um 20:38 Uhr: > >> Hi, >> I believe this is related to the libs not being compiled with the >> C++11 flags, hence the ABI errors. >> >> Regards >> >> >> Sean Clarke >> >> On 13 Oct 2016 7:08 pm, "Wolfgang Haupt" >> wrote: >> >> Hi, >> >> i found some people posting issues about linker errors on Ubuntu with apt >> installed odb. >> Seems like I'm experiencing the same issues at the moment: >> >> My Linker line includes: -lodb -lodb-sqlite -lodb-mysql >> The libs are definitely there, but I get undefined references to: >> odb::statement::process_update(char const*, void const* const*, unsigned >> long, unsigned long, char, std::__cxx11::basic_string> std::char_traits, std::allocator >&)' >> >> undefined reference to >> 'odb::query_base::operator+=(std::__cxx11::basic_string> std::char_traits, std::allocator > const&)' >> >> etc. >> >> Someone else having the same issues? >> It works fine if I use the odb.tar.gz though. >> Thanks for any hints. >> >> >> Best Regards, >> Wolfgang >> >> From boris at codesynthesis.com Fri Oct 14 09:14:30 2016 From: boris at codesynthesis.com (Boris Kolpackov) Date: Fri Oct 14 09:14:40 2016 Subject: [odb-users] Linker error on Ubuntu 16.04.1 LTS In-Reply-To: References: Message-ID: Hi Wolfgang, Sean, Yes, Ubuntu 16.04 libraries appear to be broken, I've failed a bug report, but nobody seems to care: https://bugs.launchpad.net/ubuntu/+source/libodb/+bug/1588330 I believe the problem is caused by the GCC dual ABI fiasco that is described here: https://gcc.gnu.org/onlinedocs/libstdc++/manual/using_dual_abi.html My current guess is that some libodb* packages (I think libodb) were built with an older version of the compiler and are still using the old ABI. So it's a mess all around, unfortunately. Boris From obermann.lukas at gmail.com Tue Oct 18 05:54:41 2016 From: obermann.lukas at gmail.com (Lukas Obermann) Date: Tue Oct 18 05:55:04 2016 Subject: [odb-users] Querying on Containers In-Reply-To: References: Message-ID: Hi Boris, sorry f?r the delay. So, I have this view: #pragma db view \ object(main) \ object(ClassA = a: main::ptr_a) \ object(ClassA = list_a: main::list_a) \ object(ClassB = b: main::ptr_b) ... So, accessing and querying 'a' and 'list_a' works perfectly. but when now trying query: query::b::ptr_c->iNeedToBeQueried == "SomeValues" it simply does not know the 'iNeedToBeQueried' value. Also tried: query::b::ptr_c::iNeedToBeQueried == "SomeValues" with the same result. I assume that I somehow have to make ClassC visible within the view? Thanks, Lukas Boris Kolpackov schrieb am Mo., 10. Okt. 2016 um 15:45 Uhr: > Hi Lukas, > > Lukas Obermann writes: > > > But still can't figure out how to access the element in ClassC in > > the query. > > You should be able to just join it to the view since it has an > unambigous relationship (main->ptr_b->ptr_c). What exactly have > you tried and what doesn't work? > > Boris > From albert.gu at ringcentral.com Tue Oct 18 04:05:02 2016 From: albert.gu at ringcentral.com (Albert Gu) Date: Tue Oct 18 11:26:40 2016 Subject: [odb-users] Can I pass a customized filter function to ODB? Message-ID: Hi Boris, I would like to implement a calendar using ODB. This calendar should support recurrence events as the mobile phone does. (Eg. iPhone native Calendar) Not sure if ODB supports customized filter function which can be used in SQL's "WHERE" clause. If ODB doesn't support this, do you have any idea about this requirement? Any help would be appreciated! Best wishes, Albert From boris at codesynthesis.com Tue Oct 18 11:44:48 2016 From: boris at codesynthesis.com (Boris Kolpackov) Date: Tue Oct 18 11:44:57 2016 Subject: [odb-users] Querying on Containers In-Reply-To: References: Message-ID: Hi Lukas, Lukas Obermann writes: > #pragma db view \ > object(main) \ > object(ClassA = a: main::ptr_a) \ > object(ClassA = list_a: main::list_a) \ > object(ClassB = b: main::ptr_b) > ... Have you tried adding: object(ClassC ...) Just like you did for the others? Boris From michael at unetresgrossebite.com Tue Oct 18 11:44:49 2016 From: michael at unetresgrossebite.com (=?ISO-8859-1?Q?Micha=EBl_Mart=EDn?= Moro) Date: Tue Oct 18 11:50:54 2016 Subject: [odb-users] Can I pass a customized filter function to ODB? In-Reply-To: References: Message-ID: <2642322.dEL5QPWgVH@archnemesis> Hi Albert, I might be able to speed this up a little ! I'm not entirely sure what you mean by recurrence event, but anything you can do with a WHERE clause in SQL, you should be able to do with ODB. ODB queries can also be concatenated with good old strings. For instance, in order to use postgres' array operators, I do something that basically sums up to this: query::my_field + "@>" + "'{1,2,3}'::int[]" Now, if you're also wondering about how to use custom columns, this part of the documentation should be what you're looking for: http://www.codesynthesis.com/products/odb/doc/manual.xhtml#2.7 Hope that helps, and good luck with your work ! On martes, 18 de octubre de 2016 8:05:02 (CEST) you wrote: > Hi Boris, > > > I would like to implement a calendar using ODB. This calendar should support > recurrence events as the mobile phone does. (Eg. iPhone native Calendar) > > > Not sure if ODB supports customized filter function which can be used in > SQL's "WHERE" clause. > > > If ODB doesn't support this, do you have any idea about this requirement? > > > Any help would be appreciated! > > > Best wishes, > > Albert From anaswara.nn at gmail.com Wed Oct 19 02:52:05 2016 From: anaswara.nn at gmail.com (Anaswara Nair) Date: Wed Oct 19 02:52:17 2016 Subject: [odb-users] Unknown database schema in Visual Studio project In-Reply-To: References: Message-ID: I tried the fix as said in http://www.codesynthesis.com/ pipermail/odb-users/2013-May/001289.html. But the error still exists. On Fri, Oct 7, 2016 at 8:00 PM, Boris Kolpackov wrote: > Hi Anaswara, > > Anaswara Nair writes: > > > In my Visual Studio solution, I have two different projects of which one > is > > built as a static library and the other one as the executable. > > This post explains the potential problem with static libraries: > > http://www.codesynthesis.com/pipermail/odb-users/2013-May/001286.html > > While this post explains how to fix it in VC: > > http://www.codesynthesis.com/pipermail/odb-users/2013-May/001289.html > > Boris > -- WITH REGARDS, ANASWARA From albert.gu at ringcentral.com Wed Oct 19 04:27:22 2016 From: albert.gu at ringcentral.com (Albert Gu) Date: Wed Oct 19 04:31:30 2016 Subject: [odb-users] Re: Can I pass a customized filter function to ODB? In-Reply-To: References: Message-ID: Hi Boris, As you can see, I was asking the way to support customized Functions used in accessing SQLite. Telling you the requirement is wanna you know more about the usage context instead of provide exact solution. By the way, you DO have the right to say NO directly. Thanks for contacting us! - Regards, Albert From: Albert Gu > Date: Tuesday, 18 October 2016 at 4:05 PM To: "odb-users@codesynthesis.com" > Subject: Can I pass a customized filter function to ODB? Hi Boris, I would like to implement a calendar using ODB. This calendar should support recurrence events as the mobile phone does. (Eg. iPhone native Calendar) Not sure if ODB supports customized filter function which can be used in SQL's "WHERE" clause. If ODB doesn't support this, do you have any idea about this requirement? Any help would be appreciated! Best wishes, Albert From obermann.lukas at gmail.com Wed Oct 19 11:10:15 2016 From: obermann.lukas at gmail.com (Lukas Obermann) Date: Wed Oct 19 11:10:41 2016 Subject: [odb-users] Querying on Containers In-Reply-To: References: Message-ID: Hi Boris, ok, I tried a few things around today and seems that the issue was on my side somewhere, as this was not working before, but I assume I screwed up somewhere else. So, I can access it now via: #pragma db view \ object(main) \ object(ClassA = a: main::ptr_a) \ object(ClassA = list_a: main::list_a) \ object(ClassB = b: main::ptr_b) \ object(ClassC = c: b::ptr_c) ... Looks good now. Will continue testing. Thanks for the help! All the best, Lukas Boris Kolpackov schrieb am Di., 18. Okt. 2016 um 17:44 Uhr: Hi Lukas, Lukas Obermann writes: > #pragma db view \ > object(main) \ > object(ClassA = a: main::ptr_a) \ > object(ClassA = list_a: main::list_a) \ > object(ClassB = b: main::ptr_b) > ... Have you tried adding: object(ClassC ...) Just like you did for the others? Boris From ratkaisut at gmail.com Sun Oct 23 16:19:12 2016 From: ratkaisut at gmail.com (Sten Kultakangas) Date: Sun Oct 23 16:19:25 2016 Subject: [odb-users] Re: using ODB with cross-compiler x86_64-linux-gnu -> i686-w64-mingw In-Reply-To: References: Message-ID: Hello I have just realized the cause of SIGSEGV when the following lines of codes are executed: unique_ptr db(new odb::mssql::database("user", "password", "", "testbench\\SQLEXPRESS2005")); odb::transaction t(db->begin()); //<-------- SIGSEGV generated here This is because exceptions normally occur in odbc32.dll, however, the default exception ABI used in the cross-compiled binaries was for some reason dwarf-2. not sjlj. Here's the information concerning DW2: "GCC currently supports two methods of stack frame unwinding: Dwarf-2 (DW2) or SJLJ (setjmp/longjmp). Until recently, only SJLJ has been available for the Windows platform. This affects you, the end user, primarily in programs that throw and catch exceptions. Programs which utilize the DW2 unwind method generally execute more quickly than programs which utilize the SJLJ method, because the DW2 method incurs no runtime overhead until an exception is thrown. However, the DW2 method does incur a size penalty on code that must handle exceptions, and more importantly the DW2 method cannot yet unwind (pass exceptions) through "foreign" stack frames: stack frames compiled by another non-DW2-enabled compiler, such as OS DLLs in a Windows callback." As you can realize, the vectored exception handler is unable to pass the exception to the structured exception handler located in odbc32.dll hence the totally innocent code was believed to have caused memory access violation. Do not use DW2 in mingw32 targets, cross-compiled or not! Best regards, Sten Kultakangas On Mon, Oct 10, 2016 at 5:06 PM, Boris Kolpackov wrote: > Hi Andrew, > > Andrew Cunningham writes: > >> I am confused as to why you are trying to do this when the ODB compiler >> and libraries are available on Windows. > > Some of us prefer not to leave the comfort of our Linux/Emacs and use > cross-compilers for Windows ;-). > > What Sten is trying to do is use the GCC cross-compiler as the underlying > compiler for ODB. This can become important if you include some Windows- > specific stuff (e.g., ) in headers that you compile with ODB; > if you were to use a native (e.g., Linux-targeting) ODB build, then it > won't be able to compile such headers. > > Boris From boris at codesynthesis.com Mon Oct 24 03:27:24 2016 From: boris at codesynthesis.com (Boris Kolpackov) Date: Mon Oct 24 03:27:34 2016 Subject: [odb-users] Re: using ODB with cross-compiler x86_64-linux-gnu -> i686-w64-mingw In-Reply-To: References: Message-ID: Hi Sten, Sten Kultakangas writes: > Do not use DW2 in mingw32 targets, cross-compiled or not! Thanks for sharing, always appreciated. It looks like these days sjlj is more or less standard for i686-w64-mingw32. But for x86_64-w64-mingw32 it is seh. Wonder if 64-bit/seh will still work in your situation. Boris From ratkaisut at gmail.com Mon Oct 24 14:40:11 2016 From: ratkaisut at gmail.com (Sten Kultakangas) Date: Mon Oct 24 14:40:23 2016 Subject: [odb-users] SQL functions as values for certain columns on INSERT or UPDATE Message-ID: Hello I want to set a column's value to a value returned by DATEADD(ss,-something,GETDATE()) on INSERT. Can this be achieved using standard ways without using execute() etc ? A similar functionality for SELECT can be achieved using views. For example: /* SELECT [KampanjaID] ,[Tila], MIN([CreateDateTime]), count(*) FROM [OutboundManager].[dbo].[KampanjaDetails] where Tila IN('S','1','2') GROUP BY KampanjaID,Tila */ PRAGMA_DB(view object(KampanjaDetails) query("Tila IN('S','1','2') GROUP BY KampanjaID,Tila")) struct KampanjaDetails_QueueSummaryView { PRAGMA_DB(column(KampanjaDetails::KampanjaID)) int KampanjaID; PRAGMA_DB(column(KampanjaDetails::Tila)) string Tila; PRAGMA_DB(column("MIN(" + KampanjaDetails::CreateDateTime + ")")) ptime oldest; PRAGMA_DB(column("COUNT(*)")) int total; }; As far as i understand, views cannot be abused for INSERT/UPDATE operations. I tried the following: PRAGMA_DB(object schema("ICCAnalyzer.dbo")) struct CallDetailRecord { PRAGMA_DB(id auto type("bigint")) //... PRAGMA_DB(type("datetime") options("DEFAULT GETDATE()")) ptime CollectedDateTime; }; however, the newly inserted rows are NULL. I know i can workaround this by altering the table definition: ALTER TABLE [ICCAnalyzer].[dbo].[CallDetailRecord] ADD CONSTRAINT [DF_CallDetailRecord_CollectedDateTime] DEFAULT (getdate()) FOR [CollectedDateTime] and then simply exclude CollectedDateTime from the object's definition in the header file. Is it possible to use similar functionality which is available for views? For example something like this: PRAGMA_DB(column_value("GETDATE()")) ptime CollectedDateTime; PRAGMA_DB(column_value("DATEADD(ss,-" + CallDetailRecord::DurationSeconds + ",GETDATE())")) ptime CallStartedDateTime; Best regards, Sten Kultakangas From boris at codesynthesis.com Tue Oct 25 00:53:18 2016 From: boris at codesynthesis.com (Boris Kolpackov) Date: Tue Oct 25 00:53:29 2016 Subject: [odb-users] SQL functions as values for certain columns on INSERT or UPDATE In-Reply-To: References: Message-ID: Hi Sten, Sten Kultakangas writes: > I want to set a column's value to a value returned by > DATEADD(ss,-something,GETDATE()) on INSERT. Can this be achieved using > standard ways without using execute() etc ? No, you cannot "pass" database function calls to insert()/update() operations. Your options are: 1. Use a view to call the function, fetch the result, and pass it as a normal value. 2. Use the function call as the column's default value (see pragma db default). Then insert/update NULL to trigger the use of the default value. 3. Similar to 3 but using INSERT/UPDATE triggers. For example, you could reserve some "special" values which the trigger detects. Boris From obermann.lukas at gmail.com Tue Oct 25 04:59:19 2016 From: obermann.lukas at gmail.com (Lukas Obermann) Date: Tue Oct 25 04:59:42 2016 Subject: [odb-users] Query on non-empty container in view Message-ID: Hi All, a question which I can not find any solution in the docs or via google. So, having a class that has some containers (std::vector) in a class and a view on top of that to access the elements. What is the recommended way of querying that the vector must have at least one element in it? The view is not providing access to the vector itself (as stated in the docs) but getting the objects out via a object loading view seems also to not offer the correct functions. Thanks again for the help, Lukas From boris at codesynthesis.com Tue Oct 25 11:27:37 2016 From: boris at codesynthesis.com (Boris Kolpackov) Date: Tue Oct 25 11:27:47 2016 Subject: [odb-users] Query on non-empty container in view In-Reply-To: References: Message-ID: Hi Lukas, Lukas Obermann writes: > So, having a class that has some containers > (std::vector) in a class and a view on top of that to > access the elements. > > What is the recommended way of querying that the vector must have at least > one element in it? If pointers in your vector cannot be NULL (which would generally be pointless in this case, no pun intended), then you can just join the pointed-to object and add a test like "its object id is not NULL" (or use an appropriate join type). Boris From vyelnikov at adfsolutions.com Wed Oct 26 04:53:30 2016 From: vyelnikov at adfsolutions.com (Vladimir Yelnikov) Date: Wed Oct 26 04:53:42 2016 Subject: [odb-users] database generated ID combined with manual ID in SQLite Message-ID: We have code looks like this: struct SomeClass { #pragma id auto int id_; } I need to combine autogenerated IDs with manual IDs when persisting objects, sometimes developer needs to set IDs manually and in some cases, he doesn't care. The first solution I tried is using nullable IDs and rely on SQLite behavior when id is NULL - id will be generated. But it requires a lot of changes in code struct SomeClass { #pragma id auto odb::nullable id_; } Also I tried to use --sqlite-lax-auto-id ODB compiler parameter, ODB doesn't throw exception about monotonically inc id but it ignores custom IDs. Is it possible to get need behavior using ODB pragmas? void access::object_traits_impl< SomeClass, id_sqlite >:: persist (database& db, object_type& obj) { ... if (init (im, obj, statement_insert)) //producess proper id and image_type im.version++; ... im.id_null = true; // will be nice to get something like im.id_null = im.id == 0; ... } Best Wishes, Vladimir From boris at codesynthesis.com Wed Oct 26 10:44:55 2016 From: boris at codesynthesis.com (Boris Kolpackov) Date: Wed Oct 26 10:45:06 2016 Subject: [odb-users] database generated ID combined with manual ID in SQLite In-Reply-To: References: Message-ID: Hi Vladimir, Vladimir Yelnikov writes: > The first solution I tried is using nullable IDs and rely on SQLite > behavior when id is NULL - id will be generated. > > struct SomeClass > { > #pragma id auto > odb::nullable id_; > } Ok, I've implemented support for this (but only for SQLite). Now if you set id_ to NULL you will get an auto-assigned value. Otherwise, the value you specified will be used. I can package you a pre-release if you would like to give it a try. Boris From jmmut at ebi.ac.uk Fri Oct 28 04:42:42 2016 From: jmmut at ebi.ac.uk (jose miguel mut) Date: Fri Oct 28 07:04:56 2016 Subject: [odb-users] persisting objects increases long-term memory usage (with sqlite) Message-ID: <71b8e585-7d0a-32e0-8ad8-7cf3b78fccd5@ebi.ac.uk> Hello, We are using ODB 2.4.0 with sqlite (with great delight) but have noticed that the memory used increases with time. Is this expected? Or maybe we are not using the ODB API properly? For long executions (up to 10^10 instances), a constant memory usage would be ideal. The increase seems linear and is noticeable even in short executions. To clear any doubt, I am not talking about memory leaks, those are well handled as valgrind shows (those 72,704 bytes seem to be about an unrelated issue with c++ stdlib): ==892== LEAK SUMMARY: ==892== definitely lost: 0 bytes in 0 blocks ==892== indirectly lost: 0 bytes in 0 blocks ==892== possibly lost: 0 bytes in 0 blocks ==892== still reachable: 72,704 bytes in 1 blocks ==892== suppressed: 0 bytes in 0 blocks I am talking about memory usage, I attached the most important part of the output of a `valgrind --tool=massif` analysis. You can see there how the 80% percent of the final usage is allocated by `sqlite_step`, called by `odb::sqlite::insert_statement::execute() (statement.cxx:649)`. In this execution, no reading was done, only writing. I think that ODB might be caching some statements, so I would like to know if it's possible to not cache anything. The manual says that sessions may cache some things, but we are not using sessions. We are using transactions, and flushing every 1000 elements (Error is the class we are persisting): ``` void OdbReportRW::write(Error &error) { if (current_transaction_size == 0) { // start transaction transaction.reset(db->begin()); } db->persist(error); ++current_transaction_size; if (current_transaction_size == transaction_size) { // commit transaction flush(); current_transaction_size = 0; } } void OdbReportRW::flush() { if (transaction.has_current()) { transaction.commit(); } } ``` So, wrapping up, is it possible to have a constant memory usage when persisting objects? Regards, Jose -------------- next part -------------- -------------------------------------------------------------------------------- Command: ./builds/debug/bin/vcf_validator -v v4.1 -i ../../Documents/biofiles/European_Holstein.NewZealand_population.10000.vcf -r stdout,database -o /tmp Massif arguments: --time-unit=B ms_print arguments: massif.out.623 -------------------------------------------------------------------------------- MB 2.319^ # | ::@@# | @@@@@: @@# | ::@@@ @@@: @@# | @@@::: @ @ @@@: @@# | ::::@ @: : @ @ @@@: @@# | @@:@@:: :@ @: : @ @ @@@: @@# | @@@@@@ :@ :: :@ @: : @ @ @@@: @@# | ::@@@@@@ @ :@ :: :@ @: : @ @ @@@: @@# | @@@: @@@@@@ @ :@ :: :@ @: : @ @ @@@: @@# | ::@@@:@ @: @@@@@@ @ :@ :: :@ @: : @ @ @@@: @@# | :@@@: @ @:@ @: @@@@@@ @ :@ :: :@ @: : @ @ @@@: @@# | ::::::@@ : @ @:@ @: @@@@@@ @ :@ :: :@ @: : @ @ @@@: @@# | :::::@@::: ::@@ : @ @:@ @: @@@@@@ @ :@ :: :@ @: : @ @ @@@: @@# | @::: :@ ::: ::@@ : @ @:@ @: @@@@@@ @ :@ :: :@ @: : @ @ @@@: @@# | @::@::: :@ ::: ::@@ : @ @:@ @: @@@@@@ @ :@ :: :@ @: : @ @ @@@: @@# | :@@@: @::: :@ ::: ::@@ : @ @:@ @: @@@@@@ @ :@ :: :@ @: : @ @ @@@: @@# | @:@ @: @::: :@ ::: ::@@ : @ @:@ @: @@@@@@ @ :@ :: :@ @: : @ @ @@@: @@# | @:@ @: @::: :@ ::: ::@@ : @ @:@ @: @@@@@@ @ :@ :: :@ @: : @ @ @@@: @@# | @:@ @: @::: :@ ::: ::@@ : @ @:@ @: @@@@@@ @ :@ :: :@ @: : @ @ @@@: @@# 0 +----------------------------------------------------------------------->GB 0 9.917 Number of snapshots: 53 Detailed snapshots: [1, 3, 4, 6, 11, 17, 18, 20, 21, 23, 24, 26, 27, 28, 29, 30, 31, 32, 34, 38, 39, 42, 43, 44, 45, 46, 48, 50, 52 (peak)] -------------------------------------------------------------------------------- n time(b) total(b) useful-heap(b) extra-heap(b) stacks(b) -------------------------------------------------------------------------------- 51 10,613,896,096 2,419,152 2,320,601 98,551 0 52 10,648,454,520 2,431,464 2,332,669 98,795 0 95.94% (2,332,669b) (heap allocation functions) malloc/new/new[], --alloc-fns, etc. ->80.96% (1,968,584b) 0x71d1dc5: ??? (in /usr/lib/x86_64-linux-gnu/libsqlite3.so.0.8.6) | ->80.96% (1,968,584b) 0x71ac568: ??? (in /usr/lib/x86_64-linux-gnu/libsqlite3.so.0.8.6) | ->80.96% (1,968,584b) 0x71b4c46: ??? (in /usr/lib/x86_64-linux-gnu/libsqlite3.so.0.8.6) | | ->76.21% (1,852,944b) 0x71b8899: ??? (in /usr/lib/x86_64-linux-gnu/libsqlite3.so.0.8.6) | | | ->76.12% (1,850,880b) 0x71b8af0: ??? (in /usr/lib/x86_64-linux-gnu/libsqlite3.so.0.8.6) | | | | ->76.12% (1,850,880b) 0x71b2367: ??? (in /usr/lib/x86_64-linux-gnu/libsqlite3.so.0.8.6) | | | | ->76.12% (1,850,880b) 0x71de5d4: ??? (in /usr/lib/x86_64-linux-gnu/libsqlite3.so.0.8.6) | | | | ->76.12% (1,850,880b) 0x71de88b: ??? (in /usr/lib/x86_64-linux-gnu/libsqlite3.so.0.8.6) | | | | ->76.07% (1,849,600b) 0x71e18ea: ??? (in /usr/lib/x86_64-linux-gnu/libsqlite3.so.0.8.6) | | | | | ->73.96% (1,798,400b) 0x71e55d1: ??? (in /usr/lib/x86_64-linux-gnu/libsqlite3.so.0.8.6) | | | | | | ->73.96% (1,798,400b) 0x71e66f7: ??? (in /usr/lib/x86_64-linux-gnu/libsqlite3.so.0.8.6) | | | | | | ->73.96% (1,798,400b) 0x720f460: ??? (in /usr/lib/x86_64-linux-gnu/libsqlite3.so.0.8.6) | | | | | | ->73.96% (1,798,400b) 0x7212f85: sqlite3_step (in /usr/lib/x86_64-linux-gnu/libsqlite3.so.0.8.6) | | | | | | ->73.96% (1,798,400b) 0x59f8a88: odb::sqlite::insert_statement::execute() (statement.cxx:649) | | | | | | ->65.54% (1,593,600b) 0x6fe3db: odb::access::object_traits_impl::persist(odb::database&, ebi::vcf::error&, bool, bool) (error-odb.cpp:538) | | | | | | | ->43.69% (1,062,400b) 0x705c1f: odb::access::object_traits_impl::persist(odb::database&, ebi::vcf::nometadefinitionerror&, bool, bool) (error-odb.cpp:3558) | | | | | | | | ->43.69% (1,062,400b) 0x73542a: odb::dispatch_persist::call(odb::database&, ebi::vcf::nometadefinitionerror const&) (polymorphic-map.hxx:146) | | | | | | | | ->43.69% (1,062,400b) 0x726c7c: bool odb::dispatch_impl(odb::polymorphic_concrete_info::root_type>::call_type, odb::database&, odb::object_traits::root_type const*, void const*) (polymorphic-map.hxx:180) | | | | | | | | ->43.69% (1,062,400b) 0x6fe1f6: odb::access::object_traits_impl::persist(odb::database&, ebi::vcf::error&, bool, bool) (error-odb.cpp:495) | | | | | | | | ->43.69% (1,062,400b) 0x5358a2: odb::object_traits::id_type odb::database::persist_(ebi::vcf::error&) (database.txx:38) | | | | | | | | ->43.69% (1,062,400b) 0x534d03: odb::object_traits::id_type odb::database::persist(ebi::vcf::error&) (database.ixx:160) | | | | | | | | ->43.69% (1,062,400b) 0x5335ce: ebi::vcf::odbreportrw::write(ebi::vcf::error&) (odb_report.cpp:98) | | | | | | | | ->43.69% (1,062,400b) 0x533556: ebi::vcf::odbreportrw::write_warning(ebi::vcf::error&) (odb_report.cpp:88) | | | | | | | | ->43.69% (1,062,400b) 0x5380e4: ebi::vcf::is_valid_vcf_file(std::istream&, ebi::vcf::parser&, std::vector >, std::allocator > > >&) (validator.cpp:142) | | | | | | | | ->43.69% (1,062,400b) 0x5203d9: main (main.cpp:242) | | | | | | | | | | | | | | | ->21.85% (531,200b) 0x703e0d: odb::access::object_traits_impl::persist(odb::database&, ebi::vcf::bodysectionerror&, bool, bool) (error-odb.cpp:2764) | | | | | | | ->21.85% (531,200b) 0x71a3fb: odb::access::object_traits_impl::persist(odb::database&, ebi::vcf::samplesfieldbodyerror&, bool, bool) (error-odb.cpp:11883) | | | | | | | ->21.85% (531,200b) 0x73a330: odb::dispatch_persist::call(odb::database&, ebi::vcf::samplesfieldbodyerror const&) (polymorphic-map.hxx:146) | | | | | | | ->21.85% (531,200b) 0x730886: bool odb::dispatch_impl(odb::polymorphic_concrete_info::root_type>::call_type, odb::database&, odb::object_traits::root_type const*, void const*) (polymorphic-map.hxx:180) | | | | | | | ->21.85% (531,200b) 0x6fe1f6: odb::access::object_traits_impl::persist(odb::database&, ebi::vcf::error&, bool, bool) (error-odb.cpp:495) | | | | | | | ->21.85% (531,200b) 0x5358a2: odb::object_traits::id_type odb::database::persist_(ebi::vcf::error&) (database.txx:38) | | | | | | | ->21.85% (531,200b) 0x534d03: odb::object_traits::id_type odb::database::persist(ebi::vcf::error&) (database.ixx:160) | | | | | | | ->21.85% (531,200b) 0x5335ce: ebi::vcf::odbreportrw::write(ebi::vcf::error&) (odb_report.cpp:98) | | | | | | | ->21.85% (531,200b) 0x533526: ebi::vcf::odbreportrw::write_error(ebi::vcf::error&) (odb_report.cpp:83) | | | | | | | ->21.85% (531,200b) 0x537fbb: ebi::vcf::is_valid_vcf_file(std::istream&, ebi::vcf::parser&, std::vector >, std::allocator > > >&) (validator.cpp:137) | | | | | | | ->21.85% (531,200b) 0x5203d9: main (main.cpp:242) | | | | | | | | | | | | | ->05.26% (128,000b) 0x705d54: odb::access::object_traits_impl::persist(odb::database&, ebi::vcf::nometadefinitionerror&, bool, bool) (error-odb.cpp:3578) | | | | | | | ->05.26% (128,000b) 0x73542a: odb::dispatch_persist::call(odb::database&, ebi::vcf::nometadefinitionerror const&) (polymorphic-map.hxx:146) | | | | | | | ->05.26% (128,000b) 0x726c7c: bool odb::dispatch_impl(odb::polymorphic_concrete_info::root_type>::call_type, odb::database&, odb::object_traits::root_type const*, void const*) (polymorphic-map.hxx:180) | | | | | | | ->05.26% (128,000b) 0x6fe1f6: odb::access::object_traits_impl::persist(odb::database&, ebi::vcf::error&, bool, bool) (error-odb.cpp:495) | | | | | | | ->05.26% (128,000b) 0x5358a2: odb::object_traits::id_type odb::database::persist_(ebi::vcf::error&) (database.txx:38) | | | | | | | ->05.26% (128,000b) 0x534d03: odb::object_traits::id_type odb::database::persist(ebi::vcf::error&) (database.ixx:160) | | | | | | | ->05.26% (128,000b) 0x5335ce: ebi::vcf::odbreportrw::write(ebi::vcf::error&) (odb_report.cpp:98) | | | | | | | ->05.26% (128,000b) 0x533556: ebi::vcf::odbreportrw::write_warning(ebi::vcf::error&) (odb_report.cpp:88) | | | | | | | ->05.26% (128,000b) 0x5380e4: ebi::vcf::is_valid_vcf_file(std::istream&, ebi::vcf::parser&, std::vector >, std::allocator > > >&) (validator.cpp:142) | | | | | | | ->05.26% (128,000b) 0x5203d9: main (main.cpp:242) | | | | | | | | | | | | | ->02.00% (48,640b) 0x71a530: odb::access::object_traits_impl::persist(odb::database&, ebi::vcf::samplesfieldbodyerror&, bool, bool) (error-odb.cpp:11903) | | | | | | | ->02.00% (48,640b) 0x73a330: odb::dispatch_persist::call(odb::database&, ebi::vcf::samplesfieldbodyerror const&) (polymorphic-map.hxx:146) | | | | | | | ->02.00% (48,640b) 0x730886: bool odb::dispatch_impl(odb::polymorphic_concrete_info::root_type>::call_type, odb::database&, odb::object_traits::root_type const*, void const*) (polymorphic-map.hxx:180) | | | | | | | ->02.00% (48,640b) 0x6fe1f6: odb::access::object_traits_impl::persist(odb::database&, ebi::vcf::error&, bool, bool) (error-odb.cpp:495) | | | | | | | ->02.00% (48,640b) 0x5358a2: odb::object_traits::id_type odb::database::persist_(ebi::vcf::error&) (database.txx:38) | | | | | | | ->02.00% (48,640b) 0x534d03: odb::object_traits::id_type odb::database::persist(ebi::vcf::error&) (database.ixx:160) | | | | | | | ->02.00% (48,640b) 0x5335ce: ebi::vcf::odbreportrw::write(ebi::vcf::error&) (odb_report.cpp:98) | | | | | | | ->02.00% (48,640b) 0x533526: ebi::vcf::odbreportrw::write_error(ebi::vcf::error&) (odb_report.cpp:83) | | | | | | | ->02.00% (48,640b) 0x537fbb: ebi::vcf::is_valid_vcf_file(std::istream&, ebi::vcf::parser&, std::vector >, std::allocator > > >&) (validator.cpp:137) | | | | | | | ->02.00% (48,640b) 0x5203d9: main (main.cpp:242) | | | | | | | | | | | | | ->01.16% (28,160b) 0x703f42: odb::access::object_traits_impl::persist(odb::database&, ebi::vcf::bodysectionerror&, bool, bool) (error-odb.cpp:2784) | | | | | | ->01.16% (28,160b) 0x71a3fb: odb::access::object_traits_impl::persist(odb::database&, ebi::vcf::samplesfieldbodyerror&, bool, bool) (error-odb.cpp:11883) | | | | | | ->01.16% (28,160b) 0x73a330: odb::dispatch_persist::call(odb::database&, ebi::vcf::samplesfieldbodyerror const&) (polymorphic-map.hxx:146) | | | | | | ->01.16% (28,160b) 0x730886: bool odb::dispatch_impl(odb::polymorphic_concrete_info::root_type>::call_type, odb::database&, odb::object_traits::root_type const*, void const*) (polymorphic-map.hxx:180) | | | | | | ->01.16% (28,160b) 0x6fe1f6: odb::access::object_traits_impl::persist(odb::database&, ebi::vcf::error&, bool, bool) (error-odb.cpp:495) | | | | | | ->01.16% (28,160b) 0x5358a2: odb::object_traits::id_type odb::database::persist_(ebi::vcf::error&) (database.txx:38) | | | | | | ->01.16% (28,160b) 0x534d03: odb::object_traits::id_type odb::database::persist(ebi::vcf::error&) (database.ixx:160) | | | | | | ->01.16% (28,160b) 0x5335ce: ebi::vcf::odbreportrw::write(ebi::vcf::error&) (odb_report.cpp:98) | | | | | | ->01.16% (28,160b) 0x533526: ebi::vcf::odbreportrw::write_error(ebi::vcf::error&) (odb_report.cpp:83) | | | | | | ->01.16% (28,160b) 0x537fbb: ebi::vcf::is_valid_vcf_file(std::istream&, ebi::vcf::parser&, std::vector >, std::allocator > > >&) (validator.cpp:137) | | | | | | ->01.16% (28,160b) 0x5203d9: main (main.cpp:242) | | | | | | | | | | | ->01.05% (25,600b) 0x71e6d50: ??? (in /usr/lib/x86_64-linux-gnu/libsqlite3.so.0.8.6) | | | | | | ->01.05% (25,600b) 0x720d668: ??? (in /usr/lib/x86_64-linux-gnu/libsqlite3.so.0.8.6) | | | | | | ->01.05% (25,600b) 0x7212f85: sqlite3_step (in /usr/lib/x86_64-linux-gnu/libsqlite3.so.0.8.6) | | | | | | ->01.05% (25,600b) 0x59f82a0: odb::sqlite::generic_statement::execute() (statement.cxx:390) | | | | | | ->01.05% (25,600b) 0x59ec832: odb::sqlite::connection::execute(char const*, unsigned long) (connection.cxx:146) | | | | | | ->01.05% (25,600b) 0x72291c: odb::database::execute(char const*) (database.ixx:869) | | | | | | ->01.05% (25,600b) in 19 places, all below massif's threshold (01.00%) | | | | | | | | | | | ->01.05% (25,600b) in 2 places, all below massif's threshold (01.00%) | | | | | | | | | ->00.05% (1,280b) in 1+ places, all below ms_print's threshold (01.00%) | | | | | | | ->00.08% (2,064b) in 1+ places, all below ms_print's threshold (01.00%) | | | | | ->02.63% (64,008b) 0x71be910: ??? (in /usr/lib/x86_64-linux-gnu/libsqlite3.so.0.8.6) | | | ->02.63% (64,008b) 0x7232617: ??? (in /usr/lib/x86_64-linux-gnu/libsqlite3.so.0.8.6) | | | ->02.63% (64,008b) 0x59ed1ae: odb::sqlite::connection::connection(odb::sqlite::database&, int) (connection.cxx:62) | | | ->02.63% (64,008b) 0x59ee437: odb::sqlite::connection_pool_factory::pooled_connection::pooled_connection(odb::sqlite::database&, int) (connection-factory.cxx:245) | | | ->02.63% (64,008b) 0x59ee4a7: odb::sqlite::connection_pool_factory::create() (connection-factory.cxx:137) | | | ->02.63% (64,008b) 0x59ee0ca: odb::sqlite::connection_pool_factory::connect() (connection-factory.cxx:177) | | | ->02.63% (64,008b) 0x59ef1c1: odb::sqlite::database::connection_() (database.cxx:182) | | | ->02.63% (64,008b) 0x534243: odb::database::connection() (database.ixx:127) | | | ->02.63% (64,008b) 0x532f99: ebi::vcf::odbreportrw::odbreportrw(std::string const&) (odb_report.cpp:44) | | | ->02.63% (64,008b) 0x51fb97: (anonymous namespace)::get_outputs(std::string const&, std::string const&) (main.cpp:198) | | | ->02.63% (64,008b) 0x520280: main (main.cpp:231) | | | | | ->01.22% (29,640b) 0x71b4d64: ??? (in /usr/lib/x86_64-linux-gnu/libsqlite3.so.0.8.6) | | | ->01.22% (29,640b) in 17 places, all below massif's threshold (01.00%) | | | | | ->00.90% (21,992b) in 1+ places, all below ms_print's threshold (01.00%) | | | ->00.00% (0b) in 1+ places, all below ms_print's threshold (01.00%) From boris at codesynthesis.com Mon Oct 31 06:25:06 2016 From: boris at codesynthesis.com (Boris Kolpackov) Date: Mon Oct 31 06:25:16 2016 Subject: [odb-users] persisting objects increases long-term memory usage (with sqlite) In-Reply-To: <71b8e585-7d0a-32e0-8ad8-7cf3b78fccd5@ebi.ac.uk> References: <71b8e585-7d0a-32e0-8ad8-7cf3b78fccd5@ebi.ac.uk> Message-ID: Hi Jose, jose miguel mut writes: > I think that ODB might be caching some statements, so I would like to > know if it's possible to not cache anything. ODB doesn't do any caching that would result in continuous memory growth. For a single persistent object it would prepare and cache the statements but that would stay constant whether you perform 10 or 10M operations on this object. This is seems to be an SQLite problem/limitation. I found this discussion which seems to be about the same problem and it has a number of suggestions that you could try: http://stackoverflow.com/questions/15255409/how-to-reduce-sqlite-memory-consumption Also, if you find a solution or a better understanding of the problem, a quick note to this mailing list would be much appreciated, in case others hit a similar issue in the future. Boris From vyelnikov at adfsolutions.com Mon Oct 31 11:31:43 2016 From: vyelnikov at adfsolutions.com (Vladimir Yelnikov) Date: Mon Oct 31 11:31:55 2016 Subject: [odb-users] database generated ID combined with manual ID in SQLite In-Reply-To: References: Message-ID: Hi Boris, It will be nice to get pre-release build. Thank you. Another question: will it generate proper relation records in DB for One-to-Many relationship? It generates internal tables where object_id = NULL without that fix. On Wed, Oct 26, 2016 at 5:44 PM, Boris Kolpackov wrote: > Hi Vladimir, > > Vladimir Yelnikov writes: > > > The first solution I tried is using nullable IDs and rely on SQLite > > behavior when id is NULL - id will be generated. > > > > struct SomeClass > > { > > #pragma id auto > > odb::nullable id_; > > } > > Ok, I've implemented support for this (but only for SQLite). Now if you > set id_ to NULL you will get an auto-assigned value. Otherwise, the value > you specified will be used. > > I can package you a pre-release if you would like to give it a try. > > Boris >