From boris at codesynthesis.com Mon Dec 2 05:43:38 2013 From: boris at codesynthesis.com (Boris Kolpackov) Date: Mon Dec 2 05:46:03 2013 Subject: [odb-users] Problems with foreign key constraints when erasing In-Reply-To: References: Message-ID: Hi Troy, Troy Heron writes: > Is there much involved in the implementation or is it mostly a matter > of turning it on? All the underlying machinery is already there (we use ON DELETE CASCADE internally to implement containers). So it is a matter of adding the pragmas, diagnosing all the corner cases, adding a test, and writing the documentation. In fact, I've done the first three this morning. Can you let me know which ODB compiler package you are using? Boris From astek.rbasset at tisseo.fr Mon Dec 2 06:09:51 2013 From: astek.rbasset at tisseo.fr (astek.rbasset) Date: Mon Dec 2 06:48:55 2013 Subject: [odb-users] internal compiler error in pointer-traits.hxx Message-ID: Hello, I'm trying to build my first ODB project on Windows XP with MinGW *.hpp sources DO compile on linux platform, but Windows compilation gets an internal compiler error : 8< ------------------------------------- >8 D:\users\\src>odb -d sqlite -p boost -I D:\users\\includes -I D:\boost_1_55_0 --default-pointer boost::shared_ptr -o odb_obj_headers -q -s -e odb_obj_headers/*.hpp *** 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 | odb PLUGIN_PRAGMAS | odb PLUGIN_OVERRIDE_GATE | odb In file included from :8:0: D:\users\\includes/odb/tr1/pointer-traits.hxx: In destructor 'virtual boost::exception_detail::clone_base::~clone_base()': D:\users\\includes/odb/tr1/pointer-traits.hxx:116:1: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See for instructions. 8< ------------------------------------- >8 Note that I had to add boost complete library in include path (D:\boost_1_55_0) because of this previous error : 8< ------------------------------------- >8 D:\users\\src>odb -d sqlite -p boost --default-pointer boost::shared_ptr -o odb_obj_headers -q -s -e odb_obj_headers/*.hpp In file included from :1:0: d:\odb\odb-2.3.0-i686-windows\mingw\bin\../../mingw/include/odb/boost/date-time/sqlite/gregorian-mapping.hxx:8:57: fatal error: boost/date_time/gregorian/gregorian_types.hpp: No such file or directory compilation terminated. 8< ------------------------------------- >8 ODB : 2.3.0 BOOST : 1.55 MinGW : latest form http://sourceforge.net/projects/mingw/ Any help is welcome ! Rodolphe From boris at codesynthesis.com Mon Dec 2 06:55:50 2013 From: boris at codesynthesis.com (Boris Kolpackov) Date: Mon Dec 2 06:58:14 2013 Subject: [odb-users] internal compiler error in pointer-traits.hxx In-Reply-To: References: Message-ID: Hi Rodolphe, astek.rbasset writes: > D:\users\\src>odb -d sqlite -p boost -I \ > D:\users\\includes -I D:\boost_1_55_0 --default-pointer \ > boost::shared_ptr -o odb_obj_headers -q -s -e odb_obj_headers/*.hpp Can you try to compile each header file in odb_obj_headers individually and see which one causes the ODB compiler to crash. If you could then send this file to me (you can send it off-list if you want to keep it private), then I could try to figure out what's wrong. Boris From astek.rbasset at tisseo.fr Mon Dec 2 08:38:22 2013 From: astek.rbasset at tisseo.fr (astek.rbasset) Date: Mon Dec 2 09:15:35 2013 Subject: [odb-users] internal compiler error in pointer-traits.hxx In-Reply-To: References: Message-ID: Hi Boris, Thanks for your attention. 3 / 7 are not compiling, 4 / 7 are properly compiling. Here's two of them not compiling (following private email) Control.hpp Inspector.hpp I cannot see what makes the difference. Was I wrong in adding "-I D:\boost_1_55_0", could be another version / implementation of boost lib ? Thanks for helping, Rodolphe -----Message d'origine----- De?: Boris Kolpackov [mailto:boris@codesynthesis.com] Envoy??: lundi 2 d?cembre 2013 12:56 ??: astek.rbasset Cc?: odb-users@codesynthesis.com Objet?: Re: [odb-users] internal compiler error in pointer-traits.hxx Hi Rodolphe, astek.rbasset writes: > D:\users\\src>odb -d sqlite -p boost -I \ > D:\users\\includes -I D:\boost_1_55_0 --default-pointer \ > boost::shared_ptr -o odb_obj_headers -q -s -e odb_obj_headers/*.hpp Can you try to compile each header file in odb_obj_headers individually and see which one causes the ODB compiler to crash. If you could then send this file to me (you can send it off-list if you want to keep it private), then I could try to figure out what's wrong. Boris From boris at codesynthesis.com Mon Dec 2 09:18:01 2013 From: boris at codesynthesis.com (Boris Kolpackov) Date: Mon Dec 2 09:20:26 2013 Subject: [odb-users] internal compiler error in pointer-traits.hxx In-Reply-To: References: Message-ID: Hi Rodolphe, Ok, I've managed to reproduce the crash on both Windows and Linux. The problem is with the combination of the const pointed-to object: boost::shared_ptr _lineSpot; And Boost 1.55.0. That is, if I remove const from the above line, everything compiles fine. Similarly, if I use an earlier version of Boost (I tried 1.52.0) leaving const in place, everything compiles fine as well. I am still going to investigate further (and hopefully fix) this strange combination. In the meantime you can use these two changes as potential workarounds. Boris From astek.rbasset at tisseo.fr Mon Dec 2 10:32:13 2013 From: astek.rbasset at tisseo.fr (astek.rbasset) Date: Mon Dec 2 13:24:48 2013 Subject: [odb-users] internal compiler error in pointer-traits.hxx In-Reply-To: References: Message-ID: Hi Boris, Thanks a lot for this diagnostic ! You're right, well-compiled files has no boost::shared_ptr use ! Indeed, linux compiles with libodb-2.2.so and libboost_system.so.5, which seems to be older... I'll remove temporarily the const keyword to go further with my project. All *.hpp is compiled ! Thanks a lot ! Rodolphe -----Message d'origine----- De?: Boris Kolpackov [mailto:boris@codesynthesis.com] Envoy??: lundi 2 d?cembre 2013 15:18 ??: astek.rbasset Cc?: odb-users@codesynthesis.com Objet?: Re: [odb-users] internal compiler error in pointer-traits.hxx Hi Rodolphe, Ok, I've managed to reproduce the crash on both Windows and Linux. The problem is with the combination of the const pointed-to object: boost::shared_ptr _lineSpot; And Boost 1.55.0. That is, if I remove const from the above line, everything compiles fine. Similarly, if I use an earlier version of Boost (I tried 1.52.0) leaving const in place, everything compiles fine as well. I am still going to investigate further (and hopefully fix) this strange combination. In the meantime you can use these two changes as potential workarounds. Boris From troy.heron at hixxy.org Tue Dec 3 00:46:18 2013 From: troy.heron at hixxy.org (Troy Heron) Date: Tue Dec 3 00:46:26 2013 Subject: [odb-users] Problems with foreign key constraints when erasing In-Reply-To: References: Message-ID: I am using the most recent package from the website: ODB object-relational mapping (ORM) compiler for C++ 2.3.0 I have another question ;) Initially I was planning on using the object's 'name' as the primary key, but my application requires that this no be static (objects can be renamed). It seems that this would not be possible with foreign key constraints. So... I've changed all the objects to have a separate id field as primary key and made the name a unique constraint instead. Now I'm having troubles with using load() as at the time of loading an object, I know the name, not the id. Of course, I could query for the object, but that doesn't return a shared_ptr like load does. Any idea what the best way to deal with this situation is? I need a primary key that can change without breaking foreign key constraints or to be able to load using a field other than the primary key. I may have missed something in the docs (which are great btw)... any help appreciated. Thanks, Troy On Mon, Dec 2, 2013 at 8:43 PM, Boris Kolpackov wrote: > Hi Troy, > > Troy Heron writes: > > > Is there much involved in the implementation or is it mostly a matter > > of turning it on? > > All the underlying machinery is already there (we use ON DELETE CASCADE > internally to implement containers). So it is a matter of adding the > pragmas, diagnosing all the corner cases, adding a test, and writing > the documentation. In fact, I've done the first three this morning. > > Can you let me know which ODB compiler package you are using? > > Boris > From troy.heron at hixxy.org Tue Dec 3 00:49:34 2013 From: troy.heron at hixxy.org (Troy Heron) Date: Tue Dec 3 00:49:41 2013 Subject: [odb-users] Problems with foreign key constraints when erasing In-Reply-To: References: Message-ID: Further to that previous email, I'm using this horrible hack to work around to issue until I figure out what to do in the long term: http://pastebin.com/4ebvY6Pw On Tue, Dec 3, 2013 at 3:46 PM, Troy Heron wrote: > I am using the most recent package from the website: > > ODB object-relational mapping (ORM) compiler for C++ 2.3.0 > > I have another question ;) > > Initially I was planning on using the object's 'name' as the primary key, > but my application requires that this no be static (objects can be > renamed). It seems that this would not be possible with foreign key > constraints. So... I've changed all the objects to have a separate id field > as primary key and made the name a unique constraint instead. Now I'm > having troubles with using load() as at the time of loading an object, I > know the name, not the id. Of course, I could query for the object, but > that doesn't return a shared_ptr like load does. > > Any idea what the best way to deal with this situation is? I need a > primary key that can change without breaking foreign key constraints or to > be able to load using a field other than the primary key. > > I may have missed something in the docs (which are great btw)... any help > appreciated. > > Thanks, > Troy > > > On Mon, Dec 2, 2013 at 8:43 PM, Boris Kolpackov wrote: > >> Hi Troy, >> >> Troy Heron writes: >> >> > Is there much involved in the implementation or is it mostly a matter >> > of turning it on? >> >> All the underlying machinery is already there (we use ON DELETE CASCADE >> internally to implement containers). So it is a matter of adding the >> pragmas, diagnosing all the corner cases, adding a test, and writing >> the documentation. In fact, I've done the first three this morning. >> >> Can you let me know which ODB compiler package you are using? >> >> Boris >> > > From boris at codesynthesis.com Tue Dec 3 01:47:52 2013 From: boris at codesynthesis.com (Boris Kolpackov) Date: Tue Dec 3 01:50:17 2013 Subject: [odb-users] Problems with foreign key constraints when erasing In-Reply-To: References: Message-ID: Hi Troy, Troy Heron writes: > I am using the most recent package from the website Are you using a pre-built binary for the ODB compiler, a .deb package, or .rpm? Also which platform (Linux, Windows, etc.), and architecture (i686, x86_64, etc)? I will need to build you one for the beta-testing. > Initially I was planning on using the object's 'name' as the primary key, > but my application requires that this no be static (objects can be > renamed). It seems that this would not be possible with foreign key > constraints. So... I've changed all the objects to have a separate id field > as primary key and made the name a unique constraint instead. Now I'm > having troubles with using load() as at the time of loading an object, I > know the name, not the id. Of course, I could query for the object, but > that doesn't return a shared_ptr like load does. > > Any idea what the best way to deal with this situation is? I need a primary > key that can change without breaking foreign key constraints or to be able > to load using a field other than the primary key. Having a separate id (probably auto) makes sense. What you are missing is the fact that you can load the object from the query result iterator: auto r = db->query(query::name == name); shared_ptr o = r.begin ().load (); This is discussed in Section 4.4, "Query Result". Also, if you are concerned with performance of this approach (compared to database::load()), then you may want to consider preparing and caching the query (Section 4.5, "Prepared Queries"). This way it will be as efficient as database::load(). Boris From troy.heron at hixxy.org Tue Dec 3 02:03:14 2013 From: troy.heron at hixxy.org (Troy Heron) Date: Tue Dec 3 02:03:21 2013 Subject: [odb-users] Problems with foreign key constraints when erasing In-Reply-To: References: Message-ID: I'm using the pre-built .deb ODB compiler on x68_64 Linux. I completely missed that load() member on the iterator. Thanks, exactly what I was looking for. On Tue, Dec 3, 2013 at 4:47 PM, Boris Kolpackov wrote: > Hi Troy, > > Troy Heron writes: > > > I am using the most recent package from the website > > Are you using a pre-built binary for the ODB compiler, a .deb > package, or .rpm? Also which platform (Linux, Windows, etc.), > and architecture (i686, x86_64, etc)? > > I will need to build you one for the beta-testing. > > > > Initially I was planning on using the object's 'name' as the primary key, > > but my application requires that this no be static (objects can be > > renamed). It seems that this would not be possible with foreign key > > constraints. So... I've changed all the objects to have a separate id > field > > as primary key and made the name a unique constraint instead. Now I'm > > having troubles with using load() as at the time of loading an object, I > > know the name, not the id. Of course, I could query for the object, but > > that doesn't return a shared_ptr like load does. > > > > Any idea what the best way to deal with this situation is? I need a > primary > > key that can change without breaking foreign key constraints or to be > able > > to load using a field other than the primary key. > > Having a separate id (probably auto) makes sense. What you are missing > is the fact that you can load the object from the query result iterator: > > auto r = db->query(query::name == name); > shared_ptr o = r.begin ().load (); > > This is discussed in Section 4.4, "Query Result". > > Also, if you are concerned with performance of this approach (compared > to database::load()), then you may want to consider preparing and > caching the query (Section 4.5, "Prepared Queries"). This way it will > be as efficient as database::load(). > > Boris > From Mikhail.Tomilov at infotecs.ru Tue Dec 3 08:32:48 2013 From: Mikhail.Tomilov at infotecs.ru (Mikhail Tomilov) Date: Tue Dec 3 08:37:17 2013 Subject: [odb-users] Postgresql column with default value Message-ID: <529DDD80.5060506@infotecs.ru> Hello! We have postgresql 9.1 table: CREATE TABLE test ( id bigserial primary key, some_field text not null default some_heavy_computation_procedure() ); C++ code: #pragma db object struct test { #pragma id auto long long id; std::string some_field; }; test t; db.persist( t ); std::cout << t.some_field; // expecting to get actual DB value calculated by some_heavy_computation_procedure() With code above we get this SQL: INSERT INTO test(id, some_field) VALUES(DEFAULT, $1) RETURNING id; But we need to get SQL query like this: INSERT INTO test(id, some_field) VALUES(DEFAULT, DEFAULT) RETURNING id, some_field; We want to persist this class instance with DB default value for some_field. some_heavy_computation_procedure() is stored procedure that performs complex calculation we cannot implement in C++ code (for some reason). We considered to use callbacks but didn't get it worked the way we want (described above). Also we tried to use struct like this: #pragma db object table("test") struct test_ins { #pragma id auto long long id; // Intentionally absent some_field }; This doesn't suit for polymorphic objects (because of typeid column and we had to perform additional select query after persist call). What is the best approach to solve this problem? Regards, Mikhail. From boris at codesynthesis.com Wed Dec 4 03:02:29 2013 From: boris at codesynthesis.com (Boris Kolpackov) Date: Wed Dec 4 03:04:57 2013 Subject: [odb-users] Postgresql column with default value In-Reply-To: <529DDD80.5060506@infotecs.ru> References: <529DDD80.5060506@infotecs.ru> Message-ID: Hi Mikhail, Mikhail Tomilov writes: > We considered to use callbacks but didn't get it worked the way we > want (described above). Unfortunately there is still no support for the RETURNING clause in ODB. It is on our TODO list but is not yet implemented. For now, the workaround is the same as what I have described in my previous reply: http://www.codesynthesis.com/pipermail/odb-users/2013-July/001457.html That is, send the NULL value on persist() and load the computed data member in a callback. Unfortunately, this will require a separate query, but that's the best that can be done until proper support for RETURNING is implemented. Here is an outline: // file: test.hxx // #include #pragma db object callback(init) struct test { #pragma id auto long long id; odb::nullable some_field; void init (odb::callback_event, odb::database&) const; }; #pragma db view object(test) struct test_computed { std::string some_field; }; // file: test.cxx // void test:: init (odb::callback_event e, odb::database& db) const { switch (e) { case odb::callback_event::pre_persist: { // Reset some_field to NULL so that the default value is // assigned by the database. // const_cast (this)->some_field.reset (); break; } case odb::callback_event::post_persist: { // Load the computed fields using the test_computed view. // test_computed v; db.query ( odb::query::id == id).begin ().load (v); const_cast (this)->some_field = v.some_field; break; } } } You can further optimize this by preparing and caching the query used to load computed members (Section 4.5, "Prepared Queries"). Boris From boris at codesynthesis.com Wed Dec 4 05:28:38 2013 From: boris at codesynthesis.com (Boris Kolpackov) Date: Wed Dec 4 05:31:02 2013 Subject: [odb-users] internal compiler error in pointer-traits.hxx In-Reply-To: References: Message-ID: Hi Rodolphe, Boris Kolpackov writes: > I am still going to investigate further (and hopefully fix) this > strange combination. Ok, I've fixed this. I am not planning to make a bug-fix release yet for this issue since it is fairly obscure. You can continue using one of the workarounds I mentioned or I can build you a pre-release binary. There is also the patch if anyone is interested: http://scm.codesynthesis.com/?p=odb/odb.git;a=commit;h=ab4abe514a617ef530a18d5f71950d082ebd1ac4 Boris From astek.rbasset at tisseo.fr Thu Dec 5 04:13:14 2013 From: astek.rbasset at tisseo.fr (astek.rbasset) Date: Thu Dec 5 06:00:03 2013 Subject: [odb-users] internal compiler error in pointer-traits.hxx In-Reply-To: References: Message-ID: Hi Boris, Good work ! 'Hope I made things progress... though it wasn't my first goal ;-) A pre-release is welcome, avoid me to fork from linux sources on my project to build on windows. My current build is "odb-2.3.0-i686-windows" (Win32/XP) Thanks a lot, Rodolphe -----Message d'origine----- De?: Boris Kolpackov [mailto:boris@codesynthesis.com] Envoy??: mercredi 4 d?cembre 2013 11:29 ??: astek.rbasset Cc?: odb-users@codesynthesis.com Objet?: Re: [odb-users] internal compiler error in pointer-traits.hxx Hi Rodolphe, Boris Kolpackov writes: > I am still going to investigate further (and hopefully fix) this > strange combination. Ok, I've fixed this. I am not planning to make a bug-fix release yet for this issue since it is fairly obscure. You can continue using one of the workarounds I mentioned or I can build you a pre-release binary. There is also the patch if anyone is interested: http://scm.codesynthesis.com/?p=odb/odb.git;a=commit;h=ab4abe514a617ef530a18d5f71950d082ebd1ac4 Boris From Aleksey.Enakaev at infotecs.ru Fri Dec 6 01:27:34 2013 From: Aleksey.Enakaev at infotecs.ru (=?UTF-8?B?0JXQvdCw0LrQsNC10LIg0JDQu9C10LrRgdC10Lk=?=) Date: Fri Dec 6 02:42:37 2013 Subject: [odb-users] ODB pgsql compiling problem Message-ID: <52A16E56.2010006@infotecs.ru> Hi. First, I want to thank you for answers to our previous emails. Now, I'd like to inform you about a problem we discovered. If we describe some DB view in a separate file, then generate ODB code (files *.odb.cpp) and try compiling them we will get a compiler error message. (Note: it's all about pgsql code generation). Compiler says: ".../odb/pgsql/view-result.hxx:68:7: error: ?view_traits_calls? does not name a type" Investigation we had taken showed that there was a private field view_traits_calls tc_ added to class view_result_impl. Class declaration view_traits_calls was found in odb/pgsql/traits-calls.hxx file. The problem has been solved after we added #include to "odb/pgsql/view-result.hxx". (Note: the same ODB code generated for the sqlite database is compiled without error.) We suppose you'd like to know about this problem to fix it in next versions. Best regards, Aleksey, Mikhail. From boris at codesynthesis.com Fri Dec 6 03:14:05 2013 From: boris at codesynthesis.com (Boris Kolpackov) Date: Fri Dec 6 03:16:29 2013 Subject: [odb-users] libodb-pgsql 2.3.1 bugfix released Message-ID: Hi, A new bugfix release for the PostgreSQL ODB runtime library (libodb-pgsql) is now available. It adds a missing include file that affected compilation of generated files that contain only views. For more details on this issue, see the following mailing list thread: http://www.codesynthesis.com/pipermail/odb-users/2013-December/001653.html You can download the new packages from the ODB download page: http://www.codesynthesis.com/products/odb/download.xhtml SHA1 checksums for the files in this release are as follows: 91f5688decb0269f630f7a88d16a5a73b9ebb284 libodb-pgsql-2.3.1.tar.bz2 8b1874747580ac840f4b22c4b7b13a1523a9f270 libodb-pgsql-2.3.1.tar.gz 985b191ff1c84fcf94400db70b219023bfdfffd3 libodb-pgsql-2.3.1.zip Boris From boris at codesynthesis.com Fri Dec 6 03:22:29 2013 From: boris at codesynthesis.com (Boris Kolpackov) Date: Fri Dec 6 03:24:54 2013 Subject: [odb-users] ODB pgsql compiling problem In-Reply-To: <52A16E56.2010006@infotecs.ru> References: <52A16E56.2010006@infotecs.ru> Message-ID: Hi Aleksey, ??????? ??????? writes: > The problem has been solved after we added #include > to "odb/pgsql/view-result.hxx". Yes, that's a bug. I've just released a bugfix for libodb-pgsql: http://www.codesynthesis.com/pipermail/odb-announcements/2013/000038.html Thanks for reporting it! Boris From boris at codesynthesis.com Fri Dec 6 05:36:24 2013 From: boris at codesynthesis.com (Boris Kolpackov) Date: Fri Dec 6 05:38:48 2013 Subject: [odb-users] Problems with foreign key constraints when erasing In-Reply-To: References: Message-ID: Hi Troy, Troy Heron writes: > I'm using the pre-built .deb ODB compiler on x68_64 Linux. Ok, the pre-release is ready: http://www.codesynthesis.com/~boris/tmp/odb/pre-release/ Note that besides installing the ODB compiler, you will also need to build and install new runtime libraries (libodb, etc). The documentation for the new on_delete pragma can be found in Section 14.4.15, "on_delete" in the ODB manual that comes with the ODB compiler (installed into /usr/share/doc/odb/). Let me know how it goes. Boris From boris at codesynthesis.com Fri Dec 6 05:37:43 2013 From: boris at codesynthesis.com (Boris Kolpackov) Date: Fri Dec 6 05:40:08 2013 Subject: [odb-users] Problems with foreign key constraints when erasing In-Reply-To: References: Message-ID: Hi Per, Per Edin writes: > I heavily rely on CASCADE in other projects although I have yet to > experience any problems with ODB's lack of supportt. If you implement > support I would happily beta-test it! Thanks. The pre-release is here: http://www.codesynthesis.com/~boris/tmp/odb/pre-release/ If you need a different package for the ODB compiler, let me know. Boris From boris at codesynthesis.com Fri Dec 6 05:39:47 2013 From: boris at codesynthesis.com (Boris Kolpackov) Date: Fri Dec 6 05:42:12 2013 Subject: [odb-users] internal compiler error in pointer-traits.hxx In-Reply-To: References: Message-ID: Hi Rodolphe, astek.rbasset writes: > A pre-release is welcome, avoid me to fork from linux sources on my > project to build on windows. > > My current build is "odb-2.3.0-i686-windows" (Win32/XP) I've packaged a pre-release with the fix which you can find here: http://www.codesynthesis.com/~boris/tmp/odb/pre-release/ Note that besides the ODB compiler itself, you will also need to build new runtimes (libodb, etc). Let me know if there are any problems. Boris From scott.deerwester at gmail.com Fri Dec 6 10:37:22 2013 From: scott.deerwester at gmail.com (Scott Deerwester) Date: Fri Dec 6 10:37:51 2013 Subject: [odb-users] ODB segfaults in Qt profile Message-ID: I am receiving the following error: odb --database mysql --profile qt --generate-schema --generate-query --generate-session -I/opt/Qt/5.1.1/gcc_64/include -I/opt/Qt/5.1.1/gcc_64/include/QtCore ../ODBExample/ChildClass.h *** 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 | odb PLUGIN_PRAGMAS | odb PLUGIN_OVERRIDE_GATE | odb In file included from :8:0: /usr/local/include/odb/tr1/pointer-traits.hxx: In member function ?virtual const char* __gnu_cxx::__concurrence_lock_error::what() const?: /usr/local/include/odb/tr1/pointer-traits.hxx:116:1: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See for instructions. make: *** [ChildClass-odb.cxx] Error 1 Here is file ChildClass.h: #ifndef CHILDCLASS_H #define CHILDCLASS_H #include #include #include class ParentClass; #pragma db object class ChildClass { public: ChildClass(); const QString getID() const; void setID(QString &aID); private: friend class odb::access; #pragma db id QString id_; QSharedPointer parent_; }; #endif // CHILDCLASS_H and here is file ParentClass.h: #ifndef PARENTCLASS_H #define PARENTCLASS_H #include #include #include #include #include "ChildClass.h" #pragma db object class ParentClass { public: ParentClass(); ParentClass(QString aID); const QString getID() const; void setID(QString &aID); private: friend class odb::access; #pragma db id QString id_; bool bool_; int int_; #pragma db not_null inverse(parent_) QMap > children_; }; #endif // PARENTCLASS_H I am running Qt 5.1.1, odb 2.3.0 and gcc 4.6.3 on Ubuntu 12.04. Any ideas? From boris at codesynthesis.com Fri Dec 6 11:20:51 2013 From: boris at codesynthesis.com (Boris Kolpackov) Date: Fri Dec 6 11:23:16 2013 Subject: [odb-users] ODB segfaults in Qt profile In-Reply-To: References: Message-ID: Hi Scott, Scott Deerwester writes: > QSharedPointer parent_;> > > [...] > > QMap > children_; I am pretty sure this is the same bug that was reported a few days ago: http://www.codesynthesis.com/pipermail/odb-users/2013-December/001640.html Can you try to remove the const's and see if it help. If it does then there is a pre-release available with the fix: http://www.codesynthesis.com/~boris/tmp/odb/pre-release/ Note that you will also need to update the runtime libraries (libodb, etc) besides the ODB compiler. Or, if you built the ODB compiler from source, you can apply the patch: http://scm.codesynthesis.com/?p=odb/odb.git;a=commit;h=ab4abe514a617ef530a18d5f71950d082ebd1ac4 Boris From scott.deerwester at gmail.com Fri Dec 6 11:47:03 2013 From: scott.deerwester at gmail.com (Scott Deerwester) Date: Fri Dec 6 11:47:31 2013 Subject: [odb-users] ODB segfaults in Qt profile In-Reply-To: References: Message-ID: That did it, thank you. I'll load the prerelease and try putting the consts back. On Fri, Dec 6, 2013 at 11:20 AM, Boris Kolpackov wrote: > Hi Scott, > > Scott Deerwester writes: > > > QSharedPointer parent_;> > > > > [...] > > > > QMap > children_; > > I am pretty sure this is the same bug that was reported a few > days ago: > > http://www.codesynthesis.com/pipermail/odb-users/2013-December/001640.html > > Can you try to remove the const's and see if it help. If it does then > there is a pre-release available with the fix: > > http://www.codesynthesis.com/~boris/tmp/odb/pre-release/ > > Note that you will also need to update the runtime libraries (libodb, > etc) besides the ODB compiler. > > Or, if you built the ODB compiler from source, you can apply the patch: > > > http://scm.codesynthesis.com/?p=odb/odb.git;a=commit;h=ab4abe514a617ef530a18d5f71950d082ebd1ac4 > > Boris > From troy.heron at hixxy.org Fri Dec 6 16:00:52 2013 From: troy.heron at hixxy.org (Troy Heron) Date: Fri Dec 6 16:01:01 2013 Subject: [odb-users] Problems with foreign key constraints when erasing In-Reply-To: References: Message-ID: Thanks Boris. Will give it a work over sometime today or tomorrow. I'm just looking at using --include-regex at the moment. What regex engine is it using? Does it support negative lookbehind? Thanks On Fri, Dec 6, 2013 at 8:36 PM, Boris Kolpackov wrote: > Hi Troy, > > Troy Heron writes: > > > I'm using the pre-built .deb ODB compiler on x68_64 Linux. > > Ok, the pre-release is ready: > > http://www.codesynthesis.com/~boris/tmp/odb/pre-release/ > > Note that besides installing the ODB compiler, you will also need > to build and install new runtime libraries (libodb, etc). > > The documentation for the new on_delete pragma can be found in Section > 14.4.15, "on_delete" in the ODB manual that comes with the ODB compiler > (installed into /usr/share/doc/odb/). > > Let me know how it goes. > > Boris > From troy.heron at hixxy.org Fri Dec 6 16:54:48 2013 From: troy.heron at hixxy.org (Troy Heron) Date: Fri Dec 6 16:54:55 2013 Subject: [odb-users] Problems with foreign key constraints when erasing In-Reply-To: References: Message-ID: Nevermind. I've discovered what I need to know. It does support negative look-behind and was only user-error of course :) On Sat, Dec 7, 2013 at 7:00 AM, Troy Heron wrote: > Thanks Boris. Will give it a work over sometime today or tomorrow. > > I'm just looking at using --include-regex at the moment. What regex engine > is it using? Does it support negative lookbehind? > > Thanks > > > On Fri, Dec 6, 2013 at 8:36 PM, Boris Kolpackov wrote: > >> Hi Troy, >> >> Troy Heron writes: >> >> > I'm using the pre-built .deb ODB compiler on x68_64 Linux. >> >> Ok, the pre-release is ready: >> >> http://www.codesynthesis.com/~boris/tmp/odb/pre-release/ >> >> Note that besides installing the ODB compiler, you will also need >> to build and install new runtime libraries (libodb, etc). >> >> The documentation for the new on_delete pragma can be found in Section >> 14.4.15, "on_delete" in the ODB manual that comes with the ODB compiler >> (installed into /usr/share/doc/odb/). >> >> Let me know how it goes. >> >> Boris >> > > From lidia at lemur-soft.com Tue Dec 10 15:05:55 2013 From: lidia at lemur-soft.com (Lidia Kalinovsky) Date: Tue Dec 10 15:06:01 2013 Subject: [odb-users] is it possible to use same relationship table for 2 class data members ? Message-ID: Hello For example, something like this : // contained object #pragma db object class B { private: friend class odb::access; int m; }; // container #pragma db object class A { public: ... private: friend class odb::access; #pragma db table("A_bs") std::unordered_map , std::hash> m_bsMap; std::vector > m_bs; }; ( i see solution with defining one member as transient and using db callback functions to update/load it ). Any advice/suggestion is really appreciated. Thanks. Lidia. From arnoud.van-der-wal at nz.abb.com Tue Dec 10 15:37:37 2013 From: arnoud.van-der-wal at nz.abb.com (Arnoud van-der-Wal) Date: Tue Dec 10 15:37:54 2013 Subject: [odb-users] Sqlite auto ID persists with ID=NULL returns NULL? Message-ID: We are trying to use the nullable ID entries but hitting issues with the returned ID. Sqlite has the feature that it can create unique primarily keys when the ID is set to NULL - without needing to use AUTOINCREMENT the "auto" pragma . In our app we like to avoid to use the AUTOINCREMENT. When doing a persists() and selecting NULL for ID in ODB 2.3.0 then Sqlite assigns an correct ID and writes the table rows in the database. But for some reason the db->persists() does not return the assigned ID and it just returns the id as NULL ( null_ set true). That is a problem, because we need to use the ID. When selecting pragma 'auto' using autoincrement it works correctly and returns the created ID. Example class #pragma db object table("test") pointer(*) class tOrm_test_table { public: friend class odb::access; #pragma db id type("INTEGER") column("id") odb::nullable m_id; #pragma db type("INTEGER") column("is_integer") int mInteger; }; In the code used the sequence is similar to odb::database * db ( new odb::sqlite::database ( "\\test.db", (int)SQLITE_OPEN_READWRITE | SQLITE_OPEN_CREATE, false, "" )); tOrm_test_table test; test.m_id.reset(); odb::transaction t ( db->begin() ); odb::nullable id; id = db->persist ( &test ); t.commit(); What do we wrong? How can we obtain the ID of the just persist class? Thanks, Arnoud From boris at codesynthesis.com Wed Dec 11 00:07:51 2013 From: boris at codesynthesis.com (Boris Kolpackov) Date: Wed Dec 11 00:10:15 2013 Subject: [odb-users] Sqlite auto ID persists with ID=NULL returns NULL? In-Reply-To: References: Message-ID: Hi Arnoud, Arnoud van-der-Wal writes: > When doing a persists() and selecting NULL for ID in ODB 2.3.0 then > Sqlite assigns an correct ID and writes the table rows in the database. > But for some reason the db->persists() does not return the assigned ID > and it just returns the id as NULL ( null_ set true). The reason for this is that without auto ODB doesn't know that you are using database-generated IDs. The ODB way of doing what you want is to use the --sqlite-lax-auto-id option. Quoting the documentation: "Do not force monotonically increasing automatically-assigned object ids. In this mode the generated database schema omits the AUTOINCREMENT keyword which results in faster object persistence but may lead to automatically-assigned ids not being in a strictly ascending order. Refer to the SQLite documentation for details." The good thing with this approach is that you don't need to mess with NULLs; ODB will do everything automatically for you. Boris From boris at codesynthesis.com Wed Dec 11 00:14:15 2013 From: boris at codesynthesis.com (Boris Kolpackov) Date: Wed Dec 11 00:16:38 2013 Subject: [odb-users] is it possible to use same relationship table for 2 class data members ? In-Reply-To: References: Message-ID: Hi Lidia, Lidia Kalinovsky writes: > #pragma db table("A_bs") > std::unordered_map , std::hash> m_bsMap; > > std::vector > m_bs; > > ( i see solution with defining one member as transient and using db > callback functions to update/load it ). Yes, this is probably the most straightforward way. If you have many objects with such containers (or containers of this template), then it may be better to create your own container wrapper that maintains the two underlying containers. You can then add a custom mapping for such a container for ODB. Let me know if you are interested in this approach and I can provide more details. Boris From lidia at lemur-soft.com Wed Dec 11 01:44:05 2013 From: lidia at lemur-soft.com (Lidia Kalinovsky) Date: Wed Dec 11 01:44:13 2013 Subject: [odb-users] is it possible to use same relationship table for 2 class data members ? In-Reply-To: References: Message-ID: Hello Boris. We definitely will try to use custom mapping odb functionality. If you could recommend some known payment free solution for map implementation that works well as std::map and has directs "values" function ( get vector of values without iterating ), it will be great. Thanks a lot for quick response and great library. Lidia. On Wed, Dec 11, 2013 at 7:14 AM, Boris Kolpackov wrote: > Hi Lidia, > > Lidia Kalinovsky writes: > > > #pragma db table("A_bs") > > std::unordered_map , > std::hash> m_bsMap; > > > > std::vector > m_bs; > > > > ( i see solution with defining one member as transient and using db > > callback functions to update/load it ). > > Yes, this is probably the most straightforward way. > > If you have many objects with such containers (or containers of > this template), then it may be better to create your own container > wrapper that maintains the two underlying containers. You can then > add a custom mapping for such a container for ODB. Let me know if > you are interested in this approach and I can provide more details. > > Boris > -- Software integration and outsourcing services, Lemur-Soft, Giv'at Nili Israel, 37825 Phone : (+972) 545748325 Fax : (+972) 775345383 Email : lidia@lemur-soft.com Web: www.lemur-soft.com From boris at codesynthesis.com Wed Dec 11 02:03:04 2013 From: boris at codesynthesis.com (Boris Kolpackov) Date: Wed Dec 11 02:05:27 2013 Subject: [odb-users] is it possible to use same relationship table for 2 class data members ? In-Reply-To: References: Message-ID: Hi Lidia, Lidia Kalinovsky writes: > If you could recommend some known payment free solution for map > implementation that works well as std::map and has directs "values" > function ( get vector of values without iterating ), it will be great. Boost multi-index container. The best part is that the ODB Boost profile already includes a mapping for this container (Section 23.3, "Multi-Index Container Library"). Boris From lidia at lemur-soft.com Wed Dec 11 03:06:19 2013 From: lidia at lemur-soft.com (Lidia Kalinovsky) Date: Wed Dec 11 03:06:26 2013 Subject: [odb-users] is it possible to use same relationship table for 2 class data members ? In-Reply-To: References: Message-ID: looks great and fit our needs - thanks ! On Wed, Dec 11, 2013 at 9:03 AM, Boris Kolpackov wrote: > Hi Lidia, > > Lidia Kalinovsky writes: > > > If you could recommend some known payment free solution for map > > implementation that works well as std::map and has directs "values" > > function ( get vector of values without iterating ), it will be great. > > Boost multi-index container. The best part is that the ODB Boost profile > already includes a mapping for this container (Section 23.3, "Multi-Index > Container Library"). > > Boris > -- Software integration and outsourcing services, Lemur-Soft, Giv'at Nili Israel, 37825 Phone : (+972) 545748325 Fax : (+972) 775345383 Email : lidia@lemur-soft.com Web: www.lemur-soft.com From scott.deerwester at gmail.com Wed Dec 11 10:30:59 2013 From: scott.deerwester at gmail.com (Scott Deerwester) Date: Wed Dec 11 10:31:28 2013 Subject: [odb-users] Assertion fails in mysql/statement.cxx Message-ID: I'm receiving the following in a unit test: tst_MyTest: statement.cxx:377: odb::mysql::select_statement::result odb::mysql::select_statement::fetch(bool): Assertion `mysql_stmt_field_count (stmt_) == count' failed. The situation is that I've just called db.find() with a key that doesn't exist, and then try again with a key that does. If you need me to, I'll try to write a minimal set of code that demonstrates the problem. From boris at codesynthesis.com Wed Dec 11 10:43:11 2013 From: boris at codesynthesis.com (Boris Kolpackov) Date: Wed Dec 11 10:45:35 2013 Subject: [odb-users] Assertion fails in mysql/statement.cxx In-Reply-To: References: Message-ID: Hi Scott, Scott Deerwester writes: > I'm receiving the following in a unit test: > > tst_MyTest: statement.cxx:377: odb::mysql::select_statement::result > odb::mysql::select_statement::fetch(bool): Assertion > `mysql_stmt_field_count (stmt_) == count' failed. The comment just before the assert() explains what it tries to catch: // Make sure that the number of columns in the result returned by // the database matches the number that we expect. A common cause // of this assertion is a native view with a number of data members // not matching the number of columns in the SELECT-list. Though it seems like you are loading an object so this can't be that. > If you need me to, I'll try to write a minimal set of code that > demonstrates the problem. Yes, that would be very helpful. Boris From scott.deerwester at gmail.com Wed Dec 11 11:28:39 2013 From: scott.deerwester at gmail.com (Scott Deerwester) Date: Wed Dec 11 11:29:07 2013 Subject: [odb-users] Assertion fails in mysql/statement.cxx In-Reply-To: References: Message-ID: Hmm. I *do* have a view defined for the class that's not working. I don't see the view in the code in the schema for this class, and so the view hasn't been defined in the database. I define the view after the class in the same header: #pragma db value(QString) type("VARCHAR(255)") #pragma db object class CodeSet { ... #pragma db id QString key_; // Identifier ... }; #pragma db view object(CodeSet) struct codeSetStat { #pragma db column("count(" + CodeSet::key_ + ")") int count; }; Do I need to do something special to get the definition for the view? On Wed, Dec 11, 2013 at 10:43 AM, Boris Kolpackov wrote: > Hi Scott, > > Scott Deerwester writes: > > > I'm receiving the following in a unit test: > > > > tst_MyTest: statement.cxx:377: odb::mysql::select_statement::result > > odb::mysql::select_statement::fetch(bool): Assertion > > `mysql_stmt_field_count (stmt_) == count' failed. > > The comment just before the assert() explains what it tries to catch: > > // Make sure that the number of columns in the result returned by > // the database matches the number that we expect. A common cause > // of this assertion is a native view with a number of data members > // not matching the number of columns in the SELECT-list. > > Though it seems like you are loading an object so this can't be that. > > > > If you need me to, I'll try to write a minimal set of code that > > demonstrates the problem. > > Yes, that would be very helpful. > > Boris > > From scott.deerwester at gmail.com Wed Dec 11 16:11:26 2013 From: scott.deerwester at gmail.com (Scott Deerwester) Date: Wed Dec 11 16:11:53 2013 Subject: [odb-users] Assertion fails in mysql/statement.cxx In-Reply-To: References: Message-ID: Okay, I've got a minimal example for you, but it's got nine files in it. How would you like me to get it to you? I presume that an email attachment to the list wouldn't be a very good idea... On Wed, Dec 11, 2013 at 11:28 AM, Scott Deerwester < scott.deerwester@gmail.com> wrote: > Hmm. I *do* have a view defined for the class that's not working. I don't > see the view in the code in the schema for this class, and so the view > hasn't been defined in the database. I define the view after the class in > the same header: > > #pragma db value(QString) type("VARCHAR(255)") > #pragma db object > class CodeSet > { > ... > #pragma db id > QString key_; // Identifier > ... > }; > > #pragma db view object(CodeSet) > struct codeSetStat { > #pragma db column("count(" + CodeSet::key_ + ")") > int count; > }; > > > Do I need to do something special to get the definition for the view? > > On Wed, Dec 11, 2013 at 10:43 AM, Boris Kolpackov > wrote: > >> Hi Scott, >> >> Scott Deerwester writes: >> >> > I'm receiving the following in a unit test: >> > >> > tst_MyTest: statement.cxx:377: odb::mysql::select_statement::result >> > odb::mysql::select_statement::fetch(bool): Assertion >> > `mysql_stmt_field_count (stmt_) == count' failed. >> >> The comment just before the assert() explains what it tries to catch: >> >> // Make sure that the number of columns in the result returned by >> // the database matches the number that we expect. A common cause >> // of this assertion is a native view with a number of data members >> // not matching the number of columns in the SELECT-list. >> >> Though it seems like you are loading an object so this can't be that. >> >> >> > If you need me to, I'll try to write a minimal set of code that >> > demonstrates the problem. >> >> Yes, that would be very helpful. >> >> Boris >> >> > From boris at codesynthesis.com Thu Dec 12 03:19:40 2013 From: boris at codesynthesis.com (Boris Kolpackov) Date: Thu Dec 12 03:22:04 2013 Subject: [odb-users] Assertion fails in mysql/statement.cxx In-Reply-To: References: Message-ID: Hi Scott, Thanks for sending the test case. The problematic part is this line: #pragma db not_null inverse(parent_) QMap > children_; An inverse container of pointers cannot be a map (remember that there is no table for an inverse container so there is no place to store the key). We should actually diagnose this in the ODB compiler and I've added this check for the next release. Once I've changed QMap to QSet, I ran into another problem in your code: since you have a bi-directional relationship between ChildClass and ParentClass, you need to use a session (object cache) when loading them. Otherwise ODB will keep loading them recursively until it runs out of stack: transaction t(this->db->begin()); odb::session s; QSharedPointer parent; if (!this->db->find(aID)) { qDebug() << "Failed to find parent" << aID; } t.commit(); With these two fixes your test runs fine. Boris From astek.rbasset at tisseo.fr Thu Dec 12 05:46:04 2013 From: astek.rbasset at tisseo.fr (astek.rbasset) Date: Thu Dec 12 07:32:42 2013 Subject: [odb-users] include odb/details/config.h on Windows / Eclipse CDT / MinGW ? Message-ID: Hello, I'm trying to build C++ application with odb libs to access an sqlite DB. I want it to be portable Linux / Windows. Linux building is OK (different version of ODB / Boost, but same source) On Windows XP, I'm using Eclipse (Kepler) CDT and MinGW as a compiler. My includes are the following ones : D:\MinGW\msys\1.0\include /PlanControle/includes D:\boost_1_55_0 D:\odb\libodb-2.3.0 D:\odb\libodb-boost-2.3.0 D:\odb\libodb-sqlite-2.3.0 D:\odb\odb-2.3.0-i686-windows\mingw\include I'm not compiling with MSVC, but I am on windows target. My question : which conf should be preprocessed in config.hxx ? #ifdef _MSC_VER # include #elif defined(ODB_COMPILER) # ... #else # include # ... #endif Do I need to define _MSC_VER ? ODB_COMPILER ? Nowadays, building cannot find odb/details/config.h nor odb/details/config-vc.h I'm a bit confused... Thanks for any help. Rodolphe From boris at codesynthesis.com Thu Dec 12 07:37:35 2013 From: boris at codesynthesis.com (Boris Kolpackov) Date: Thu Dec 12 07:39:59 2013 Subject: [odb-users] include odb/details/config.h on Windows / Eclipse CDT / MinGW ? In-Reply-To: References: Message-ID: Hi Rodolphe, astek.rbasset writes: > D:\odb\odb-2.3.0-i686-windows\mingw\include You should not include this directory. It is internal ODB compiler details. > My question : which conf should be preprocessed in config.hxx ? It should be autoconf-generated odb/details/config.h found in D:\odb\libodb-2.3.0. Have you actually built libodb for MinGW? > Do I need to define _MSC_VER ? ODB_COMPILER ? No, you should not define either of those. Boris From scott.deerwester at gmail.com Thu Dec 12 10:18:02 2013 From: scott.deerwester at gmail.com (Scott Deerwester) Date: Thu Dec 12 10:18:29 2013 Subject: [odb-users] Assertion fails in mysql/statement.cxx In-Reply-To: References: Message-ID: Thanks very much, Boris. One more question. What do I do if I need to get an ordered list of the ChildClass ID's that are associated with a ParentClass object? That was the motivation for using a QMap. I was using a QMap iterator, but QSet doesn't do that. Any ideas? On Thu, Dec 12, 2013 at 3:19 AM, Boris Kolpackov wrote: > Hi Scott, > > Thanks for sending the test case. The problematic part is this line: > > #pragma db not_null inverse(parent_) > QMap > children_; > > An inverse container of pointers cannot be a map (remember that there > is no table for an inverse container so there is no place to store the > key). We should actually diagnose this in the ODB compiler and I've > added this check for the next release. > > Once I've changed QMap to QSet, I ran into another problem in your > code: since you have a bi-directional relationship between ChildClass > and ParentClass, you need to use a session (object cache) when loading > them. Otherwise ODB will keep loading them recursively until it runs > out of stack: > > transaction t(this->db->begin()); > > odb::session s; > > QSharedPointer parent; > > if (!this->db->find(aID)) { > qDebug() << "Failed to find parent" << aID; > } > > t.commit(); > > With these two fixes your test runs fine. > > Boris > From astek.rbasset at tisseo.fr Thu Dec 12 12:11:02 2013 From: astek.rbasset at tisseo.fr (astek.rbasset) Date: Thu Dec 12 12:54:57 2013 Subject: [odb-users] include odb/details/config.h on Windows / Eclipse CDT / MinGW ? In-Reply-To: References: Message-ID: Hi Boris, >> D:\odb\odb-2.3.0-i686-windows\mingw\include > You should not include this directory. It is internal ODB compiler details. OK >> My question : which conf should be preprocessed in config.hxx ? > It should be autoconf-generated odb/details/config.h found in D:\odb\libodb-2.3.0. Have you actually built libodb for MinGW? 'should have actually read the INSTALL file... ;-) I didn't notice that I had to build : libodb, sqlite, boost, libodb-sqlite, libodb-boost And that's ok (compiled) ! Now trying to link... :-) Thanks a lot. Rodolphe From boris at codesynthesis.com Thu Dec 12 13:02:13 2013 From: boris at codesynthesis.com (Boris Kolpackov) Date: Thu Dec 12 13:04:44 2013 Subject: [odb-users] Assertion fails in mysql/statement.cxx In-Reply-To: References: Message-ID: Hi Scott, Scott Deerwester writes: > What do I do if I need to get an ordered list of the ChildClass ID's > that are associated with a ParentClass object? That was the motivation > for using a QMap. I was using a QMap iterator, but QSet doesn't do that. With std::set you can provide a custom comparator to order the objects using IDs rather than pointers (second template argument to std::set). This way iteration over set will implicitly give you an ordered list of IDs. Unfortunately, QSet doesn't seem to provide this functionality and I am not sure if any other Qt container supported by ODB does. Boris From alexis.mestag at epitech.eu Sun Dec 15 14:40:04 2013 From: alexis.mestag at epitech.eu (Alexis Mestag) Date: Sun Dec 15 14:45:11 2013 Subject: [odb-users] Using Custom Container (with template) makes odb crash Message-ID: Hello everyone, I use ODB for a school C++ project. I need relationships for my persistent objects, for example, a list of pointers. ODB recognizes relationships made with list of pointers. The problem is, in my class, I want to store a POINTER to a list of pointers to make the relationship, not the list directly. So far, in order to do that, I created a wrapper to a list, and implemented the templated odb::access::container_traits class to make ODB recognize my custom container (as it's explained in the documentation). For example, I need that : // Person.hh class Person { friend class odb::access; private: // ODB will not recognize this since it's a pointer to a list, not directly the list. std::list *_friends; }; #ifdef ODB_COMPILER # pragma db object(Person) #endif So I transform the class as followed : // Person.hh #include "Friends.hh" class Person { friend class odb::access; private: Friends *_friends; }; #ifdef ODB_COMPILER # pragma db object(Person) #endif I add this class : // Friends.hh class Friends { private: std::list *_elts; }; I implement the class odb::access::container_traits in a Friends-traits.hxx file, create the Friends.options file and add it in the parameters of the compilation command. That works well. The problem of this solution is that I need to recreate a wrapper to a list, reimplement the odb::access::container_traits class, recreate a Whatever.options file and also add it in the command each time I make a relationship. To solve this problem, I wanted to create a templated class which would wrap a list, as followed : #ifndef __LISTCONTAINER_HH__ # define __LISTCONTAINER_HH__ # include template class ListContainer { public: typedef std::list ListSubType; typedef typename ListSubType::size_type IndexType; private: ListSubType *_elts; public: ListContainer() : _elts(new ListSubType) {} virtual ~ListContainer() { delete _elts; } }; #endif And I implemented the odb::access::container_traits *> class (big file) : #ifndef __LISTCONTAINER_TRAITS_HXX__ # define __LISTCONTAINER_TRAITS_HXX__ # include # include # include "ListContainer.hpp" namespace odb { template class access::container_traits *> { public: static container_kind const kind = ck_ordered; static bool const smart = false; typedef ListContainer * container_type; typedef T value_type; typedef typename ListContainer::IndexType index_type; typedef ordered_functions functions; public: static void persist(container_type const &c, functions const &f) { index_type i = 0; for (auto it = c->_elts->cbegin() ; it != c->_elts->cend() ; ++it) { f.insert(i++, *it); } } static void load(container_type &c, bool more, functions const &f) { c->_elts->clear(); while (more) { index_type dummy = 0; c->_elts->push_back(value_type()); more = f.insert(dummy, c->_elts->back()); } } static void update(container_type const &c, functions const &f) { index_type i = 0; f.delete_(); for (auto it = c->_elts->cbegin() ; it != c->_elts->cend() ; ++it) { f.insert(i++, *it); } } static void erase(functions const &f) { f.delete_(); } }; } # include #endif The ListContainer.options file : --odb-epilogue '#include "ListContainer-traits.hxx"' --hxx-prologue '#include "ListContainer-traits.hxx"' In theory, theses classes would allow me to do this : #ifndef __PERSON_HH__ # define __PERSON_HH__ # include "Persistent.hh" # include "Nameable.hh" # include "ListContainer.hpp" class Person : public Persistent, public Nameable { friend class odb::access; private: unsigned char _age; ListContainer *_friends; private: Person(); public: Person(std::string const &name, unsigned char const age = 0); Person(Person const &rhs); virtual ~Person(); Person &operator=(Person const &rhs); unsigned char getAge() const; void setAge(unsigned char const age); }; # ifdef ODB_COMPILER # pragma db object(Person) # endif #endif I don't know if I did something wrong but when I try to compile this with the command : odb -d mysql --generate-schema-only --std c++11 --at-once --options-file ListContainer.options --input-name schema.sql Persistent.hh Nameable.hh Person.hh ODB crashes (Segmentation Fault), that's what it prints : *** 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 | odb PLUGIN_PRAGMAS | odb PLUGIN_OVERRIDE_GATE | odb In file included from /usr/include/c++/4.8.2/bits/stl_map.h:63:0, from /usr/include/c++/4.8.2/map:61, from /usr/include/odb/std-map-traits.hxx:10, from /usr/include/odb/container-traits.hxx:207, from ListContainer-traits.hxx:15, from :1: /usr/include/c++/4.8.2/tuple: In member function ?void std::tuple<>::swap(std::tuple<>&)?: /usr/include/c++/4.8.2/tuple:515:12: internal compiler error: Segmentation fault void swap(tuple&) noexcept { /* no-op */ } ^ Please submit a full bug report, with preprocessed source if appropriate. See for instructions. Here's my problem. Note that odb doesn't crashes when I comment the line 'ListContainer *_friends;' in the Person class. I hope I made my problem clear, if not, feel free to ask more details. So, is it possible to make a templated custom container with ODB ? If it is, what did I miss ? Thanks in advance. Alexis MESTAG From boris at codesynthesis.com Mon Dec 16 03:28:17 2013 From: boris at codesynthesis.com (Boris Kolpackov) Date: Mon Dec 16 03:30:42 2013 Subject: [odb-users] Using Custom Container (with template) makes odb crash In-Reply-To: References: Message-ID: Hi Alexis, Alexis Mestag writes: > class Person > { > ... > > Friends *_friends; > }; > > class Friends > { > std::list *_elts; > }; Your wrapper approach is not exactly equivalent to the original version. If we "unwrap" it, we will get std::list** instead of std::list*. To me, it seems the equivalent will be: class Person { ... Friends _friends; }; > I implement the class odb::access::container_traits The problem is, container_traits should be specialized for a container. You are still specializing it for a pointer to a container. This won't work. Besides containers, ODB also has a notion of wrappers. That is, something that wraps or holds the underlying value. I think this will be more inline with what you are trying to do. For example, you can do something like this out of the box: class Person { ... std::unique_ptr> _friends; }; Because ODB includes a specialization of odb::warpper_traits for std::unique_ptr. While there is no default specialization for the raw pointer, you can add one yourself. In fact, the odb/wrapper-traits.hxx file on libodb contains a commented-out implementation that has the following comment: // Sample specialization for raw pointers. It is not enabled by default // since it makes many assumptions that may not always hold true (such // as that instances are allocated with new and freed with delete). // This makes it too dangerous to be enabled unconditionally. If you // need this functionality, you can copy the below code into your // application. Also consider changing it to only specialize for // specific types instead of for any pointer (it will almost always // do the wrong thing for char*). Boris