From boris at codesynthesis.com Sun May 1 10:32:07 2016 From: boris at codesynthesis.com (Boris Kolpackov) Date: Sun May 1 10:32:17 2016 Subject: [odb-users] Containers of containers not detected In-Reply-To: References: Message-ID: Hi Andrew, Andrew Cunningham writes: > It would be great if the ODB compiler could detect "containers of > containers" and throw an error. It does normally. In your case, you have a container of containers via a value type, which ODB doesn't detect. I've added an item to our bug list. > - Is the "container of containers" a hard limitation that will remain in > future versions of ODB? There are no plans to support this feature "out of the box" since the complexity will make the mapping incomprehensible for most users. What we will support is emulation of containers of containers. It will require quite a bit of work from your side but the benefit is that you will understand the (complexity) of the resulting schema (and can decide whether it is worth it). scm.codesynthesis.com/?p=odb/libodb.git;a=commit;h=ad515f85e807f8d21a1b70f5ed288705e0f2f531 > - Is the fact that using a BLOB makes the code work just blind good luck? No, if you map an inner vector to BLOB, then it is no longer a container in the ODB sense (i.e., it is not mapped to its own table). Boris From odb at a-cunningham.com Sun May 1 13:39:51 2016 From: odb at a-cunningham.com (Andrew Cunningham) Date: Sun May 1 13:40:04 2016 Subject: [odb-users] Containers of containers not detected In-Reply-To: References: Message-ID: Hi Boris, Ok, thanks for the explanation. I suspected that mapping a vector to a BLOB makes it "not a container" and is supported. So that brings up a problem I have found shown in the "reproducer" project I sent to you. When the std::vector/BLOB from my example is in a odd::section , it is not properly restored. The BLOB/vector is restored with the correct size, but the restored data is garbage. This only happens in the case as shown in my example, where the BLOB is part of an object that is a value of a std::map Andrew On Sun, May 1, 2016 at 7:32 AM, Boris Kolpackov wrote: > Hi Andrew, > > Andrew Cunningham writes: > > > It would be great if the ODB compiler could detect "containers of > > containers" and throw an error. > > It does normally. In your case, you have a container of containers > via a value type, which ODB doesn't detect. I've added an item to > our bug list. > > > > - Is the "container of containers" a hard limitation that will remain in > > future versions of ODB? > > There are no plans to support this feature "out of the box" since the > complexity will make the mapping incomprehensible for most users. > > What we will support is emulation of containers of containers. It will > require quite a bit of work from your side but the benefit is that you > will understand the (complexity) of the resulting schema (and can decide > whether it is worth it). > > > scm.codesynthesis.com/?p=odb/libodb.git;a=commit;h=ad515f85e807f8d21a1b70f5ed288705e0f2f531 > > > > - Is the fact that using a BLOB makes the code work just blind good luck? > > No, if you map an inner vector to BLOB, then it is no longer a container > in the ODB sense (i.e., it is not mapped to its own table). > > Boris > From boris at codesynthesis.com Mon May 2 04:54:58 2016 From: boris at codesynthesis.com (Boris Kolpackov) Date: Mon May 2 04:55:08 2016 Subject: [odb-users] Object loading view defined in a separate file: object_statements is not being instantiated In-Reply-To: References: Message-ID: Hi Aar?n, This is a bug, thanks for the resport! I've fixed it for the next release: http://scm.codesynthesis.com/?p=odb/odb.git;a=commit;h=83355694c8bd7a9aa9a222ae9d12274c4dab0bac I can build you a pre-release binary with the fix if you are interested. Boris From dieter.govaerts at bricsys.com Mon May 2 05:29:07 2016 From: dieter.govaerts at bricsys.com (Dieter Govaerts) Date: Mon May 2 05:29:13 2016 Subject: =?utf-8?Q?RE=3A_AW=3A_=5Bodb-users=5D_object=5Falready=5Fpersistent_excep?= =?utf-8?Q?tion_and_polymorphic_class?= In-Reply-To: <92102a8bfe104d86b28388e22b2f3cf1@QEX.qosmotec.com> References: <1461930912.192515761@apps.rackspace.com> <92102a8bfe104d86b28388e22b2f3cf1@QEX.qosmotec.com> Message-ID: <1462181347.247732038@apps.rackspace.com> Hi Marcel, > sounds like you catch the exception and then commit the transaction anyway? You > should not do that. If you do something like > > try > { > odb::transaction t(db.begin()); > > db.persist(new employee("John")); > db.persist(new employee("John")); > > t.commit(); > } > catch (const odb::exception& e) > { > std::cerr << e.what () << endl; > } > > then the transaction is rolled-back automatically because ODB's transaction class > conforms to the RAII principle. > This should solve your problem. Yes, you are right. What else do we need transactions for? I must have been asleep :-/. The problem was that I can not rollback the transaction. The operation is part of a greater whole which I do not have control over. I knew sqlite didn't support nested transactions but it runs out it has savepoints which can serve the same purpose. Problem solved. Thank you. Dieter From abv150ci at gmail.com Mon May 2 11:18:45 2016 From: abv150ci at gmail.com (=?UTF-8?Q?Aar=C3=B3n_Bueno_Villares?=) Date: Mon May 2 11:19:37 2016 Subject: [odb-users] Object loading view defined in a separate file: object_statements is not being instantiated In-Reply-To: References: Message-ID: Don't worry. I don't think I'll apply any patch or rebuild the libs, because I've installed it in some computers. I have solved it comparing a "working" generated-file with my not-working view-only file, and the only thing I had to do was to add the following ODB compiler option when generating the view-only file: --hxx-prologue "\#include " Thanks, 2016-05-02 10:54 GMT+02:00 Boris Kolpackov : > Hi Aar?n, > > This is a bug, thanks for the resport! I've fixed it for the next > release: > > > http://scm.codesynthesis.com/?p=odb/odb.git;a=commit;h=83355694c8bd7a9aa9a222ae9d12274c4dab0bac > > I can build you a pre-release binary with the fix if you are interested. > > Boris > From ellav at checkpoint.com Tue May 3 09:07:50 2016 From: ellav at checkpoint.com (Ella Vishnevsky) Date: Tue May 3 09:08:01 2016 Subject: [odb-users] table creation failure and odb log files Message-ID: <4E3D0839F36EF04D988AECF0CA558E15DAFF72FC@DAG-EX10.ad.checkpoint.com> Hey, I'm running odb compiler(version 2.1.1) from gcc compiler. My ODB makefile has 2 tables, that are mapped to the same schema name, for example: odbCompiler -d sqlite --generate-query --generate-schema --schema-name one person.h && cp person-odb.cxx person-odb.cpp odbCompiler -d sqlite --generate-query --generate-schema --schema-name one person2.h && cp person2-odb.cxx person2-odb.cpp I'm also compiling person.cpp, person2.cpp, person-odb.cpp and person2-odb.cpp. (static compilation) My problem is that only one table is being created when I run the following: odb::database *m_db_3 = new odb::sqlite::database("TEST",SQLITE_OPEN_READWRITE | SQLITE_OPEN_CREATE); odb::transaction t (m_db_3->begin ()); try{ m_db_3->query (false); //HERE IS THE PROBLEM } catch(const odb::exception& e) { odb::schema_catalog::create_schema (*m_db_3,"one"); } t.commit(); If I change from "m_db_3->query (false); " to " m_db_3->query (false);" -> both tables will be created. Can't figure out why. 1. Did anyone had this problem? 2. Are there any logs or data that I can get from the odb? (maybe the commands that are being executed or any other information that can help me) Thanks a lot From boris at codesynthesis.com Tue May 3 16:57:22 2016 From: boris at codesynthesis.com (Boris Kolpackov) Date: Tue May 3 16:57:33 2016 Subject: [odb-users] Object loading view defined in a separate file: object_statements is not being instantiated In-Reply-To: References: Message-ID: Hi Aar?n, Aar?n Bueno Villares writes: > --hxx-prologue "\#include " Yes, that's pretty clever. Boris From boris at codesynthesis.com Tue May 3 17:28:08 2016 From: boris at codesynthesis.com (Boris Kolpackov) Date: Tue May 3 17:28:20 2016 Subject: [odb-users] table creation failure and odb log files In-Reply-To: <4E3D0839F36EF04D988AECF0CA558E15DAFF72FC@DAG-EX10.ad.checkpoint.com> References: <4E3D0839F36EF04D988AECF0CA558E15DAFF72FC@DAG-EX10.ad.checkpoint.com> Message-ID: Hi Ella, Ella Vishnevsky writes: > I'm also compiling person.cpp, person2.cpp, person-odb.cpp and > person2-odb.cpp. (static compilation) > > If I change from "m_db_3->query (false); " to > " m_db_3->query (false);" -> both tables will be created. When you use static libraries (I assume that's what you mean by "static compilation") only object files that are "used" are added to the resulting executable. And by "used" I mean there is one or more symbols in the executable that are satisified by the object file. See this thread for more information and potential solutions: http://www.codesynthesis.com/pipermail/odb-users/2013-May/001286.html Boris From boris at codesynthesis.com Wed May 4 13:37:42 2016 From: boris at codesynthesis.com (Boris Kolpackov) Date: Wed May 4 13:37:54 2016 Subject: [odb-users] Problem with session cache and weak_ptr In-Reply-To: References: <96d8d11a4c124466b9271f85f0dcdb5e@QEX.qosmotec.com> Message-ID: Hi Marcel, Thanks for the test case. While I am not sure this is the same situation as in your original case, but I can explain what's going on here: in this test you invalidate the weak pointer from employees to employers but the employee objects still remain in the cache. When you load them again, ODB first checks the cache and finds them there. In this case ODB assumes that the object in cache is valid/fully loaded and simply returns it. In particular it doesn't try to re-validate/re-load it in any way. Boris From mne at qosmotec.com Mon May 9 06:03:13 2016 From: mne at qosmotec.com (Marcel Nehring) Date: Mon May 9 06:03:23 2016 Subject: AW: [odb-users] Problem with session cache and weak_ptr In-Reply-To: References: <96d8d11a4c124466b9271f85f0dcdb5e@QEX.qosmotec.com> Message-ID: <8449ca0fd5fc487b8a9440690d6bc3c6@QEX.qosmotec.com> Hi Boris, Thanks for having a look! I can understand that you argue that it is expected behavior from ODB's point of view. I cannot explain to my colleagues, however, that our database access layer returns invalid objects. ;) In the meantime I addressed the issue with a similar solution to Andrew Cunningham's auto-loading lazy pointer. I changed all weak pointer to lazy pointer and automatically load the pointed to object when it is accessed in case the pointer is invalid/expired. So far this works and is fast enough. Regards, Marcel From odb at a-cunningham.com Mon May 9 12:48:40 2016 From: odb at a-cunningham.com (Andrew Cunningham) Date: Mon May 9 12:48:52 2016 Subject: [odb-users] Bug Message-ID: > > When the std::vector/BLOB from my example is in a odd::section , it is not > properly restored. > > The BLOB/vector is restored with the correct size, but the restored data > is garbage. > > This only happens in the case as shown in my example, where the BLOB is > part of an object that is a value of a std::map > Just FYI to the list, Boris was able to nail down this issue and correct it in 2.5.0a7. From odb at a-cunningham.com Mon May 9 18:04:26 2016 From: odb at a-cunningham.com (Andrew Cunningham) Date: Mon May 9 18:04:39 2016 Subject: [odb-users] Queries not working as expected with large numbers of objects Message-ID: Hi Boris, I am executing a couple of simple queries on a class of objects on a simple,non-indexed "integer" member odb::query q = odb::query::useCnt == 1; and odb::query q = odb::query::useCnt > 1; Works perfectly when the number of objects is , say, n=1000 However, I am seeing some incorrect behavior when querying large numbers of objects. For example, when the number of objects that might meet the search criteria is >300,000 the "useCnt == 1" query is returning objects with a useCnt=4(!) , for example, while the "useCnt > 1" query is returning 0 objects in it's result. This is 100% repeatable. ODB 2.4.0 /SQLite 3.12.2 From mne at qosmotec.com Tue May 10 12:17:15 2016 From: mne at qosmotec.com (Marcel Nehring) Date: Tue May 10 12:17:47 2016 Subject: AW: [odb-users] Typos in documentation In-Reply-To: References: Message-ID: <8955d1d0680b4d79930a742b07cae33f@QEX.qosmotec.com> Hi Boris, I found a typo: 6.4 Lazy Pointers, page 114: "A a result, when object relationships are involved, a simple transaction like the above can load many more objects than is necessary." I think it should be "As a result,..." Regards, Marcel From mne at qosmotec.com Tue May 10 12:46:51 2016 From: mne at qosmotec.com (Marcel Nehring) Date: Tue May 10 12:47:01 2016 Subject: AW: [odb-users] Problem with session cache and weak_ptr In-Reply-To: <8449ca0fd5fc487b8a9440690d6bc3c6@QEX.qosmotec.com> References: <96d8d11a4c124466b9271f85f0dcdb5e@QEX.qosmotec.com> <8449ca0fd5fc487b8a9440690d6bc3c6@QEX.qosmotec.com> Message-ID: <00c73cb1e87643e9961f94d45ea5ea1e@QEX.qosmotec.com> Hi, seems like my solution does not work. When persisting new objects my lazy weak pointer referencing them do not get updated. If the pointer expires I am unable to reload the object since the lazy pointer thinks it points to a transient object. Is this expected behavior? Regards, Marcel From boris at codesynthesis.com Tue May 10 19:22:40 2016 From: boris at codesynthesis.com (Boris Kolpackov) Date: Tue May 10 19:22:45 2016 Subject: [odb-users] Typos in documentation In-Reply-To: <8955d1d0680b4d79930a742b07cae33f@QEX.qosmotec.com> References: <8955d1d0680b4d79930a742b07cae33f@QEX.qosmotec.com> Message-ID: Hi Marcel, Marcel Nehring writes: > I found a typo: [...] Fixed, thanks for the report! Boris From boris at codesynthesis.com Tue May 10 19:32:45 2016 From: boris at codesynthesis.com (Boris Kolpackov) Date: Tue May 10 19:32:50 2016 Subject: [odb-users] Problem with session cache and weak_ptr In-Reply-To: <00c73cb1e87643e9961f94d45ea5ea1e@QEX.qosmotec.com> References: <96d8d11a4c124466b9271f85f0dcdb5e@QEX.qosmotec.com> <8449ca0fd5fc487b8a9440690d6bc3c6@QEX.qosmotec.com> <00c73cb1e87643e9961f94d45ea5ea1e@QEX.qosmotec.com> Message-ID: Hi Marcel, Marcel Nehring writes: > When persisting new objects my lazy weak pointer referencing them do > not get updated. If the pointer expires I am unable to reload the > object since the lazy pointer thinks it points to a transient object. > Is this expected behavior? How exactly (and from which state) does your lazy weak pointer expires? If it was pointing to a persistent object (loaded or not), unless it is reset, it should still be pointing to a persistent object. Try also to unload() the expired pointer before attempting to load() it. Boris From boris at codesynthesis.com Tue May 10 19:35:49 2016 From: boris at codesynthesis.com (Boris Kolpackov) Date: Tue May 10 19:35:53 2016 Subject: [odb-users] Queries not working as expected with large numbers of objects In-Reply-To: References: Message-ID: Hi Andrew, Andrew Cunningham writes: > This is 100% repeatable. I could take a look if you can send a minimal (i.e. the persistent class plus main()), reproducible test case. Boris From odb at a-cunningham.com Tue May 10 20:24:53 2016 From: odb at a-cunningham.com (Andrew Cunningham) Date: Tue May 10 20:25:05 2016 Subject: [odb-users] Queries not working as expected with large numbers of objects In-Reply-To: References: Message-ID: I tried... sadly in a simple example it works as expected. I will have to turn tracing on to see what is happening. On Tue, May 10, 2016 at 4:35 PM, Boris Kolpackov wrote: > Hi Andrew, > > Andrew Cunningham writes: > > > This is 100% repeatable. > > I could take a look if you can send a minimal (i.e. the persistent > class plus main()), reproducible test case. > > Boris > From mne at qosmotec.com Wed May 11 03:25:19 2016 From: mne at qosmotec.com (Marcel Nehring) Date: Wed May 11 03:25:30 2016 Subject: AW: [odb-users] Problem with session cache and weak_ptr In-Reply-To: References: <96d8d11a4c124466b9271f85f0dcdb5e@QEX.qosmotec.com> <8449ca0fd5fc487b8a9440690d6bc3c6@QEX.qosmotec.com> <00c73cb1e87643e9961f94d45ea5ea1e@QEX.qosmotec.com> Message-ID: Hi Boris, thanks for your quick response. What happens is the following: 1) The lazy weak pointer gets initialized to a transient object. 2) The transient object gets persisted. 3) The lazy weak pointer expires. 4) A call to loaded() returns true while a call to get_eager() returns an empty/expired pointer. According to the manual this means the lazy pointer is a "NULL pointer to transient object". I guessed that the problem is that the lazy weak pointer does not get informed that the object it points to changed from transient to persisted state. Regards, Marcel From mne at qosmotec.com Wed May 11 06:52:34 2016 From: mne at qosmotec.com (Marcel Nehring) Date: Wed May 11 06:52:44 2016 Subject: AW: [odb-users] Problem with session cache and weak_ptr In-Reply-To: References: <96d8d11a4c124466b9271f85f0dcdb5e@QEX.qosmotec.com> <8449ca0fd5fc487b8a9440690d6bc3c6@QEX.qosmotec.com> <00c73cb1e87643e9961f94d45ea5ea1e@QEX.qosmotec.com> Message-ID: <1965057559504f13b51a9e35554385b3@QEX.qosmotec.com> Hi Boris, I investigated this problem a bit more and have to change my description a bit. I was not aware of the fact that a simple assignment to a lazy pointer from its eager counterpart is not sufficient (maybe we could add a corresponding paragraph to the manual?). When I use the reset method instead and provide both, the eager pointer and the odb::database instance the observable behavior slightly changes: 1) The lazy weak pointer gets reset to a transient object. 2) The transient object gets persisted. 3) The lazy weak pointer expires. 4) A call to loaded() returns false while a call to get_eager() returns an empty/expired pointer. According to the manual this means the lazy pointer is an "unloaded pointer to persistent object". Trying to load it, however, fails since the database id stored inside the lazy weak pointer was not updated and thus load() results in an "object not persistent" exception being thrown. So I still guess the problem is that the lazy weak pointer does not get informed that the object it points to changed from transient to persisted state. Another question, rather out of curiosity. Why does a lazy pointer need to know the database? Since we need to be inside a transaction when calling load couldn't we get it from there? Regards, Marcel From abodrin at gmail.com Thu May 12 11:53:58 2016 From: abodrin at gmail.com (=?koi8-r?B?4dLUo80g4s/E0snO?=) Date: Thu May 12 14:34:46 2016 Subject: [odb-users] Composite value object id Message-ID: <3F01549F-B2A3-4DBE-B44F-0CE883E49B4A@gmail.com> Chapter 14.4.1 id claims that "id specifier cannot be used for data members of composite value types or views". But we have a chapter 7.2.1 Composite Object Ids, where first sentence claims opposite. Is this errors in a doc, or I misunderstood something? Regards, Artem Bodrin From boris at codesynthesis.com Thu May 12 19:29:04 2016 From: boris at codesynthesis.com (Boris Kolpackov) Date: Thu May 12 19:29:16 2016 Subject: [odb-users] Composite value object id In-Reply-To: <3F01549F-B2A3-4DBE-B44F-0CE883E49B4A@gmail.com> References: <3F01549F-B2A3-4DBE-B44F-0CE883E49B4A@gmail.com> Message-ID: Hi Artem, ????? ?????? writes: > I misunderstood something? Yes. You cannot make a member inside a composite value type an object id but you can make a member inside an object which is of a composite value type an object id. #pragma db value struct point { #pragma db id // error int x; int y; }; #pragma db value struct circle { #pragma db id // ok point center; }; See also this commit for some upcoming enhancements in this area: http://scm.codesynthesis.com/?p=odb/odb.git;a=commit;h=80b868be1e7c249daa714b0c7a5f87694edb8664 Boris From boris at codesynthesis.com Thu May 12 19:49:24 2016 From: boris at codesynthesis.com (Boris Kolpackov) Date: Thu May 12 19:49:35 2016 Subject: [odb-users] Problem with session cache and weak_ptr In-Reply-To: <1965057559504f13b51a9e35554385b3@QEX.qosmotec.com> References: <96d8d11a4c124466b9271f85f0dcdb5e@QEX.qosmotec.com> <8449ca0fd5fc487b8a9440690d6bc3c6@QEX.qosmotec.com> <00c73cb1e87643e9961f94d45ea5ea1e@QEX.qosmotec.com> <1965057559504f13b51a9e35554385b3@QEX.qosmotec.com> Message-ID: Hi Marcel, Marcel Nehring writes: > I was not aware of the fact that a simple assignment to a lazy pointer > from its eager counterpart is not sufficient (maybe we could add a > corresponding paragraph to the manual?). Added this paragraph: "Note that to initialize a lazy pointer to a persistent object from its eager pointer one must use the constructor or reset() function with the database as its first argument. The database is required to support comparison of unloaded lazy pointers to persistent objects." > Trying to load it, however, fails since the database id stored inside the > lazy weak pointer was not updated and thus load() results in an "object > not persistent" exception being thrown. > > So I still guess the problem is that the lazy weak pointer does not get > informed that the object it points to changed from transient to persisted > state. Yes, there is no magic in ODB ;-) In a sense you are violating the interface: you are saying (by calling reset() with the database) that this object is persistent (and thus has a valid object id) when in reality this is not the case. The fix would be to first persist the object and then assign it to the lazy pointer. Boris From luisagiacomini.eu at gmail.com Wed May 18 02:44:32 2016 From: luisagiacomini.eu at gmail.com (Luisa Giacomini) Date: Wed May 18 08:56:25 2016 Subject: [odb-users] Behaviour of PRAGMA busy_timeout on different platforms Message-ID: Dear Boris, we are using odb 2.3 with sqlite and we are trying to write from more than one writer on the same db (we know the sqlite is not exctly designed for the task). If we do nothing, some of the data to be written are just discarded, in the aim of avoinding that we applied a timeout to the various writers via the PRAGMA busy_timout=N with N up to 30 seconds. Every writer opens the db, sets the pragma and starts a loop persisting 10000 new records each. At this point we discovered a different behaviour on our to reference platforms: A. Windows 8.1 64 bit Pro B. Centos 6.5 x86_64 On (A) the persist operation suspends itself for up to N seconds if the db is locked; if the db is not yet available after the time out elapsed, is raised the exception "database operation timeout". On (B) the persist operation does not wait and exits immediately with the odb::core::exception "database operation timeout". So the question is why? The busy_timeout PRAGMA does not work on linux? Thanks in advance, Luisa Giacomini. From boris at codesynthesis.com Wed May 18 11:14:52 2016 From: boris at codesynthesis.com (Boris Kolpackov) Date: Wed May 18 11:14:59 2016 Subject: [odb-users] Behaviour of PRAGMA busy_timeout on different platforms In-Reply-To: References: Message-ID: Hi Luisa, Luisa Giacomini writes: > A. Windows 8.1 64 bit Pro > B. Centos 6.5 x86_64 > > [...] > > So the question is why? The busy_timeout PRAGMA does not work on linux? We haven't encountered this issue before, so I am only speculating here. My first guess would be that it is version specific. CentOS probably has a very old version of SQLite. So the first thing to try is to compile (or upgrade to) the latest and see if there is any change. Other than that, I found the following discussion which may be relevant: http://www.perlmonks.org/?node_id=1079811 If none of this helps, then the next step should probably be a post to the SQLite mailing list seeing that this appears to be an SQLite issue. Boris From abodrin at gmail.com Sat May 21 07:10:36 2016 From: abodrin at gmail.com (=?UTF-8?B?0JDRgNGC0ZHQvCDQkdC+0LTRgNC40L0=?=) Date: Sat May 21 10:05:43 2016 Subject: [odb-users] Reuse inheritance and id column names Message-ID: Greetings, developers 8-) I've encountered a problem with subject, when tried to reflect odb-ready classes onto existing database tables. Consider a small test: reflection.h with contents: #pragma once #include class CommonBase { public: QUuid id; QUuid class_id; }; #ifdef ODB_COMPILER #pragma db object( CommonBase ) abstract #endif class Object : public CommonBase { public: quint32 num1; }; #ifdef ODB_COMPILER #pragma db object( Object ) table( "object" ) #pragma db member( Object::id ) column( "id" ) id #pragma db member( Object::class_id ) column( "class_id" ) #endif class Extension : public CommonBase { public: quint32 num2; }; #ifdef ODB_COMPILER #pragma db object( Extension ) table( "extension" ) #pragma db member( Extension::id ) column( "object_id" ) id #pragma db member( Extension::class_id ) column( "object_class_id" ) #endif processed by odb compiler: /opt/odb-2.4.0/bin/odb -I/opt/Qt5.3.0/5.3/gcc_64/include/QtCore -I/opt/Qt5.3.0/5.3/gcc_64/include/ -d pgsql --generate-query --generate-schema --profile qt reflection.h and produced a following sql file with schema: /* This file was generated by ODB, object-relational mapping (ORM) * compiler for C++. */ DROP TABLE IF EXISTS "extension" CASCADE; DROP TABLE IF EXISTS "object" CASCADE; CREATE TABLE "object" ( "object_id" UUID NOT NULL PRIMARY KEY, "object_class_id" UUID NULL, "num1" INTEGER NOT NULL); CREATE TABLE "extension" ( "object_id" UUID NOT NULL PRIMARY KEY, "object_class_id" UUID NULL, "num2" INTEGER NOT NULL); everything seems fine and simple, except column names for table "objects". I've expected "id" an "class_id" respectively as defined by pragmas... Is this an odb-compiler bug, or i must do something else to meet my needs? Thanks in advance, Artem. From boris at codesynthesis.com Sun May 22 20:08:35 2016 From: boris at codesynthesis.com (Boris Kolpackov) Date: Sun May 22 20:08:38 2016 Subject: [odb-users] Reuse inheritance and id column names In-Reply-To: References: Message-ID: Hi Artem, ????? ?????? writes: > Is this an odb-compiler bug, or i must do something else to meet my needs? It's what we call a "limitation", a bug that will be very hard to fix and which we probably won't do ;-). The problem has to do with the way all the pragma values are saved: in this case the column values are saved in the data member nodes. And since the two derived classes inherit the same data member, we get this override behavior. There is a fairly easy, if a bit messy, workaround. Here is the revised version of your example (I replaced Qt types with int's for testing): class CommonBase { public: int id; int class_id; }; class Object : public CommonBase { public: int num1; }; #ifdef ODB_COMPILER #pragma db object( Object ) table( "object" ) #pragma db member( Object::id_ ) virtual (int) access(id) column( "id" ) id #pragma db member( Object::class_id_ ) virtual (int) access(class_id) column( "class_id" ) #endif class Extension : public CommonBase { public: int num2; }; #ifdef ODB_COMPILER #pragma db object( Extension ) table( "extension" ) #pragma db member( Extension::id_ ) virtual(int) access (id) column( "object_id" ) id #pragma db member( Extension::class_id_ ) virtual(int) access (class_id) column( "object_class_id" ) #endif The idea is to make CommonBase transient and then use virtual data members feature to make them persistent with different column names in each derived case. As a side note, this change actually makes quite a bit of sense, conceptually: since you map CommonBase to the database differently in each derived class, it is not really a persistent object, in ODB sense. Rather, it's just a group of common data members. With this change you get the schema that you expect, almost. The only drawback of this approach is that the *id columns will come after the num* columns. If you don't like that (and don't want to move the member pragmas into the class body), then you will need the 2.5.0 pre-release which support the before/after pragmas: #pragma db member( Object::id_ ) virtual(int) after ... // Means first. #pragma db member( Object::class_id_ ) virtual(int) after(Object::id_) ... Boris From mne at qosmotec.com Mon May 23 06:46:17 2016 From: mne at qosmotec.com (Marcel Nehring) Date: Mon May 23 06:46:27 2016 Subject: AW: [odb-users] Problem with session cache and weak_ptr In-Reply-To: References: <96d8d11a4c124466b9271f85f0dcdb5e@QEX.qosmotec.com> <8449ca0fd5fc487b8a9440690d6bc3c6@QEX.qosmotec.com> <00c73cb1e87643e9961f94d45ea5ea1e@QEX.qosmotec.com> <1965057559504f13b51a9e35554385b3@QEX.qosmotec.com> Message-ID: <1ec711815e80442898bd66822896e2e8@QEX.qosmotec.com> Hi Boris, so a lazy pointer is meant to store a transient object (if no database object was provided) and a persistent object (if a database object was provided) and handle the differentiation internally? So if persisting the object before assigning it (as you suggested) is not an option, one could later reset it or update the ID? Is this the expected usage? Regards, Marcel From henning.becker at apworks.de Sun May 22 14:12:18 2016 From: henning.becker at apworks.de (Henning Becker) Date: Mon May 23 10:15:24 2016 Subject: [odb-users] Nested Vectors of Composite Values Message-ID: <1893534.cfvexKPs7z@tegilbor.lan> Hello everybody, I'm trying to use the following setup of classes (stripped down to a simple example). classes.h: #pragma db value class A { std::string first; std::string second; friend class odb::access; }; #pragma db value class B { std::string hello; std::vector a; friend class odb::access; }; #pragma db object class C { #pragma db id std::string name; std::vector b; friend class odb::access; }; And I run the following to command, just to generate the SQL database schema: # odb --database sqlite --generate-schema-only --schema-format sql classes.h I would have expected, that three tables were generated in classes.sql: - C - C_b - C_b_a But actually, I get only these two: CREATE TABLE "C" ( "name" TEXT NOT NULL PRIMARY KEY); CREATE TABLE "C_b" ( "object_id" TEXT NOT NULL, "index" INTEGER NOT NULL, "value_hello" TEXT NOT NULL, CONSTRAINT "object_id_fk" FOREIGN KEY ("object_id") REFERENCES "C" ("name") ON DELETE CASCADE); What am I doing wrong? What am I missing? Any ideas? Thanks, Henning -- _______________________________________ Henning Becker Development Engineer AIRBUS APWORKS GmbH Willy-Messerschmitt-Str. 1 82024 Taufkirchen - Germany T: +49 89 60729771 F: +49 89 60728239 M: +49 174 9818097 henning.becker@apworks.de AIRBUS APWORKS GmbH Registered Office: Ottobrunn District Court of Munich: HRB 141734 Managing Director: Joachim Zettler Internet: www.apworks.de _______________________________________ From abodrin at gmail.com Mon May 23 03:51:53 2016 From: abodrin at gmail.com (=?koi8-r?B?4dLUo80g4s/E0snO?=) Date: Mon May 23 10:18:29 2016 Subject: [odb-users] Reuse inheritance and id column names In-Reply-To: References: Message-ID: Good morning, Boris >> Is this an odb-compiler bug, or i must do something else to meet my needs? > > It's what we call a "limitation", a bug that will be very hard to fix > and which we probably won't do ;-). A very, very familiar explanation ;-)) As for workaround: it's good for me, and for most db developers around, i think. Good code mostly doesn't rely on actual order of columns in tables, as i see it. Huge load of thanks to you and your team, great work! 8-) By the way, do you think this "limitation" worth to be described in docs, or some kind of FAQ, for future? Regards, Artem Bodrin. From boris at codesynthesis.com Mon May 23 22:36:06 2016 From: boris at codesynthesis.com (Boris Kolpackov) Date: Mon May 23 22:36:08 2016 Subject: [odb-users] Reuse inheritance and id column names In-Reply-To: References: Message-ID: Hi Artem, ????? ?????? writes: > Huge load of thanks to you and your team, great work! 8-) Thanks, I am glad you are enjoying it. > By the way, do you think this "limitation" worth to be described in > docs, or some kind of FAQ, for future? I think the mailing lists post (which is archived and google-searchable) is sufficient. It is quite rare that one wants to map columns of a base class differently in the derived classes. Plus, people are starting to complain that the manual is too big ;-). Boris From boris at codesynthesis.com Mon May 23 22:39:25 2016 From: boris at codesynthesis.com (Boris Kolpackov) Date: Mon May 23 22:39:28 2016 Subject: [odb-users] Nested Vectors of Composite Values In-Reply-To: <1893534.cfvexKPs7z@tegilbor.lan> References: <1893534.cfvexKPs7z@tegilbor.lan> Message-ID: Hi Henning, Containers of containers are not supported in ODB. Normally this is diagnosed but the case where it is done via a composite value is not yet handled. See this earlier post for more information (as well as what can be done if you really need it): http://www.codesynthesis.com/pipermail/odb-users/2016-May/003240.html Boris From henning.becker at apworks.de Tue May 24 02:30:58 2016 From: henning.becker at apworks.de (Henning Becker) Date: Tue May 24 02:31:12 2016 Subject: [odb-users] Nested Vectors of Composite Values In-Reply-To: References: <1893534.cfvexKPs7z@tegilbor.lan> Message-ID: <3519759.EC7OVnMpNR@tegilbor.lan> Am Dienstag, 24. Mai 2016, 02:39:25 CEST schrieben Sie: > Hi Henning, > > Containers of containers are not supported in ODB. Normally this is > diagnosed but the case where it is done via a composite value is > not yet handled. See this earlier post for more information (as well > as what can be done if you really need it): > > http://www.codesynthesis.com/pipermail/odb-users/2016-May/003240.html > > Boris > Hi Boris, thanks for your quick answer. I will try to model my data structures in a different way to avoid this limitation. Cheers, Henning -- _______________________________________ Henning Becker Development Engineer AIRBUS APWORKS GmbH Willy-Messerschmitt-Str. 1 82024 Taufkirchen - Germany T: +49 89 60729771 F: +49 89 60728239 M: +49 174 9818097 henning.becker@apworks.de AIRBUS APWORKS GmbH Registered Office: Ottobrunn District Court of Munich: HRB 141734 Managing Director: Joachim Zettler Internet: www.apworks.de _______________________________________ From Steve.Hales at garmin.com Mon May 23 18:25:23 2016 From: Steve.Hales at garmin.com (Hales, Steve) Date: Tue May 24 15:15:52 2016 Subject: [odb-users] odb::timeout on sqlite Message-ID: My team is developing an iOS app using ODB 2.4.0 on a sqlite3 database. Our app has a number of background processes that access the database from multiple threads. Occasionally, our app receives an odb::timeout exception. I looked in the ODB code and found that this exception might be thrown as a result of a SQLITE_LOCKED or SQLITE_BUSY error. It is my limited understanding that this may be caused by multithreaded access to the database. Can you provide any guidance on how to debug this problem? Thanks, Steve ________________________________ CONFIDENTIALITY NOTICE: This email and any attachments are for the sole use of the intended recipient(s) and contain information that may be Garmin confidential and/or Garmin legally privileged. If you have received this email in error, please notify the sender by reply email and delete the message. Any disclosure, copying, distribution or use of this communication (including attachments) by someone other than the intended recipient is prohibited. Thank you. From boris at codesynthesis.com Tue May 24 19:54:56 2016 From: boris at codesynthesis.com (Boris Kolpackov) Date: Tue May 24 19:55:07 2016 Subject: [odb-users] odb::timeout on sqlite In-Reply-To: References: Message-ID: Hi Steve, Hales, Steve writes: > My team is developing an iOS app using ODB 2.4.0 on a sqlite3 database. > Our app has a number of background processes that access the database > from multiple threads. By "processes" you don't mean actual operating system processes, correct? In other words, you have a single application (process) that runs multiple threads. > Occasionally, our app receives an odb::timeout exception. I looked in > the ODB code and found that this exception might be thrown as a result > of a SQLITE_LOCKED or SQLITE_BUSY error. It is my limited understanding > that this may be caused by multithreaded access to the database. Can > you provide any guidance on how to debug this problem? Quoting the "Requirements" sections from libodb-sqlite's INSTALL file: "If you plan to access an SQLite database from multiple threads, then you will need SQLite version 3.5.0 or later built with the unlock notify feature (SQLITE_ENABLE_UNLOCK_NOTIFY) enabled." My guess would be the stock iOS SQLite is built without this feature. Normally, in this sutuation, one would use a custom build of SQLite. This earlier post has more details: http://www.codesynthesis.com/pipermail/odb-users/2014-November/002239.html Boris From odb at a-cunningham.com Wed May 25 12:32:37 2016 From: odb at a-cunningham.com (Andrew Cunningham) Date: Wed May 25 12:32:50 2016 Subject: [odb-users] Re: odb::timeout on sqlite Message-ID: What I do is use the SQLite "amalgamation" of sqlite.c and embed that in my build of libodb-sqlite so there is no confusion about what version of SQLite I am using and what options are active. > Hales, Steve writes: > > > My team is developing an iOS app using ODB 2.4.0 on a sqlite3 database. > > Our app has a number of background processes that access the database > > from multiple threads. > > By "processes" you don't mean actual operating system processes, correct? > In other words, you have a single application (process) that runs multiple > threads. > > > > Occasionally, our app receives an odb::timeout exception. I looked in > > the ODB code and found that this exception might be thrown as a result > > of a SQLITE_LOCKED or SQLITE_BUSY error. It is my limited understanding > > that this may be caused by multithreaded access to the database. Can > > you provide any guidance on how to debug this problem? > > Quoting the "Requirements" sections from libodb-sqlite's INSTALL file: > > "If you plan to access an SQLite database from multiple threads, then > you will need SQLite version 3.5.0 or later built with the unlock notify > feature (SQLITE_ENABLE_UNLOCK_NOTIFY) enabled." > > My guess would be the stock iOS SQLite is built without this feature. > Normally, in this sutuation, one would use a custom build of SQLite. > This earlier post has more details: > > http://www.codesynthesis.com/pipermail/odb-users/2014-November/002239.html > > Boris > > From boris at codesynthesis.com Wed May 25 19:54:45 2016 From: boris at codesynthesis.com (Boris Kolpackov) Date: Wed May 25 19:54:55 2016 Subject: [odb-users] Problem with session cache and weak_ptr In-Reply-To: <1ec711815e80442898bd66822896e2e8@QEX.qosmotec.com> References: <8449ca0fd5fc487b8a9440690d6bc3c6@QEX.qosmotec.com> <00c73cb1e87643e9961f94d45ea5ea1e@QEX.qosmotec.com> <1965057559504f13b51a9e35554385b3@QEX.qosmotec.com> <1ec711815e80442898bd66822896e2e8@QEX.qosmotec.com> Message-ID: Hi Marcel, Marcel Nehring writes: > so a lazy pointer is meant to store a transient object (if no database > object was provided) and a persistent object (if a database object was > provided) and handle the differentiation internally? I am not sure what you mean by "handle the differentiation". A lazy pointer is essentially an eager pointer plus the {id,db} pair which can be NULL. If the pair is NULL, then the pointer is transient. > So if persisting the object before assigning it (as you suggested) > is not a option, one could later reset it or update the ID? Is this > the expected usage? I don't think you can update the ID directly. But resetting it, yes, that would force the ID re-query. Boris From martin at mu-schneider.de Sat May 28 10:23:05 2016 From: martin at mu-schneider.de (Martin Schneider) Date: Sun May 29 17:01:46 2016 Subject: [odb-users] Linking problem at Ubuntu 16.04 Message-ID: <5749A9C9.2010602@mu-schneider.de> Hi, I've switched to Ubuntu 16.04 and get some strange problems when linking my old odb programs. After this I tried the examples from odb-tests-2.4.0 and get the same error. Running following commands gives > ./configure --with-database=mysql > make ... make[4]: Verzeichnis ?/home/martin/projects/odb/odb-tests-2.4.0/common/access? wird betreten /bin/bash ../../libtool --tag=CXX --mode=link g++ -g -O2 -D_REENTRANT -o driver driver.o test-odb.o ../../libcommon/common/libcommon.la -lodb-mysql -lodb-qt -lodb-boost -lboost_date_time -lboost_system -lodb -lpthread libtool: link: g++ -g -O2 -D_REENTRANT -o .libs/driver driver.o test-odb.o ../../libcommon/common/.libs/libcommon.so -lodb-mysql -lodb-qt -lodb-boost -lboost_date_time -lboost_system -lodb -lpthread /usr/lib/gcc/x86_64-linux-gnu/5/../../../x86_64-linux-gnu/libodb-mysql.so: undefined reference to `odb::statement::process_insert(char const*, void const* const*, unsigned long, unsigned long, char, std::__cxx11::basic_string, std::allocator >&)' /usr/lib/gcc/x86_64-linux-gnu/5/../../../x86_64-linux-gnu/libodb-mysql.so: undefined reference to `odb::statement::process_update(char const*, void const* const*, unsigned long, unsigned long, char, std::__cxx11::basic_string, std::allocator >&)' /usr/lib/gcc/x86_64-linux-gnu/5/../../../x86_64-linux-gnu/libodb-mysql.so: undefined reference to `odb::statement::process_select(char const*, void const* const*, unsigned long, unsigned long, char, char, bool, std::__cxx11::basic_string, std::allocator >&, bool)' collect2: error: ld returned 1 exit status Makefile:343: die Regel f?r Ziel ?driver? scheiterte ... Following odb libs are installed: martin@pcmartin:~/projects/odb/odb-tests-2.4.0$ ll /usr/lib/x86_64-linux-gnu/libodb* -rw-r--r-- 1 root root 142048 Mai 25 2015 libodb-2.4.so -rw-r--r-- 1 root root 341234 Mai 25 2015 libodb.a -rw-r--r-- 1 root root 10408 Mai 27 2015 libodb-boost-2.4.so -rw-r--r-- 1 root root 12754 Mai 27 2015 libodb-boost.a lrwxrwxrwx 1 root root 19 Mai 27 2015 libodb-boost.so -> libodb-boost-2.4.so -rw-r--r-- 1 root root 171232 Apr 5 17:18 libodb-mysql-2.4.so -rw-r--r-- 1 root root 374774 Apr 5 17:18 libodb-mysql.a lrwxrwxrwx 1 root root 19 Apr 5 17:18 libodb-mysql.so -> libodb-mysql-2.4.so -rw-r--r-- 1 root root 10408 Jul 5 2015 libodb-qt-2.4.so -rw-r--r-- 1 root root 10318 Jul 5 2015 libodb-qt.a lrwxrwxrwx 1 root root 16 Jul 5 2015 libodb-qt.so -> libodb-qt-2.4.so lrwxrwxrwx 1 root root 13 Mai 25 2015 libodb.so -> libodb-2.4.so installed by: sudo apt-get install libodb-dev libodb-mysql-dev libodb-boost-dev libodb-qt-dev Any idea where my mistake is? Thanks Martin From boris at codesynthesis.com Sun May 29 21:25:27 2016 From: boris at codesynthesis.com (Boris Kolpackov) Date: Sun May 29 21:25:41 2016 Subject: [odb-users] Linking problem at Ubuntu 16.04 In-Reply-To: <5749A9C9.2010602@mu-schneider.de> References: <5749A9C9.2010602@mu-schneider.de> Message-ID: Hi Martin, Martin Schneider writes: > ./configure --with-database=mysql > > [...] > > /usr/lib/gcc/x86_64-linux-gnu/5/../../../x86_64-linux-gnu/libodb-mysql.so: > undefined reference to `odb::statement::process_insert(char const*, > void const* const*, unsigned long, unsigned long, char, > std::__cxx11::basic_string, > std::allocator >&)' > /usr/lib/gcc/x86_64-linux-gnu/5/../../../x86_64-linux-gnu/libodb-mysql.so: > undefined reference to `odb::statement::process_update(char const*, > void const* const*, unsigned long, unsigned long, char, > std::__cxx11::basic_string, > std::allocator >&)' > /usr/lib/gcc/x86_64-linux-gnu/5/../../../x86_64-linux-gnu/libodb-mysql.so: > undefined reference to `odb::statement::process_select(char const*, > void const* const*, unsigned long, unsigned long, char, char, bool, > std::__cxx11::basic_string, > std::allocator >&, bool)' > > [...] > > installed by: > sudo apt-get install libodb-dev libodb-mysql-dev libodb-boost-dev > libodb-qt-dev Hm, looking at those 'std::__cxx11::basic_string' my suspicion is that there is a C++98/C++11 mismatch. Normally, with libstdc++, a library that was compiled with C++98 can be used with C++11. However, I am not sure if the other way around also works, my guess would be it does not. And it looks like libodb-mysql was compiled in the C++11 mode while libodb was not. You could try to configure your tests in C++11 though I am not sure it will make any difference (it is the way libodb-mysql is build that is the problem): ./configure --with-database=mysql CXXFLAGS=-std=c++11 I think we should dig into the libodb-mysql package and/or contact its maintainer with this information. Boris From adanesh at noornet.net Mon May 30 05:56:52 2016 From: adanesh at noornet.net (=?utf-8?B?2LnZhNuMINiv2KfZhti0?=) Date: Mon May 30 05:56:53 2016 Subject: [odb-users] Nested Select Query Message-ID: <1464602212318.25733@noornet.net> Hi Boris! Does ODB support nested select query? For example: SELECT name FROM world WHERE population > (SELECT population FROM world WHERE name='Romania') In my case ? the nested select is a view like this: #pragma db view object(FacetIndexDocument) object(FacetIndexFieldValue) query((?) + "GROUP BY" + FacetIndexDocument::m_fieldName + "," + FacetIndexDocument::m_fieldValue) struct FacetIndexFieldValueCountView { int m_fieldName; //odb::lazy_shared_ptr m_fieldName; QString m_value; #pragma db column("count(" + FacetIndexDocument::m_fieldValue + ")") int m_count; }; In fact I want to execute another query based on the results of this view. Do you have any suggestions? Thanks, Ali From martin at mu-schneider.de Mon May 30 13:55:35 2016 From: martin at mu-schneider.de (Martin Schneider) Date: Mon May 30 13:55:44 2016 Subject: [odb-users] Linking problem at Ubuntu 16.04 In-Reply-To: References: <5749A9C9.2010602@mu-schneider.de> Message-ID: <574C7E97.1090803@mu-schneider.de> > Hi Martin, > > Martin Schneider writes: > >> ./configure --with-database=mysql >> >> [...] >> >> /usr/lib/gcc/x86_64-linux-gnu/5/../../../x86_64-linux-gnu/libodb-mysql.so: >> undefined reference to `odb::statement::process_insert(char const*, >> void const* const*, unsigned long, unsigned long, char, >> std::__cxx11::basic_string, >> std::allocator >&)' >> /usr/lib/gcc/x86_64-linux-gnu/5/../../../x86_64-linux-gnu/libodb-mysql.so: >> undefined reference to `odb::statement::process_update(char const*, >> void const* const*, unsigned long, unsigned long, char, >> std::__cxx11::basic_string, >> std::allocator >&)' >> /usr/lib/gcc/x86_64-linux-gnu/5/../../../x86_64-linux-gnu/libodb-mysql.so: >> undefined reference to `odb::statement::process_select(char const*, >> void const* const*, unsigned long, unsigned long, char, char, bool, >> std::__cxx11::basic_string, >> std::allocator >&, bool)' >> >> [...] >> >> installed by: >> sudo apt-get install libodb-dev libodb-mysql-dev libodb-boost-dev >> libodb-qt-dev > Hm, looking at those 'std::__cxx11::basic_string' my suspicion is that > there is a C++98/C++11 mismatch. Normally, with libstdc++, a library > that was compiled with C++98 can be used with C++11. However, I am not > sure if the other way around also works, my guess would be it does not. > And it looks like libodb-mysql was compiled in the C++11 mode while > libodb was not. > > You could try to configure your tests in C++11 though I am not sure > it will make any difference (it is the way libodb-mysql is build that > is the problem): > > ./configure --with-database=mysql CXXFLAGS=-std=c++11 > > I think we should dig into the libodb-mysql package and/or contact > its maintainer with this information. > > Boris Hi Boris, just checked with ./configure --with-database=mysql CXXFLAGS=-std=c++11 make but then a lot of deprecate warnings like: ../../libcommon/common/common.hxx:42:15: warning: 'template class std::auto_ptr' is deprecated [-Wdeprecated-declarations] and finally a stopping error appears: g++ -DHAVE_CONFIG_H -I'../../libcommon' -I'../../libcommon' -I'.' -I'.' -std=c++11 -D_REENTRANT -MT test-odb.o -MD -MP -MF $depbase.Tpo -c -o test-odb.o test-odb.cxx &&\ mv -f $depbase.Tpo $depbase.Po test-odb.cxx: In static member function ?static void odb::access::object_traits_impl::init(odb::access::object_traits::object_type&, const odb::access::object_traits_impl::image_type&, odb::database*)?: test-odb.cxx:2367:14: error: use of deleted function ?std::unique_ptr<_Tp, _Dp>::unique_ptr(const std::unique_ptr<_Tp, _Dp>&) [with _Tp = test3::object1; _Dp = std::default_delete]? o.p2 (v); ^ In file included from /usr/include/c++/5/memory:81:0, from test.hxx:13, from test-odb.hxx:16, from test-odb.cxx:7: /usr/include/c++/5/bits/unique_ptr.h:356:7: note: declared here unique_ptr(const unique_ptr&) = delete; ^ In file included from test-odb.hxx:16:0, from test-odb.cxx:7: test.hxx:287:10: note: initializing argument 1 of ?void test3::object2::p2(test3::object1_ptr)? void p2 (object1_ptr p2) {p2_ = std::move (p2);} ^ Thanks Martin From boris at codesynthesis.com Mon May 30 18:57:55 2016 From: boris at codesynthesis.com (Boris Kolpackov) Date: Mon May 30 18:58:05 2016 Subject: [odb-users] Linking problem at Ubuntu 16.04 In-Reply-To: <574C7E97.1090803@mu-schneider.de> References: <5749A9C9.2010602@mu-schneider.de> <574C7E97.1090803@mu-schneider.de> Message-ID: Hi Martin, Martin Schneider writes: > ./configure --with-database=mysql CXXFLAGS=-std=c++11 > make > > but then a lot of deprecate warnings like: > ../../libcommon/common/common.hxx:42:15: warning: 'template class std::auto_ptr' is deprecated [-Wdeprecated-declarations] You can add -Wno-deprecated to suppress these (we will get rid of them once we switch to C++11-only): ./configure --with-database=mysql CXXFLAGS="-std=c++11 -Wno-deprecated" > test-odb.cxx:2367:14: error: use of deleted function ?std::unique_ptr<_Tp, _Dp>::unique_ptr(const std::unique_ptr<_Tp, _Dp>&) [with _Tp = test3::object1; _Dp = std::default_delete]? > o.p2 (v); I am pretty sure you are trying to compile code generated in the C++98 mode. Did you do: make distclean Before running configure? Boris From boris at codesynthesis.com Mon May 30 18:59:21 2016 From: boris at codesynthesis.com (Boris Kolpackov) Date: Mon May 30 18:59:32 2016 Subject: [odb-users] Nested Select Query In-Reply-To: <1464602212318.25733@noornet.net> References: <1464602212318.25733@noornet.net> Message-ID: Hi Ali, adanesh@noornet.net writes: > Does ODB support nested select query? Not directly, yet. The only way to do it currently is via a native view. Boris From sean.clarke at sec-consulting.co.uk Tue May 31 02:24:11 2016 From: sean.clarke at sec-consulting.co.uk (Sean Clarke) Date: Tue May 31 02:24:25 2016 Subject: [odb-users] Linking problem at Ubuntu 16.04 In-Reply-To: <5749A9C9.2010602@mu-schneider.de> References: <5749A9C9.2010602@mu-schneider.de> Message-ID: I have never been able to use the supplied binaries on Ubuntu (15.1 and 16.04), I "believed" this was down to the ABI change and "assumed" it was because the old binaries had been compiled with the old ABI and all my code used the new ABI, however looking at you errors that is not the case as and ABI incompatibility with gcc gives errors something similar to: src/system/some_system.so: undefined reference to `some_namespace::some _class::some_method[abi:cxx11]()' Regards Sean Clarke SEC Consulting Limited +44 (0)23 8040 5599 http://www.sec-consulting.co.uk sean.clarke@sec-consulting.co.uk SEC Consulting Ltd is registered in England & Wales No: 5033740. This email is from SEC Consulting Ltd and any information contained in it, including any attachment or enclosure, is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any unauthorised use, review, dissemination, copying or other use of this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material immediately. On 28 May 2016 at 15:23, Martin Schneider wrote: > Hi, > > I've switched to Ubuntu 16.04 and get some strange problems when linking > my old odb programs. > After this I tried the examples from odb-tests-2.4.0 and get the same > error. > > Running following commands gives > > ./configure --with-database=mysql > > make > ... > make[4]: Verzeichnis > ?/home/martin/projects/odb/odb-tests-2.4.0/common/access? wird betreten > /bin/bash ../../libtool --tag=CXX --mode=link g++ -g -O2 -D_REENTRANT > -o driver driver.o test-odb.o ../../libcommon/common/libcommon.la > -lodb-mysql -lodb-qt -lodb-boost -lboost_date_time -lboost_system -lodb > -lpthread > libtool: link: g++ -g -O2 -D_REENTRANT -o .libs/driver driver.o > test-odb.o ../../libcommon/common/.libs/libcommon.so -lodb-mysql -lodb-qt > -lodb-boost -lboost_date_time -lboost_system -lodb -lpthread > /usr/lib/gcc/x86_64-linux-gnu/5/../../../x86_64-linux-gnu/libodb-mysql.so: > undefined reference to `odb::statement::process_insert(char const*, void > const* const*, unsigned long, unsigned long, char, > std::__cxx11::basic_string, > std::allocator >&)' > /usr/lib/gcc/x86_64-linux-gnu/5/../../../x86_64-linux-gnu/libodb-mysql.so: > undefined reference to `odb::statement::process_update(char const*, void > const* const*, unsigned long, unsigned long, char, > std::__cxx11::basic_string, > std::allocator >&)' > /usr/lib/gcc/x86_64-linux-gnu/5/../../../x86_64-linux-gnu/libodb-mysql.so: > undefined reference to `odb::statement::process_select(char const*, void > const* const*, unsigned long, unsigned long, char, char, bool, > std::__cxx11::basic_string, > std::allocator >&, bool)' > collect2: error: ld returned 1 exit status > Makefile:343: die Regel f?r Ziel ?driver? scheiterte > ... > > > Following odb libs are installed: > martin@pcmartin:~/projects/odb/odb-tests-2.4.0$ ll > /usr/lib/x86_64-linux-gnu/libodb* > -rw-r--r-- 1 root root 142048 Mai 25 2015 libodb-2.4.so > -rw-r--r-- 1 root root 341234 Mai 25 2015 libodb.a > -rw-r--r-- 1 root root 10408 Mai 27 2015 libodb-boost-2.4.so > -rw-r--r-- 1 root root 12754 Mai 27 2015 libodb-boost.a > lrwxrwxrwx 1 root root 19 Mai 27 2015 libodb-boost.so -> > libodb-boost-2.4.so > -rw-r--r-- 1 root root 171232 Apr 5 17:18 libodb-mysql-2.4.so > -rw-r--r-- 1 root root 374774 Apr 5 17:18 libodb-mysql.a > lrwxrwxrwx 1 root root 19 Apr 5 17:18 libodb-mysql.so -> > libodb-mysql-2.4.so > -rw-r--r-- 1 root root 10408 Jul 5 2015 libodb-qt-2.4.so > -rw-r--r-- 1 root root 10318 Jul 5 2015 libodb-qt.a > lrwxrwxrwx 1 root root 16 Jul 5 2015 libodb-qt.so -> > libodb-qt-2.4.so > lrwxrwxrwx 1 root root 13 Mai 25 2015 libodb.so -> libodb-2.4.so > > installed by: > sudo apt-get install libodb-dev libodb-mysql-dev libodb-boost-dev > libodb-qt-dev > > > Any idea where my mistake is? > > Thanks > Martin > > From sean.clarke at sec-consulting.co.uk Tue May 31 02:46:41 2016 From: sean.clarke at sec-consulting.co.uk (Sean Clarke) Date: Tue May 31 02:46:53 2016 Subject: [odb-users] Linking problem at Ubuntu 16.04 In-Reply-To: References: <5749A9C9.2010602@mu-schneider.de> Message-ID: Just to check I have updated my CMake file to not include my projects compiled ODB shared objects and use the system compiled libodb and libodb-pgsql and I get similar failures as the original poster (I also spotted an ABI reference): [ 91%] Linking CXX executable bin/MyApp CMakeFiles/MyApp.dir/web_services/SomeWebService.cpp.o: In function `void __gnu_cxx::new_allocator::construct(odb::pgsql::database*, char const (&) [19], char const (&) [19], char const (&) [19], char const (&) [29])': /usr/include/c++/5/ext/new_allocator.h:120: undefined reference to ` odb::pgsql::database::database(std::__cxx11::basic_string, std::allocator > const&, std::__cxx11: :basic_string, std::allocator > const&, std::__cxx11::basic_string, std::allocator > const&, std::__cxx11::basic_string, std::allocator > const&, unsigned int, std:: __cxx11::basic_string, std::allocator > const&, odb::details::transfer_ptr)' lib/libMyAppDbLib.so: undefined reference to `odb::pgsql::select_statement::free_result()' lib/libMyAppDbLib.so: undefined reference to `odb::pgsql::select_statement::load()' lib/libMyAppDbLib.so: undefined reference to `typeinfo for odb::object_not_persistent' lib/libMyAppDbLib.so: undefined reference to `odb::pgsql::object_statements_base::~object_statements_base()' lib/libMyAppDbLib.so: undefined reference to `odb::transaction::commit()' lib/libMyAppDbLib.so: undefined reference to `odb::pgsql::select_statement::select_statement(odb::pgsql::connection&, std::__cxx11::basic_string, std::allocator > const&, std::__cxx11::basic_string, std::allocator > const&, bool, bool, unsigned int const*, unsigned long, odb::pgsql::native_binding&, odb::pgsql::binding&)' lib/libMyAppDbLib.so: undefined reference to `odb::pgsql::select_statement::reload()' lib/libMyAppDbLib.so: undefined reference to `odb::pgsql::delete_statement::delete_statement(odb::pgsql::connection&, std::__cxx11::basic_string, std::allocator > const&, std::__cxx11::basic_string, std::allocator > const&, unsigned int const*, unsigned long, odb::pgsql::native_binding&)' lib/libMyAppDbLib.so: undefined reference to `typeinfo for odb::null_pointer ' lib/libMyAppDbLib.so: undefined reference to `odb::pgsql::operator||(odb::pgsql::query_base const&, odb::pgsql::query_base const&)' lib/libMyAppDbLib.so: undefined reference to `odb::pgsql::select_statement::next()' lib/libMyAppDbLib.so: undefined reference to ` odb::pgsql::select_statement::execute()' lib/libMyAppDbLib.so: undefined reference to `vtable for odb::object_not_persistent' lib/libMyAppDbLib.so: undefined reference to `odb::pgsql::insert_statement::execute()' lib/libMyAppDbLib.so: undefined reference to ` odb::pgsql::transaction::current()' lib/libMyAppDbLib.so: undefined reference to `vtable for odb::session::object_map_base' lib/libMyAppDbLib.so: undefined reference to `odb::pgsql::insert_statement::insert_statement(odb::pgsql::connection&, char const*, char const*, bool, unsigned int const*, unsigned long, odb::pgsql::binding&, odb::pgsql::native_binding&, odb::pgsql::binding*, bool)' lib/libMyAppDbLib.so: undefined reference to `typeinfo for odb::session::object_map_base' lib/libMyAppDbLib.so: undefined reference to `odb::details::shared_base::_dec_ref_callback()' lib/libMyAppDbLib.so: undefined reference to `vtable for odb::pgsql::query_param' lib/libMyAppDbLib.so: undefined reference to `vtable for odb::null_pointer' lib/libMyAppDbLib.so: undefined reference to `typeinfo for odb::result_impl' lib/libMyAppDbLib.so: undefined reference to `odb::pgsql::query_base::append(odb::details::shared_ptr, char const*)' lib/libMyAppDbLib.so: undefined reference to ` odb::session::current_pointer()' lib/libMyAppDbLib.so: undefined reference to `odb::details::basic_buffer_base::capacity(unsigned long, unsigned long)' lib/libMyAppDbLib.so: undefined reference to `odb::details::shared' lib/libMyAppDbLib.so: undefined reference to `odb::pgsql::delete_statement::delete_statement(odb::pgsql::connection&, char const*, char const*, unsigned int const*, unsigned long, odb::pgsql::binding&, odb::pgsql::native_binding&, bool)' lib/libMyAppDbLib.so: undefined reference to `odb::pgsql::delete_statement::execute()' lib/libMyAppDbLib.so: undefined reference to `odb::pgsql::query_base::append(std::__cxx11::basic_string, std::allocator > const&)' lib/libMyAppDbLib.so: undefined reference to ` odb::pgsql::statement::deallocate()' lib/libMyAppDbLib.so: undefined reference to `odb::transaction::reset(odb::transaction_impl*, bool)' lib/libMyAppDbLib.so: undefined reference to `odb::pgsql::delete_statement::~delete_statement()' lib/libMyAppDbLib.so: undefined reference to ` odb::pgsql::query_param::~query_param()' lib/libMyAppDbLib.so: undefined reference to `odb::pgsql::query_base::clause[abi:cxx11]() const' lib/libMyAppDbLib.so: undefined reference to `odb::pgsql::operator&&(odb::pgsql::query_base const&, odb::pgsql::query_base const&)' lib/libMyAppDbLib.so: undefined reference to `typeinfo for odb::pgsql::query_param' lib/libMyAppDbLib.so: undefined reference to `odb::pgsql::update_statement::update_statement(odb::pgsql::connection&, char const*, char const*, bool, unsigned int const*, unsigned long, odb::pgsql::binding&, odb::pgsql::native_binding&, bool)' lib/libMyAppDbLib.so: undefined reference to `odb::session::object_map_base::~object_map_base()' lib/libMyAppDbLib.so: undefined reference to ` odb::result_impl::result_impl(odb::connection&)' lib/libMyAppDbLib.so: undefined reference to `odb::pgsql::select_statement::select_statement(odb::pgsql::connection&, char const*, char const*, bool, bool, unsigned int const*, unsigned long, odb::pgsql::binding&, odb::pgsql::native_binding&, odb::pgsql::binding&, bool)' lib/libMyAppDbLib.so: undefined reference to `odb::pgsql::query_base::query_base(odb::pgsql::query_base const&)' lib/libMyAppDbLib.so: undefined reference to ` odb::transaction::~transaction()' lib/libMyAppDbLib.so: undefined reference to `odb::pgsql::query_base::append(char const*, char const*)' lib/libMyAppDbLib.so: undefined reference to `typeinfo for odb::pgsql::object_statements_base' lib/libMyAppDbLib.so: undefined reference to ` odb::pgsql::default_value_traits, std::allocator >, (odb::pgsql::database_type_id)10>::set_image(odb::details::basic_buffer&, unsigned long&, bool&, std::__cxx11::basic_string, std::allocator > const&)' lib/libMyAppDbLib.so: undefined reference to `typeinfo for odb::object_already_persistent' lib/libMyAppDbLib.so: undefined reference to `vtable for odb::pgsql::object_statements_base' lib/libMyAppDbLib.so: undefined reference to `vtable for odb::object_already_persistent' lib/libMyAppDbLib.so: undefined reference to `odb::result_impl::~result_impl()' lib/libMyAppDbLib.so: undefined reference to `odb::pgsql::update_statement::execute()' lib/libMyAppDbLib.so: undefined reference to ` odb::pgsql::details::endian_traits::host_endian' lib/libMyAppDbLib.so: undefined reference to `vtable for odb::pgsql::statements_base' lib/libMyAppDbLib.so: undefined reference to `odb::pgsql::query_base::init_parameters() const' Regards Sean Clarke From mne at qosmotec.com Tue May 31 11:36:30 2016 From: mne at qosmotec.com (Marcel Nehring) Date: Tue May 31 11:36:40 2016 Subject: AW: [odb-users] Problem with session cache and weak_ptr In-Reply-To: References: <8449ca0fd5fc487b8a9440690d6bc3c6@QEX.qosmotec.com> <00c73cb1e87643e9961f94d45ea5ea1e@QEX.qosmotec.com> <1965057559504f13b51a9e35554385b3@QEX.qosmotec.com> <1ec711815e80442898bd66822896e2e8@QEX.qosmotec.com> Message-ID: Hi Boris, sorry for so many questions about this topic but it is causing a lot of trouble and confusion here. If the object a lazy_weak_ptr points to expires, is the state of the pointer still loaded or will it change to unloaded? I.e. if I have a valid pointer to a persistent object, and the pointer expires, will loaded() return true (so that it become effectively a NULL pointer to a transient object) or will it return false (so that it effectively becomes an unloaded pointer to a persistent object)? Regards, Marcel