From boris at codesynthesis.com Fri May 1 12:36:46 2015 From: boris at codesynthesis.com (Boris Kolpackov) Date: Fri May 1 12:36:54 2015 Subject: [odb-users] Transient class member that is only used to load an expression In-Reply-To: References: Message-ID: Hi Tolga, Tolga HO?G?R writes: > Thanks for ODB. It is a great, professional project. Thanks, I am glad you are enjoying it. > But the thing is I don't want the huge JSON column to be converted to text > and then parsed by the C++ JSON library completely. I need to add that JSON > class member to a lazy loading section and use only one field of it most of > the time. For that I want to create another (kind of a) transient > std::string class member that loads with 'table.JSON_column->>'json-key' > expression in the SELECT query field when I load the object. Obviously it > should not have an actual column on the database side. > > Is there a correct way to do this? There is no direct support for this in ODB. What you are looking for is an "expression member". While I can see it being useful, supporting something like this will further complicate the already complex logic in this area. Also, once we have this support, the next "reasonable" thing to want would be custom JOIN's so that you could use joined tables/objects in such expressions... At the same time, all of this (including custom JOIN's) is already supported by ODB views. In fact, it would be trivial to implement an object-loading view that also contains your expression. It will even load everything with a single SELECT statement. I would say this is a perfect solution except that this expression is loaded into a data member outside the object (you would probably be able to "patch" it directly into the object with a bit of clever code) and, and this is the biggest issue, you have to load/query the view, not the object. If you don't mind wrapping the database::load (and database::query calls, if you use them), then this would work pretty well. Perhaps we should be thinking about supporting something like loading/querying an object using a custom object-loading view but using the normal object load/query API. Or perhaps we should just keep it simple ;-). Boris From fasdfasdas at gmail.com Fri May 1 16:20:40 2015 From: fasdfasdas at gmail.com (=?UTF-8?B?VG9sZ2EgSE/FnkfDllI=?=) Date: Fri May 1 16:20:49 2015 Subject: [odb-users] Transient class member that is only used to load an expression In-Reply-To: References: Message-ID: Hello Boris, Thanks for the comprehensive answer. I guess I will keep the current view approach then. Views work very well for this situation as you say. I also have to query information if a bidirectional relationship exists or not and I'd rather do it in the database side using a view instead of looking through an ordered std::vector in the code. I am not using sessions anyway so I am not really missing anything by using the views :). Using an object-loading view with the load/query api idea feels a bit unnatural, keeping it simple is probably better. ODB is already really extensive and more features may make it a bit unappealing for starters. Regads, Tolga. On Fri, May 1, 2015 at 7:36 PM Boris Kolpackov wrote: > Hi Tolga, > > Tolga HO?G?R writes: > > > Thanks for ODB. It is a great, professional project. > > Thanks, I am glad you are enjoying it. > > > > But the thing is I don't want the huge JSON column to be converted to > text > > and then parsed by the C++ JSON library completely. I need to add that > JSON > > class member to a lazy loading section and use only one field of it most > of > > the time. For that I want to create another (kind of a) transient > > std::string class member that loads with 'table.JSON_column->>'json-key' > > expression in the SELECT query field when I load the object. Obviously it > > should not have an actual column on the database side. > > > > Is there a correct way to do this? > > There is no direct support for this in ODB. What you are looking > for is an "expression member". While I can see it being useful, > supporting something like this will further complicate the already > complex logic in this area. Also, once we have this support, the > next "reasonable" thing to want would be custom JOIN's so that you > could use joined tables/objects in such expressions... > > At the same time, all of this (including custom JOIN's) is already > supported by ODB views. In fact, it would be trivial to implement > an object-loading view that also contains your expression. It will > even load everything with a single SELECT statement. I would say > this is a perfect solution except that this expression is loaded > into a data member outside the object (you would probably be able > to "patch" it directly into the object with a bit of clever code) > and, and this is the biggest issue, you have to load/query the > view, not the object. If you don't mind wrapping the database::load > (and database::query calls, if you use them), then this would > work pretty well. > > Perhaps we should be thinking about supporting something like > loading/querying an object using a custom object-loading view > but using the normal object load/query API. Or perhaps we should > just keep it simple ;-). > > Boris > > From mne at qosmotec.com Mon May 4 06:13:06 2015 From: mne at qosmotec.com (Marcel Nehring) Date: Mon May 4 06:13:58 2015 Subject: [odb-users] Access relationships Message-ID: Hi, in my code I use the "Unit Of Work"-Pattern. I am currently trying to solve the problem of figuring out in which order I need to persist new objects to avoid foreign key constraint violations. As a first step I thought on doing a topological sort based on foreign key relationships between persistent classes and I was wondering if ODB provides some kind of information in a way that I could use to perform the sorting? In some way ODB needs to be aware of existing relationships and I was wondering whether this knowledge can be exploited or whether it is only present during compilation and later "hardcoded" in the generated files. I had a look into the generated files and it looks like the latter is the case, but I wanted to be sure. This is *not* a feature request. Figuring out the correct order for persisting objects seems to be a complicated task and not much information about it can be found online. If anyone on the list has some tips/links I would appreciate it. Regards, Marcel From fasdfasdas at gmail.com Tue May 5 10:36:03 2015 From: fasdfasdas at gmail.com (=?UTF-8?B?VG9sZ2EgSE/FnkfDllI=?=) Date: Tue May 5 10:36:13 2015 Subject: [odb-users] Bug With Polymorphism Inheritance Message-ID: Hello all, I think there is a bug with polymorphism inheritance. Consider the following: #pragma db object table("base") class Base { }; #pragma db object table("derived") class Derived : public Base { }; Now, the generated SQL uses LEFT JOIN "Base"."member" which obviously results in error. Is there a way I can specify the Base table in the Drived class declaration? Thanks, Tolga. From fasdfasdas at gmail.com Tue May 5 10:37:29 2015 From: fasdfasdas at gmail.com (=?UTF-8?B?VG9sZ2EgSE/FnkfDllI=?=) Date: Tue May 5 10:37:36 2015 Subject: [odb-users] Re: Bug With Polymorphism Inheritance In-Reply-To: References: Message-ID: I forgot the put 'polymorphic' and 'optimistic' directives in the Base class pragma in the previous mail by the way. On Tue, May 5, 2015 at 5:36 PM Tolga HO?G?R wrote: > Hello all, > > I think there is a bug with polymorphism inheritance. Consider the > following: > > #pragma db object table("base") > class Base { > }; > > #pragma db object table("derived") > class Derived > : public Base { > }; > > Now, the generated SQL uses LEFT JOIN "Base"."member" which obviously > results in error. Is there a way I can specify the Base table in the Drived > class declaration? > > Thanks, > Tolga. > From fasdfasdas at gmail.com Tue May 5 11:19:16 2015 From: fasdfasdas at gmail.com (=?UTF-8?B?VG9sZ2EgSE/FnkfDllI=?=) Date: Tue May 5 11:19:24 2015 Subject: [odb-users] Re: Bug With Polymorphism Inheritance In-Reply-To: References: Message-ID: Please ignore this issue. It appears that it was because of a problem in the build system. On Tue, May 5, 2015 at 5:37 PM Tolga HO?G?R wrote: > I forgot the put 'polymorphic' and 'optimistic' directives in the Base > class pragma in the previous mail by the way. > > On Tue, May 5, 2015 at 5:36 PM Tolga HO?G?R wrote: > >> Hello all, >> >> I think there is a bug with polymorphism inheritance. Consider the >> following: >> >> #pragma db object table("base") >> class Base { >> }; >> >> #pragma db object table("derived") >> class Derived >> : public Base { >> }; >> >> Now, the generated SQL uses LEFT JOIN "Base"."member" which obviously >> results in error. Is there a way I can specify the Base table in the Drived >> class declaration? >> >> Thanks, >> Tolga. >> > From boris at codesynthesis.com Tue May 5 13:20:19 2015 From: boris at codesynthesis.com (Boris Kolpackov) Date: Tue May 5 13:20:26 2015 Subject: [odb-users] Access relationships In-Reply-To: References: Message-ID: Hi Marcel, Marcel Nehring writes: > in my code I use the "Unit Of Work"-Pattern. I am currently trying > to solve the problem of figuring out in which order I need to persist > new objects to avoid foreign key constraint violations. Perhaps there is a solution to your problem right there in this description: don't use "patterns" (or any other dogmatic design techniques) that complicate your code to such a degree that you can no longer reason about the order of object creation. Keep things simple. > As a first step I thought on doing a topological sort based on > foreign key relationships between persistent classes and I was > wondering if ODB provides some kind of information in a way that > I could use to perform the sorting? No, ODB keeps no runtime information of this sort. I haven't thought this through far enough, but perhaps you could achieve what you want with a custom session and/or smart pointer that keep track of the dependencies in your object graph. See Section 11.2, "Custom Sessions" for details. Boris From mne at qosmotec.com Wed May 6 03:16:19 2015 From: mne at qosmotec.com (Marcel Nehring) Date: Wed May 6 03:16:49 2015 Subject: [odb-users] Access relationships In-Reply-To: References: , Message-ID: <5EF0991C-5FB7-4AD3-B997-6F2B06E0C263@qosmotec.com> Hi Boris, Thanks for your answer. > Perhaps there is a solution to your problem right there in this > description: don't use "patterns" (or any other dogmatic design > techniques) that complicate your code to such a degree that you > can no longer reason about the order of object creation. Keep > things simple. UoW and other patterns are present in more or less every ORM system I know of. I don't use any pattern for the sole purpose of using a patter. We faced some problems which could be solved with these patterns and so far I don't know any other solution. Our component under development is huge and as previous discussions have shown we push ODB to its limits. Luckily we didn't push it beyond them yet ;) >> As a first step I thought on doing a topological sort based on >> foreign key relationships between persistent classes and I was >> wondering if ODB provides some kind of information in a way that >> I could use to perform the sorting? > > No, ODB keeps no runtime information of this sort. That's what it already looked like to me. Thanks for the confirmation. Regards, Marcel From fasdfasdas at gmail.com Wed May 6 07:04:05 2015 From: fasdfasdas at gmail.com (=?UTF-8?B?VG9sZ2EgSE/FnkfDllI=?=) Date: Wed May 6 07:04:16 2015 Subject: [odb-users] Multiple column primary key (id) Message-ID: Hello, I have looked through the documentation but I think ODB does not support multi-column primary key. I'd like to use a std::pair as a key and PSQL supports the following syntax: CREATE TABLE example ( a integer, b integer, c integer, *PRIMARY KEY (a, c)* ); I tried using virtuals to achieve this: #pragma db id transient std::pair id_; #pragma db member(first) virtual(std::string) access(id_.first) #pragma db member(last) virtual(std::string) access(id_.second) But it does not compile. Do you have any idea if I can achieve this or not? Thanks, Tolga. From boris at codesynthesis.com Wed May 6 13:43:13 2015 From: boris at codesynthesis.com (Boris Kolpackov) Date: Wed May 6 13:43:19 2015 Subject: [odb-users] Multiple column primary key (id) In-Reply-To: References: Message-ID: Hi Tolga, Tolga HO?G?R writes: > I have looked through the documentation but I think ODB does not support > multi-column primary key. Section 7.2.1, "Composite Object Ids". Boris From fasdfasdas at gmail.com Wed May 6 13:59:47 2015 From: fasdfasdas at gmail.com (=?UTF-8?B?VG9sZ2EgSE/FnkfDllI=?=) Date: Wed May 6 13:59:55 2015 Subject: [odb-users] Multiple column primary key (id) In-Reply-To: References: Message-ID: Sorry, my mistake. I misinterpreted the not allowed "composite value types" in 14.4.1 "id" section. Sincerely, Tolga On Wed, May 6, 2015, 20:43 Boris Kolpackov wrote: > Hi Tolga, > > Tolga HO?G?R writes: > > > I have looked through the documentation but I think ODB does not support > > multi-column primary key. > > Section 7.2.1, "Composite Object Ids". > > Boris > From tmatthews at appliedmedical.com Wed May 6 16:17:26 2015 From: tmatthews at appliedmedical.com (Matthews, Thomas) Date: Fri May 8 07:51:34 2015 Subject: [odb-users] Preserving schema data in Visual Studio Static Library Message-ID: <29886DC6E140EB408FF197BDF257D2ADFAFD57B8@EX2.appliedmed.com> I'm using Visual Studio 2010 and Visual Studio 2008 to build a static library containing my ODB classes. When execute my program, I get the following error message for every ODB object: Uncaught exception of type struct odb::unknown_schema - unknown database schema. There are articles on how to fix this on Linux or with Mingw (GCC). The only information I found related to Visual Studio is to add this text to the odb command line: --cxx-epilogue 'extern "C" int object_phony_symbol = 0;' The problem is I get "C : error : unable to open in read mode". The marks are single quotes around the C++ statement. The error also occurs when using the back-tick marks as well. The discussion text also has a link to 2.2.0 but I'm using version 2.3.0. Does anybody have a *working* solution for telling Visual Studio not to drop the schema data when creating a static library? Due to the size of my project, I really prefer not to have all the cxx files in one module. What is your solution to this issue? I'm using ODB version 2.3.0. The odb command line is in the property page of the hpp file, under the Custom Build Tool - Command Line. Here's an example: odb -Ic:\menuplan\src\ingredient -o c:\menuplan\src\ingredient -d mysql --hxx-prologue "#include \"odb/traits.hxx\"" --generate-query --generate-schema --schema-format separate --cxx-epilogue `extern "C" int category_phony_symbol = 0;` c:\menuplan\src\ingredient\ing_odb_category.hpp Thanks, From Aleksey.Enakaev at infotecs.ru Fri May 8 05:43:28 2015 From: Aleksey.Enakaev at infotecs.ru (=?UTF-8?B?0JXQvdCw0LrQsNC10LIg0JDQu9C10LrRgdC10Lk=?=) Date: Fri May 8 07:51:34 2015 Subject: [odb-users] Question about join type for polymorphic objects In-Reply-To: <554C72D8.8020902@infotecs.ru> References: <554C72D8.8020902@infotecs.ru> Message-ID: <554C8540.2010308@infotecs.ru> Hi. We have a question about join type generated for polymorphic objects. Let's see at this sample code: #pragma db object polymorphic struct person { /* id, name, etc. */ }; #pragma db object struct employee : person { /* position, etc. */ }; For object "employee" ODB compiler generates something like this: SELECT * FROM "employee" LEFT JOIN "person" ON "person"."id" = "person"."id" ... etc. but PostgreSQL can not use "LEFT JOIN" with "FOR UPDATE". Code using query = odb::query< person >; const query q = (query::id == some_id && query::name == some_name) + "for update"; causes PostgreSQL error "FOR UPDATE cannot be applied to the nullable side of an outer join". So we have to write some extras: const query q = (query::id == some_id && query::name == some_name) + "for update of" + odb::object_traits_impl< employee, id_pgsql >::table_name; Is there any way to explicit join type for polymorphic objects? And doesn't is look more reasonable to use INNER JOIN always for this kind of objects? Best regards. From boris at codesynthesis.com Fri May 8 15:15:36 2015 From: boris at codesynthesis.com (Boris Kolpackov) Date: Fri May 8 15:15:40 2015 Subject: [odb-users] Preserving schema data in Visual Studio Static Library In-Reply-To: <29886DC6E140EB408FF197BDF257D2ADFAFD57B8@EX2.appliedmed.com> References: <29886DC6E140EB408FF197BDF257D2ADFAFD57B8@EX2.appliedmed.com> Message-ID: Hi Thomas, Matthews, Thomas writes: > The only information I found related to Visual Studio is to add this > text to the odb command line: --cxx-epilogue 'extern "C" int > object_phony_symbol = 0;' There is another way, as described in this post: http://www.codesynthesis.com/pipermail/odb-users/2013-May/001289.html > Does anybody have a *working* solution for telling Visual Studio not > to drop the schema data when creating a static library? That solution is working, you just haven't been able to apply it properly. One way to sidestep this quoting mess is to place the option into an options file. See the REGEX AND SHELL QUOTING section at the bottom of the ODB Compiler Command Line Manual (man page) for details. Boris From boris at codesynthesis.com Fri May 8 16:26:47 2015 From: boris at codesynthesis.com (Boris Kolpackov) Date: Fri May 8 16:26:52 2015 Subject: [odb-users] Question about join type for polymorphic objects In-Reply-To: <554C8540.2010308@infotecs.ru> References: <554C72D8.8020902@infotecs.ru> <554C8540.2010308@infotecs.ru> Message-ID: Hi Aleksey, ??????? ??????? writes: > SELECT * FROM "employee" LEFT JOIN "person" ON "person"."id" = > "person"."id" ... etc. > > And doesn't is look more reasonable to use INNER JOIN always for > this kind of objects? Yes, for all intents and purposes this is an INNER JOIN. And it shouldn't be any slower, in theory. However, in practice, the implementations seem to do a better job optimizing more commonly- used LEFT JOINs than INNER JOINs[1][2]. So I am reluctant to just change this. > but PostgreSQL can not use "LEFT JOIN" with "FOR UPDATE". > > Is there any way to explicit join type for polymorphic objects? Not at the moment. What you could do, however, is create a "for update" object loading view that would include that "FOR UPDATE OF ..." clause once in the query condition. This way you won't have to keep repeating it in your query construction code. Object loading views (Section 10.2) were added to handle stuff like this. [1] http://stackoverflow.com/questions/2726657/inner-join-vs-left-join-performance-in-sql-server [2] http://stackoverflow.com/questions/17100819/left-join-significantly-faster-than-inner-join Boris From amr.faissal at gmail.com Thu May 14 09:19:44 2015 From: amr.faissal at gmail.com (Faissal Elamraoui) Date: Thu May 14 09:20:12 2015 Subject: [odb-users] Problem linking my project: undefined reference to `odb::access::object_traits_impl Message-ID: Hello everyone, I keep getting this error while linking my C++ project on NetBeans : /usr/local/include/odb/database.txx:38: undefined reference to `odb::access::object_traits_impl::persist(odb::database&, BGOParams&)' collect2: error: ld returned 1 exit status odb and odb-mysql libraries are already passed to the Linker, but no success. Any pointers? Am i missing something? Thank you guys, Faissal From boris at codesynthesis.com Thu May 14 16:33:09 2015 From: boris at codesynthesis.com (Boris Kolpackov) Date: Thu May 14 16:33:08 2015 Subject: [odb-users] Problem linking my project: undefined reference to `odb::access::object_traits_impl In-Reply-To: References: Message-ID: Hi Faissal, Faissal Elamraoui writes: > /usr/local/include/odb/database.txx:38: undefined reference to > `odb::access::object_traits_impl (odb::database_id)0>::persist(odb::database&, BGOParams&)' > collect2: error: ld returned 1 exit status > > odb and odb-mysql libraries are already passed to the Linker This symbol is defined by one of the -odb.cxx files. Specifically, if the header file that defines BGOParams were called foo.hxx, then the file that you need to add to your project would be foo-odb.cxx. Boris From lordvampyre at gmail.com Thu May 14 23:07:38 2015 From: lordvampyre at gmail.com (Diego Fernando) Date: Thu May 14 23:07:44 2015 Subject: [odb-users] ODB + Cmake Message-ID: Hi, I did the download of the source code from this https://github.com/BtbN/OdbCmake and I put in person.h #include , when I will try to compile the project the compiler showed a error saying that doesn't found the QtCore. If I compile without qtcore or without odb, it works. The only thing that I did was to change on the project was person.h person.h #ifndef PERSON_HXX #define PERSON_HXX #include #include // std::size_t #include #include #pragma db object class person { public: person (const std::string& first, const std::string& last, unsigned short age) : first_ (first), last_ (last), age_ (age) { } const std::string& first () const { return first_; } const std::string& last () const { return last_; } unsigned short age () const { return age_; } void age (unsigned short age) { age_ = age; } private: friend class odb::access; person () {} #pragma db id auto unsigned long id_; std::string first_; std::string last_; unsigned short age_; }; #pragma db view object(person) struct person_stat { #pragma db column("count(" + person::id_ + ")") std::size_t count; #pragma db column("min(" + person::age_ + ")") unsigned short min_age; #pragma db column("max(" + person::age_ + ")") unsigned short max_age; }; #endif // PERSON_HXX Cmakelist cmake_minimum_required(VERSION 2.8.12) project(OdbCMake) # Find includes in corresponding build directories set(CMAKE_INCLUDE_CURRENT_DIR ON) list(APPEND CMAKE_MODULE_PATH "${CMAKE_SOURCE_DIR}/cmake/Modules") find_package(ODB REQUIRED COMPONENTS qt pgsql) find_package(Qt5Core REQUIRED) include(${ODB_USE_FILE}) set(OdbCMake_SOURCES driver.cpp database.h) set(OdbCMake_ODB_HEADERS person.h) odb_compile(OdbCMake_SOURCES FILES ${OdbCMake_ODB_HEADERS} DB pgsql GENERATE_QUERY GENERATE_SESSION) add_executable(odbcmake ${OdbCMake_SOURCES} ${OdbCMake_ODB_HEADERS}) target_link_libraries(odbcmake ${ODB_LIBRARIES}) target_include_directories(odbcmake PRIVATE ${ODB_INCLUDE_DIRS} ${ODB_COMPILE_OUTPUT_DIR}) target_compile_definitions(odbcmake PRIVATE DATABASE_PGSQL) Thank you, Diego Fernando From timo at rothenpieler.org Fri May 15 12:55:00 2015 From: timo at rothenpieler.org (Timo Rothenpieler) Date: Fri May 15 12:55:14 2015 Subject: [odb-users] ODB + Cmake In-Reply-To: References: Message-ID: <555624E4.901@rothenpieler.org> > cmake_minimum_required(VERSION 2.8.12) > > project(OdbCMake) > > > # Find includes in corresponding build directories > set(CMAKE_INCLUDE_CURRENT_DIR ON) > > list(APPEND CMAKE_MODULE_PATH "${CMAKE_SOURCE_DIR}/cmake/Modules") > > find_package(ODB REQUIRED COMPONENTS qt pgsql) > find_package(Qt5Core REQUIRED) > include(${ODB_USE_FILE}) > > set(OdbCMake_SOURCES > driver.cpp > database.h) > > set(OdbCMake_ODB_HEADERS > person.h) > > odb_compile(OdbCMake_SOURCES FILES ${OdbCMake_ODB_HEADERS} DB pgsql > GENERATE_QUERY GENERATE_SESSION) > > add_executable(odbcmake > ${OdbCMake_SOURCES} > ${OdbCMake_ODB_HEADERS}) > target_link_libraries(odbcmake > ${ODB_LIBRARIES}) You're not telling it to link to Qt5, just finding the package does nothing on its own. > target_include_directories(odbcmake > PRIVATE > ${ODB_INCLUDE_DIRS} > ${ODB_COMPILE_OUTPUT_DIR}) > target_compile_definitions(odbcmake > PRIVATE > DATABASE_PGSQL) > > > Thank you, > > Diego Fernando > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: OpenPGP digital signature Url : http://codesynthesis.com/pipermail/odb-users/attachments/20150515/5691c34e/signature.pgp From 1049124443 at qq.com Fri May 22 22:49:20 2015 From: 1049124443 at qq.com (=?gb18030?B?06m78NauueI=?=) Date: Sat May 23 09:18:21 2015 Subject: [odb-users] build the ODB compiler Message-ID: I need build the ODB compiler myself! Thanks! From andrey.psv at gmail.com Sat May 23 04:23:52 2015 From: andrey.psv at gmail.com (Andrey Paraskevopulo) Date: Sat May 23 09:18:21 2015 Subject: [odb-users] Note about the creation Microsoft SQL Server database Message-ID: I need to create database by executing query (CREATE DATABASE). I?ve tried: odb::transaction t(db->begin()); db->execute("CREATE DATABASE MYDB;"); t.commit(); But this function throws an exception: CREATE DATABASE statement not allowed within multi-statement transaction. As I found from the MS documentation for CREATE DATABASE: The CREATE DATABASE statement must run in autocommit mode (the default transaction management mode) and is not allowed in an explicit or implicit transaction. Creation database from the connection also not working (without transaction) : db->connection()->execute("CREATE DATABASE MYDB;"); throws the same exception. Because according to ODB manual: The created connection is configured to use the manual commit mode. Solution for me is to manually enable autocommit: auto conn = db->connection(); auto handle = conn->handle(); SQLSetConnectAttrA (handle, SQL_ATTR_AUTOCOMMIT, (SQLPOINTER) SQL_AUTOCOMMIT_ON, 0); conn->execute("CREATE DATABASE MYDB;"); I hope this will be helpful for someone. Andrey Paraskevopulo From andrey.psv at gmail.com Sat May 23 07:33:15 2015 From: andrey.psv at gmail.com (Andrey Paraskevopulo) Date: Sat May 23 09:18:21 2015 Subject: [odb-users] Persisting empty binary values error. Microsoft SQL Server Message-ID: I need to store empty binary values in the binary fields. I?ve try to persist record with empty std::vector (or unsigned char), but this lead to program termination. (no matter what was the mapping type ? varbinary(max) or image). After short investigation I think that I?ve found the error. odb\mssql\traits.cxx void default_value_traits, id_long_binary >::param_callback(...){ ... *buffer = &v.front (); Calling std::vector::front function on an empty container causes undefined behavior. Possible solution: replace this string with: *buffer = v.empty()?nullptr:&v.front (); (for both char and unsigned char). I am not sure about side effects, but persisting empty vectors is working. odb version 2.4.0 Andrey Paraskevopulo From boris at codesynthesis.com Sat May 23 09:49:54 2015 From: boris at codesynthesis.com (Boris Kolpackov) Date: Sat May 23 09:49:54 2015 Subject: [odb-users] build the ODB compiler In-Reply-To: References: Message-ID: 1049124443@qq.com writes: > I need build the ODB compiler myself! Great! Download the source code package and look into the INSTALL file. If something doesn't work, provide detailed information on what you have done and what exactly doesn't work. Boris From boris at codesynthesis.com Sat May 23 09:57:27 2015 From: boris at codesynthesis.com (Boris Kolpackov) Date: Sat May 23 09:57:25 2015 Subject: [odb-users] Note about the creation Microsoft SQL Server database In-Reply-To: References: Message-ID: Hi Andrey, Andrey Paraskevopulo writes: > Solution for me is to manually enable autocommit: > > [...] > > I hope this will be helpful for someone. Thanks, I appreciate you sharing this. I've also added a note to our change development system so we will hopefully address this in a future release. Boris From boris at codesynthesis.com Sat May 23 10:13:40 2015 From: boris at codesynthesis.com (Boris Kolpackov) Date: Sat May 23 10:13:38 2015 Subject: [odb-users] Persisting empty binary values error. Microsoft SQL Server In-Reply-To: References: Message-ID: Hi Andrey, Andrey Paraskevopulo writes: > After short investigation I think that I?ve found the error. > > [...] > > *buffer = &v.front (); Yes, good catch. Your fix is also good. I have applied a C++98- compatible version of it for the next release: http://scm.codesynthesis.com/?p=odb/libodb-mssql.git;a=commit;h=539b70c28091a7cdfc0abe106102a151f075e6ef We also had the same issue in libodb-oracle, also fixed: http://scm.codesynthesis.com/?p=odb/libodb-oracle.git;a=commit;h=69f440cf8c0bd4a9cce1d97cce2ebb54cee6dd0f Thanks for reporting this! Boris From axel50397 at gmail.com Wed May 27 07:00:06 2015 From: axel50397 at gmail.com (Adnan RIHAN) Date: Wed May 27 07:00:32 2015 Subject: [odb-users] #pragma view pointer() ignored on Windows Message-ID: Hi all ! I have finally finished a first version of my app, and it?s compiling/running very well. I?m on OS X, and I?m trying to compile the app on Windows XP but there are some compilation errors regarding view pointers. Here is how I call query_one() (??T?? being the raw class name): > QSharedPointer ? r; > r = this->m_db->query_one(query); erreur : no match for 'operator=' (operand types are 'QSharedPointer' and 'odb::object_traits::pointer_type {aka offer_view*}') ? ? ? ? ? ? ? ? ?r = this->m_db->query_one(query); ? ? ? ? ? ? ? ? ? ?^ offer_view is defined as: > struct offer_view > { > ? ? OfferSP ? o; > }; >? >?# ? pragma ?db ?view(offer_view) ? ? ? ? ? ?object(Offer) object(Product) object(product_barcode = barcode) ? query(distinct) No matter if I add ??pointer(QSharedPointer)?? or not, still the same error. No matter if I used the OS X-generated *-odb.*xx files on Windows or regenerate them. Plus, I?ve compared ODB generated files from OS X and Windows, they?re identical. Any idea? OSX: - Yosemite (10.10.3) - Qt 5.4.1 x64 - ODB 2.4.0 (from scratch) using gcc-4.9.2 - App compiled with clang Windows: - XP SP3 (on VM) - Qt 5.4.1 32bit - ODB 2.4.0 (precompiled) using MingW 4.9.1 - App compiled with MinGW 4.9.1 (also tested on 4.8.1) Thanks for your help. -- Cordialement, Adnan RIHAN. GPG: 5675-62BA (https://keybase.io/max13/key.asc) -> Si vous n'utilisez pas GPG mais souhaitez quand m?me m?envoyer un e-mail chiffr?: (https://encrypt.to/0x567562BA). From boris at codesynthesis.com Thu May 28 07:24:37 2015 From: boris at codesynthesis.com (Boris Kolpackov) Date: Thu May 28 07:24:43 2015 Subject: [odb-users] #pragma view pointer() ignored on Windows In-Reply-To: References: Message-ID: Hi Adnan, Adnan RIHAN writes: > erreur : no match for 'operator=' (operand types are > 'QSharedPointer' and > 'odb::object_traits::pointer_type {aka offer_view*}') I am pretty sure this is a known bug in the query_one() implementation (notice object_traits; it should be view_traits). Here are two patches that fix it: http://scm.codesynthesis.com/?p=odb/libodb.git;a=commit;h=b119086e8c5835695cd851da8ad1393218aa29df http://scm.codesynthesis.com/?p=odb/libodb.git;a=commit;h=ee4d942916d347ac65f53969941b0fb100760611 Boris From axel50397 at gmail.com Fri May 29 09:34:14 2015 From: axel50397 at gmail.com (Adnan RIHAN) Date: Fri May 29 09:34:41 2015 Subject: [odb-users] #pragma view pointer() ignored on Windows In-Reply-To: References: Message-ID: Hi Boris, Thank your for your answer. Unfortunately, it?s still not working. I?ve tried to apply the patches myself, and clone the git repository, still the exact same error. It?s happening only on Windows, while on OSX there is no error. If it was a patch problem, I would have had the same error on OSX, right? On 28 mai 2015 at 13:24:42, Boris Kolpackov (boris@codesynthesis.com) wrote: Hi Adnan, Adnan RIHAN writes: > erreur : no match for 'operator=' (operand types are > 'QSharedPointer' and > 'odb::object_traits::pointer_type {aka offer_view*}') I am pretty sure this is a known bug in the query_one() implementation (notice object_traits; it should be view_traits). Here are two patches that fix it: http://scm.codesynthesis.com/?p=odb/libodb.git;a=commit;h=b119086e8c5835695cd851da8ad1393218aa29df http://scm.codesynthesis.com/?p=odb/libodb.git;a=commit;h=ee4d942916d347ac65f53969941b0fb100760611 Boris --? Cordialement, Adnan RIHAN. Directeur-G?rant de?Eolis-Software,?soci?t? de services informatiques. GPG:?5675-62BA (https://keybase.io/max13/key.asc) ->?Si vous?n'utilisez?pas GPG mais?souhaitez quand m?me m?envoyer un?e-mail chiffr?: (https://encrypt.to/0x567562BA). From boris at codesynthesis.com Fri May 29 11:11:07 2015 From: boris at codesynthesis.com (Boris Kolpackov) Date: Fri May 29 11:11:12 2015 Subject: [odb-users] #pragma view pointer() ignored on Windows In-Reply-To: References: Message-ID: Hi Adnan, Adnan RIHAN writes: > It?s happening only on Windows, while on OSX there is no error. If > it was a patch problem, I would have had the same error on OSX, right? Yes, that's a valid point. Then it must be some setup issue on Windows. Try the following steps: 1. Confirm that the -odb.hxx file contains the view_traits specialization for the view in question (and it typedef's QSharedPointer as its object_pointer). 2. Make sure that this -odb.hxx file is actually the one that gets found by the compiler. For that, temporarily remove the file and verify that compilation now ends with a compiler error. Boris From axel50397 at gmail.com Fri May 29 14:24:30 2015 From: axel50397 at gmail.com (Adnan RIHAN) Date: Fri May 29 14:24:56 2015 Subject: [odb-users] #pragma view pointer() ignored on Windows In-Reply-To: References: Message-ID: Well... Thank you for giving me some tips... The -odb.hxx are exactly the same, so it?s not there, BUT... I?ve configured Qt-Creator with the following include paths: > C:\ODB\sqlite-3.0\include \ > C:\ODB\odb-2.4.0-i686-windows\mingw\include \ > C:\ODB\libodb-2.4.0\include \ > C:\ODB\libodb-sqlite-2.4.0\include ?\ > C:\ODB\libodb-qt-2.4.0\include Guess what? I thought it would be a good idea to include the ??include?? folder from odb-2.4.0, and it seems using the libodb unpatched files and was loading them instead of the good one. Thank you, sorry for that lack of attention (plus, I?ve included the patches you gave me, in my homebrew packages, so I was aware!) On 29 mai 2015 at 17:11:12, Boris Kolpackov (boris@codesynthesis.com) wrote: Hi Adnan, Adnan RIHAN writes: > It?s happening only on Windows, while on OSX there is no error. If > it was a patch problem, I would have had the same error on OSX, right? Yes, that's a valid point. Then it must be some setup issue on Windows. Try the following steps: 1. Confirm that the -odb.hxx file contains the view_traits specialization for the view in question (and it typedef's QSharedPointer as its object_pointer). 2. Make sure that this -odb.hxx file is actually the one that gets found by the compiler. For that, temporarily remove the file and verify that compilation now ends with a compiler error. Boris --? Cordialement, Adnan RIHAN. Directeur-G?rant de?Eolis-Software,?soci?t? de services informatiques. GPG:?5675-62BA (https://keybase.io/max13/key.asc) ->?Si vous?n'utilisez?pas GPG mais?souhaitez quand m?me m?envoyer un?e-mail chiffr?: (https://encrypt.to/0x567562BA).