From info at peredin.com Sun Sep 1 14:59:48 2013 From: info at peredin.com (Per Edin) Date: Sun Sep 1 14:59:56 2013 Subject: [odb-users] Possible #include bug in generated code Message-ID: Hi, When generating the schema separately in a static multi-database configuration the generated schema source file does not compile. The compiler gives an error about the "invalid use of incomplete type class odb::database'. I discovered that in static mode the generated inline file person-odb.ixx omits to include odb/database.hxx. In dynamic mode the #include-line is present. A workaround is to use --cxx-prologue but a long-term solution would be to make the odb compiler emit #include to the top of person-schema-DB.cxx file directly. ODB commands used: odb --generate-schema --schema-format separate --std c++11 -m static -d common -d pgsql person.hxx odb --generate-schema --schema-format separate --std c++11 -m dynamic -d common -d pgsql person.hxx Replace pgsql with sqlite and the problem remains. None of the separately generated schema source files include odb/database.hxx on their own. /Per From info at peredin.com Sun Sep 1 15:53:46 2013 From: info at peredin.com (Per Edin) Date: Sun Sep 1 15:53:55 2013 Subject: [odb-users] Re: Possible #include bug in generated code In-Reply-To: References: Message-ID: I meant --schema-prologue of course. On Sun, Sep 1, 2013 at 8:59 PM, Per Edin wrote: > Hi, > > When generating the schema separately in a static multi-database > configuration the generated schema source file does not compile. The > compiler gives an error about the "invalid use of incomplete type > class odb::database'. > > I discovered that in static mode the generated inline file > person-odb.ixx omits to include odb/database.hxx. In dynamic mode the > #include-line is present. > > A workaround is to use --cxx-prologue but a long-term solution would > be to make the odb compiler emit > > #include > > to the top of person-schema-DB.cxx file directly. > > ODB commands used: > > odb --generate-schema --schema-format separate --std c++11 -m static > -d common -d pgsql person.hxx > > odb --generate-schema --schema-format separate --std c++11 -m dynamic > -d common -d pgsql person.hxx > > Replace pgsql with sqlite and the problem remains. None of the > separately generated schema source files include odb/database.hxx on > their own. > > /Per From boris at codesynthesis.com Mon Sep 2 07:09:27 2013 From: boris at codesynthesis.com (Boris Kolpackov) Date: Mon Sep 2 07:11:09 2013 Subject: [odb-users] Possible #include bug in generated code In-Reply-To: References: Message-ID: Hi Per, Per Edin writes: > When generating the schema separately in a static multi-database > configuration the generated schema source file does not compile. The > compiler gives an error about the "invalid use of incomplete type > class odb::database'. Known issue, fixed for the next release: http://codesynthesis.com/pipermail/odb-users/2013-July/001480.html Boris From boris at codesynthesis.com Mon Sep 2 08:46:40 2013 From: boris at codesynthesis.com (Boris Kolpackov) Date: Mon Sep 2 08:48:21 2013 Subject: [odb-users] Permanent failure: Cannot start a transaction within a transaction In-Reply-To: References: <5220A144.9000706@videmo.de> Message-ID: Hi Kai, Boris Kolpackov writes: > For now I lean towards just not marking the (ODB) transaction instance > as finalized and let the standard rollback-on-destruction semantics > take care of it. I will let you know when I have a fix ready to try. In the end I've decided to just roll the transaction back if SQLite didn't do it for us automatically. I am lazy to release another bugfix seeing that the next release is imminent. Will you be able to use a patch: http://scm.codesynthesis.com/?p=odb/libodb-sqlite.git;a=commit;h=c3248cd60418cee935508f62a3436970f9d234b2 Boris From nickel at videmo.de Mon Sep 2 09:50:52 2013 From: nickel at videmo.de (Kai Nickel) Date: Mon Sep 2 11:48:20 2013 Subject: [odb-users] Permanent failure: Cannot start a transaction within a transaction In-Reply-To: References: <5220A144.9000706@videmo.de> Message-ID: <522497BC.6040500@videmo.de> Thank you Boris, I can confirm that the patch works! Kai From truthset at gmail.com Mon Sep 2 19:32:15 2013 From: truthset at gmail.com (Jeff Waller) Date: Mon Sep 2 19:32:24 2013 Subject: [odb-users] C++11 with clang on OSX 10.8 In-Reply-To: <424F3946-30B7-4E05-A60F-941EC534F986@gmail.com> References: <007EFA6D-92C3-4861-B3FD-A0E1AF62CE2F@gmail.com> <424F3946-30B7-4E05-A60F-941EC534F986@gmail.com> Message-ID: <9656671C-1504-4319-AB73-C5AC2AEBC8C6@gmail.com> Just as a base of comparison, I have no problems building and linking on OS X 10.7 using clang. However some differences 1) I do not use the packaged odb, but rather generate the source on linux and simply include the generated source as part of the distribution. I don't think this makes any difference, but it's worth mentioning. 2) Version is 2.2.2 3) libodb, libodb-sqllite, libodb-boost are built from source: ./configure CC=clang CXX=clang++, but no other flags. And then of course own project is built once again ./configure CC=clang CXX=clang++ and no other flags 4) and from above, using autotools not cmake Maybe as a test, we could compare link, compile steps? -Jeff On Aug 29, 2013, at 6:03 AM, Philipp Maluta wrote: > Ok, I built all the libs with the flags you mentioned. > Still I have linker errors about absent symbols > > Undefined symbols for architecture x86_64: > "odb::sqlite::delete_statement::delete_statement(odb::sqlite::connection&, std::__1::basic_string, std::__1::allocator > const&, odb::sqlite::binding&)", referenced from: > odb::access::object_traits_impl::erase_query(odb::database&, odb::sqlite::query_base const&) in NoteEntity-odb.cxx.o > "odb::sqlite::select_statement::select_statement(odb::sqlite::connection&, std::__1::basic_string, std::__1::allocator > const&, odb::sqlite::binding&, odb::sqlite::binding&)", referenced from: > odb::access::object_traits_impl::query(odb::database&, odb::sqlite::query_base const&) in NoteEntity-odb.cxx.o > "odb::sqlite::default_value_traits, std::__1::allocator >, (odb::sqlite::database_type_id)2>::set_image(odb::details::basic_buffer&, unsigned long&, bool&, std::__1::basic_string, std::__1::allocator > const&)", referenced from: > odb::access::object_traits_impl::init(odb::access::object_traits_impl::image_type&, NoteEntity const&, odb::sqlite::statement_kind) in NoteEntity-odb.cxx.o > ld: symbol(s) not found for architecture x86_64 > > Maybe the cmake file helps to find any clue. > > cmake_minimum_required(VERSION 2.8.8) > project(NotesCore) > set(PROJECT_NAME_STR NotesCore) > aux_source_directory(src SRC_LIST) > > add_definitions(-Wall -ansi -Wno-deprecated -pthread --std=c++11 --stdlib=libc++) > > set(COMMON_INCLUDES ${PROJECT_SOURCE_DIR}/include) > set(EXT_PROJECTS_DIR ${PROJECT_SOURCE_DIR}/ext) > set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} --std=c++11 --stdlib=libc++") > set(ODB_HEADERS ${COMMON_INCLUDES}/NoteEntity.hpp) > > include_directories(${COMMON_INCLUDES}) > include_directories(SYSTEM /opt/local/include) > add_library(${PROJECT_NAME} STATIC ${SRC_LIST}) > > #------------------- > # Test > #------------------- > > enable_testing() > set(GTEST_USE_OWN_TR1_TUPLE 1) > set(PROJECT_TEST_NAME ${PROJECT_NAME_STR}_test) > include_directories(${GTEST_INCLUDE_DIRS} ${COMMON_INCLUDES}) > add_definitions(-Wall -ansi -Wno-deprecated -pthread --std=c++11 --stdlib=libc++ ) > file(GLOB TEST_SRC_FILES ${PROJECT_SOURCE_DIR}/test/*.cpp) > > find_library(ODB_LIB odb ${EXT_PROJECTS_DIR}) > find_library(ODB_SQLITE_LIB odb-sqlite ${EXT_PROJECTS_DIR} ) > find_library(GMOCK_LIB gmock ${EXT_PROJECTS_DIR}) > find_library(GTEST_LIB gtest ${EXT_PROJECTS_DIR}) > > add_executable(${PROJECT_TEST_NAME} ${TEST_SRC_FILES} ${SRC_LIST}) > > target_link_libraries(${PROJECT_TEST_NAME} pthread) > target_link_libraries(${PROJECT_TEST_NAME} ${ODB_SQLITE_LIB}) > target_link_libraries(${PROJECT_TEST_NAME} ${ODB_LIB}) > target_link_libraries(${PROJECT_TEST_NAME} ${SQLITE_LIB}) > target_link_libraries(${PROJECT_TEST_NAME} ${GMOCK_LIB}) > target_link_libraries(${PROJECT_TEST_NAME} ${GTEST_LIB}) > > add_test( AuthLayerTest ${PROJECT_TEST_NAME} ) > > > So, here is lib to build and a target to test it. To the test target I link guest and gmock. So, may that libs conflict? gmock and gtest also built with --std=c++11 and --stdlib=libc++ > > > > 27 ???. 2013, ? 21:02, Boris Kolpackov ???????(?): > >> Hi Philipp, >> >> Boris Kolpackov writes: >> >>> If you are seeing this when building libodb, then you may want to >>> change the configure command line like this in order to try to >>> address the first possibility: >>> >>> ./configure CXX="clang++ --std=c++11 --stdlib=libc++" --prefix=/opt/local --disable-threads >> >> And if that still doesn't help, then build libodb (and libodb-sqlite) >> as static libraries: >> >> ./configure CXX=clang++ CXXFLAGS="--std=c++11 --stdlib=libc++" --disable-shared ... >> >> Boris >> >> > From boris at codesynthesis.com Tue Sep 3 07:36:59 2013 From: boris at codesynthesis.com (Boris Kolpackov) Date: Tue Sep 3 07:38:41 2013 Subject: [odb-users] C++11 with clang on OSX 10.8 In-Reply-To: <424F3946-30B7-4E05-A60F-941EC534F986@gmail.com> References: <007EFA6D-92C3-4861-B3FD-A0E1AF62CE2F@gmail.com> <424F3946-30B7-4E05-A60F-941EC534F986@gmail.com> Message-ID: Hi Philipp, Philipp Maluta writes: > Ok, I built all the libs with the flags you mentioned. You mean you built libodb and libodb-sqlite as static libraries, right? > Still I have linker errors about absent symbols All the missing symbols have std::string in their signatures, so it has to do with a different standard library "seen" when building libodb-sqlite and your application. Also, I assume you made sure that Clang actually works with these options (--std=c++11 --stdlib=libc++) e.g., by building other programs or a test? > Maybe the cmake file helps to find any clue. Try to build a test executable manually, from the command line. For instance, try to build the 'hello' example from the odb-examples package like this: odb -d sqlite -q --std=c++11 person.hxx clang++ --std=c++11 --stdlib=libc++ -c person-odb.cxx clang++ --std=c++11 --stdlib=libc++ -DDATABASE_MYSQL -c driver.cxx clang++ --std=c++11 --stdlib=libc++ -o driver driver.o person-odb.o -lodb-sqlite -lodb Boris From fil.the.ensoreus at gmail.com Tue Sep 3 08:17:58 2013 From: fil.the.ensoreus at gmail.com (Philipp Maluta) Date: Tue Sep 3 08:23:36 2013 Subject: [odb-users] C++11 with clang on OSX 10.8 In-Reply-To: References: <007EFA6D-92C3-4861-B3FD-A0E1AF62CE2F@gmail.com> <424F3946-30B7-4E05-A60F-941EC534F986@gmail.com> Message-ID: <654D3B18-8C73-4ED8-95CF-8D22B295A658@gmail.com> Thank you,Boris. At a time I rolled back to C++98 and it works.So, the problem discarded now and if there will necessary to switch to C++11, I'll check up your advices. ????????? ? iPhone 3 ????. 2013 ? 14:36 Boris Kolpackov ???????(??): > Hi Philipp, > > Philipp Maluta writes: > >> Ok, I built all the libs with the flags you mentioned. > > You mean you built libodb and libodb-sqlite as static libraries, right? > > >> Still I have linker errors about absent symbols > > All the missing symbols have std::string in their signatures, so it > has to do with a different standard library "seen" when building > libodb-sqlite and your application. > > Also, I assume you made sure that Clang actually works with these > options (--std=c++11 --stdlib=libc++) e.g., by building other > programs or a test? > > >> Maybe the cmake file helps to find any clue. > > Try to build a test executable manually, from the command line. For > instance, try to build the 'hello' example from the odb-examples > package like this: > > odb -d sqlite -q --std=c++11 person.hxx > clang++ --std=c++11 --stdlib=libc++ -c person-odb.cxx > clang++ --std=c++11 --stdlib=libc++ -DDATABASE_MYSQL -c driver.cxx > clang++ --std=c++11 --stdlib=libc++ -o driver driver.o person-odb.o -lodb-sqlite -lodb > > Boris From GPrashanth at prosolartec.de Fri Sep 6 07:03:13 2013 From: GPrashanth at prosolartec.de (Gunjur Munireddy Prashanth / LOKISA Smart Energy GmbH) Date: Fri Sep 6 07:03:19 2013 Subject: [odb-users] Native query error Message-ID: <7D6CC34E75B8C248B39B210FC1494C0048A2AA@exchange.prosolar1.local> Hello , I am using native sql query to get the average of a column and I get the average has 1.0000 Below is the snippet float avg = db->execute("SELECT AVG(mod_il2) FROM OddDay"); syslog(LOG_NOTICE, "mod il1 avg = %.2f ", avg); in sysylog data I get mod il1 avg = 1.00 the below statement executes fine and I am able to delete all the data from the table db->execute("DELETE FROM EvenDay"); Can anyone tell me what could be the possible mistake I might have done ?? Thanks!! From boris at codesynthesis.com Fri Sep 6 07:38:29 2013 From: boris at codesynthesis.com (Boris Kolpackov) Date: Fri Sep 6 07:40:09 2013 Subject: [odb-users] Native query error In-Reply-To: <7D6CC34E75B8C248B39B210FC1494C0048A2AA@exchange.prosolar1.local> References: <7D6CC34E75B8C248B39B210FC1494C0048A2AA@exchange.prosolar1.local> Message-ID: Hi Gunjur, Gunjur Munireddy Prashanth / LOKISA Smart Energy GmbH writes: > I am using native sql query to get the average of a column and I get > the average has 1.0000 > > float avg = db->execute("SELECT AVG(mod_il2) FROM OddDay"); For SELECT the database::execute() function returns the number of rows selected. You are expecting it to return the first column from the first row. To handle a query like this with ODB you will need to use a view. For example: #pragma db view query("SELECT AVG(mod_il2) FROM OddDay") struct OddDay_mod_il2_avg { float value; }; float avg = db->query ().begin ()->value; For more information on views, see Chapter 9, "Views" in the ODB Manual. Boris From GPrashanth at prosolartec.de Fri Sep 6 08:48:40 2013 From: GPrashanth at prosolartec.de (Gunjur Munireddy Prashanth / LOKISA Smart Energy GmbH) Date: Fri Sep 6 08:48:45 2013 Subject: [odb-users] Native query error In-Reply-To: References: <7D6CC34E75B8C248B39B210FC1494C0048A2AA@exchange.prosolar1.local> Message-ID: <7D6CC34E75B8C248B39B210FC1494C0048A2C7@exchange.prosolar1.local> Hello Boris, Thank you, Sorry, I could not understand completely Can you explain what this line does exactly float avg = db->query ().begin ()->value; -----Original Message----- From: Boris Kolpackov [mailto:boris@codesynthesis.com] Sent: Freitag, 6. September 2013 13:38 To: Gunjur Munireddy Prashanth / LOKISA Smart Energy GmbH Cc: odb-users@codesynthesis.com Subject: Re: [odb-users] Native query error Hi Gunjur, Gunjur Munireddy Prashanth / LOKISA Smart Energy GmbH writes: > I am using native sql query to get the average of a column and I get > the average has 1.0000 > > float avg = db->execute("SELECT AVG(mod_il2) FROM OddDay"); For SELECT the database::execute() function returns the number of rows selected. You are expecting it to return the first column from the first row. To handle a query like this with ODB you will need to use a view. For example: #pragma db view query("SELECT AVG(mod_il2) FROM OddDay") struct OddDay_mod_il2_avg { float value; }; float avg = db->query ().begin ()->value; For more information on views, see Chapter 9, "Views" in the ODB Manual. Boris ----- E-Mail ist virenfrei. Von AVG ?berpr?ft - www.avg.de Version: 2013.0.3392 / Virendatenbank: 3222/6641 - Ausgabedatum: 05.09.2013 From boris at codesynthesis.com Fri Sep 6 13:56:06 2013 From: boris at codesynthesis.com (Boris Kolpackov) Date: Fri Sep 6 13:57:47 2013 Subject: [odb-users] Native query error In-Reply-To: <7D6CC34E75B8C248B39B210FC1494C0048A2C7@exchange.prosolar1.local> References: <7D6CC34E75B8C248B39B210FC1494C0048A2AA@exchange.prosolar1.local> <7D6CC34E75B8C248B39B210FC1494C0048A2C7@exchange.prosolar1.local> Message-ID: Hi Gunjur, Gunjur Munireddy Prashanth / LOKISA Smart Energy GmbH writes: > Can you explain what this line does exactly > > float avg = db->query ().begin ()->value; Well, that's a shortcut for running a query, getting the result, and then iterating over it. Here are these three steps performed separately: typedef odb::result result; result r = db->query (); result::iterator i (r.begin ()); float avg = i->value; Because we know there will be exactly one element in the result set, we can use the shortcut version I showed earlier. You can read more about queries, result, etc., in Chapter 4, "Querying the Database" in the ODB manual. Boris From cort.tompkins at ipconfigure.com Sun Sep 8 23:05:22 2013 From: cort.tompkins at ipconfigure.com (R. Cortland Tompkins) Date: Sun Sep 8 23:06:00 2013 Subject: [odb-users] Mapping a templated wrapper class Message-ID: Hello, I made a templated wrapper class to facilitate persisting boost-serializable objects. My wrapper class maintains the object and a text archive serialization of the object, and has logic to track changes and keep the two in sync. I initially attempted to specialize value_traits for my templated wrapper, but the callbacks for the id_long_string type in MSSQL scared me off. :) At this point I was trying to serialize/deserialize on-the-fly without maintaining a text archive in my wrapper, and there did not appear to be an obvious or non-trivial way to put serialization/deserialization hooks into the get_image/set_image methods since the callbacks that effect the get/set are invoked after those functions return. Failing that, I made my wrapper change-tracking and moved the serialization/deserialization logic into its accessors, then followed the example of boost::optional<> in libodb-boost to create a wrapper_traits specialization whose wrapped_type is always std::string (the text archive) regardless of the template parameter. This method seems cleaner than my first attempt, but things get less tidy when I have to map to DB types. I made a profile for my wrapper, with per-database option files to add #pragma mapping headers to the appropriate prologues. I was hoping I could map my generic wrapper class to the various "TEXT" DB types (independent of the template parameter as described above), but it seems this is not possible. As a work-around, I have typedef'd a template specialization for each of the wrapped serializable class types I intend to use, and mapped each of these separately in each mapping file. This works but is obviously a bit fiddly. Is there a way that would avoid a priori enumeration in the mapping headers of all the serializable types I use? Revisiting my first attempt, would a value_traits specialized for my templated wrapper class and the appropriate DB type eliminate the need for #pragma type definitions? Thanks, Cort Tompkins From boris at codesynthesis.com Mon Sep 9 05:59:08 2013 From: boris at codesynthesis.com (Boris Kolpackov) Date: Mon Sep 9 06:00:47 2013 Subject: [odb-users] Mapping a templated wrapper class In-Reply-To: References: Message-ID: Hi Cort, R. Cortland Tompkins writes: > I initially attempted to specialize value_traits for my templated wrapper, > but the callbacks for the id_long_string type in MSSQL scared me off. :) Yes, those can be a bit intimidating ;-). > At this point I was trying to serialize/deserialize on-the-fly without > maintaining a text archive in my wrapper, and there did not appear to be an > obvious or non-trivial way to put serialization/deserialization hooks into > the get_image/set_image methods since the callbacks that effect the get/set > are invoked after those functions return. You can probably make it work since the callbacks allow you to detect the first/last calls. You could then pass your wrapper as the callback argument and trigger its serialization/deserialization. > Failing that, I made my wrapper change-tracking and moved the > serialization/deserialization logic into its accessors, then followed the > example of boost::optional<> in libodb-boost to create a wrapper_traits > specialization whose wrapped_type is always std::string (the text archive) > regardless of the template parameter. That's pretty neat. > I was hoping I could map my generic wrapper class to the various "TEXT" > DB types (independent of the template parameter as described above), but > it seems this is not possible. I don't think you actually need to provide any mapping at all since ODB, after not finding any type specification for your wrapper type, will look for one for wrapped_type. And since it is std::string, it will automatically map it to TEXT. Now you may still want to customize the TEXT type used for your wrapper (e.g., to make it large/small enough to hold your data) but without changing the default mapping for std::string. The easiest way to accomplish this would probably be to provide your own string type and map it as you wish: struct wrapper_data: std::string { ... }; #pragma db value(wrapper_data) mssql:type("VARCHAR(1024)") In this case you would need to also provide the value_traits specialization for wrapper_data (including those callbacks for MSSQL). You can, however, simply delegate to the std::string implementation and reuse all the code (including the callbacks). Or, you could implement your own and do the on-the-fly serialization/deserialization (I think you can still delegate to the std::string callbacks even in this case). Boris From grasmanek94 at gmail.com Mon Sep 9 11:57:21 2013 From: grasmanek94 at gmail.com (Rafal Gm) Date: Mon Sep 9 13:14:11 2013 Subject: [odb-users] Dynamic Database usage for scripting? Message-ID: I would like to bind a scripting language to my application and somehow expose the ODB features. But this means that the script would only have a static database (because the ODB compiler generates a .cpp and .h) file. How would I design a class that at the same time works with odb and can be used to provide enough dynamic-ality (sorry bad english) for a scripting language? What's compiled is compiled and can't be changed. and a script can always be reloaded, For example the script could use it's own colums which are not in the C++ compiled code. So the big question is.. is this even possible with ODB? ODB is really powerfull and if I could mary it.. I would hehe. And I understand there are limits, but maybe? I have some hope this is possible and if not then no need to waste my time trying to do that :) Thanks in advance for your time and responses! From boris at codesynthesis.com Mon Sep 9 13:32:12 2013 From: boris at codesynthesis.com (Boris Kolpackov) Date: Mon Sep 9 13:33:51 2013 Subject: [odb-users] Dynamic Database usage for scripting? In-Reply-To: References: Message-ID: Hi Rafal, Rafal Gm writes: > I would like to bind a scripting language to my application and somehow > expose the ODB features. I think it is useful to distinguish between these two cases: 1. Exposing an ODB-persistent C++ class(es) to a scripting language. This should be fairly straightforward since, in a nutshell, all ODB does is add database persistence support to a plain C++ class. Though, admittedly, things get trickier if you also want to be able to construct and run arbitrary queries from a scripting language (native queries are probably the best option here). 2. Expose the ODB functionality itself to a scripting language. That is, allow "classes" as defined in a scripting language to be persisted via ODB. This will be a lot harder and it is probably a better idea to use an ORM designed for that scripting language specifically. It seems to me you are after some variant of #2. > How would I design a class that at the same time works with odb and can be > used to provide enough dynamic-ality (sorry bad english) for a scripting > language? What's compiled is compiled and can't be changed. and a script > can always be reloaded, For example the script could use it's own colums > which are not in the C++ compiled code. Well, just one idea: instead of having normal data members, your class data could be defined as a set of name-value pairs: #pragma db object class dynamic_object { std::map data; }; Then the script can do all sorts of "dynamic" things with the data (e.g., add new "columns", discover existing ones, etc). Boris From cort.tompkins at ipconfigure.com Mon Sep 9 22:16:15 2013 From: cort.tompkins at ipconfigure.com (R. Cortland Tompkins) Date: Mon Sep 9 22:16:53 2013 Subject: [odb-users] Mapping a templated wrapper class In-Reply-To: References: Message-ID: > You can probably make it work since the callbacks allow you to detect > the first/last calls. You could then pass your wrapper as the callback > argument and trigger its serialization/deserialization. On second appraisal the callbacks were much more tractable than I had initially realized. I modified my approach to serialize/deserialize on-the-fly, went back to using value_traits instead of wrapper_traits, and modified the MS and Oracle callbacks as required. On-the-fly serialization is an improvement, but the ODB compiler still cannot map my wrapper type automatically. E.g.: unable to map C++ type '::archiveable<::boost::property_tree::basic_ptree< ::std::basic_string< char >, ::std::basic_string< char > > >' used in data member 'ptree_'. Perhaps the ODB compiler fails because my value_traits specializations are only partial specializations? E.g.: template struct odb::sqlite::default_value_traits, id_text> Thanks, Cort Tompkins From grasmanek94 at gmail.com Mon Sep 9 16:17:44 2013 From: grasmanek94 at gmail.com (Rafal Gm) Date: Tue Sep 10 08:13:18 2013 Subject: [odb-users] Dynamic Database usage for scripting? In-Reply-To: References: Message-ID: hm, that dynamic class thing sound all-right, I'm just wondering know, because ODB will create the table "dynamic_object" for that class, but would it be possile to use one class for multiple tables? If yes how would I specify that? 2013/9/9 Boris Kolpackov > Hi Rafal, > > Rafal Gm writes: > > > I would like to bind a scripting language to my application and somehow > > expose the ODB features. > > I think it is useful to distinguish between these two cases: > > 1. Exposing an ODB-persistent C++ class(es) to a scripting language. This > should be fairly straightforward since, in a nutshell, all ODB does is > add database persistence support to a plain C++ class. Though, > admittedly, > things get trickier if you also want to be able to construct and run > arbitrary queries from a scripting language (native queries are probably > the best option here). > > 2. Expose the ODB functionality itself to a scripting language. That is, > allow "classes" as defined in a scripting language to be persisted via > ODB. This will be a lot harder and it is probably a better idea to use > an ORM designed for that scripting language specifically. > > It seems to me you are after some variant of #2. > > > > How would I design a class that at the same time works with odb and can > be > > used to provide enough dynamic-ality (sorry bad english) for a scripting > > language? What's compiled is compiled and can't be changed. and a script > > can always be reloaded, For example the script could use it's own colums > > which are not in the C++ compiled code. > > Well, just one idea: instead of having normal data members, your class > data could be defined as a set of name-value pairs: > > #pragma db object > class dynamic_object > { > std::map data; > }; > > Then the script can do all sorts of "dynamic" things with the data (e.g., > add new "columns", discover existing ones, etc). > > Boris > From boris at codesynthesis.com Tue Sep 10 08:20:06 2013 From: boris at codesynthesis.com (Boris Kolpackov) Date: Tue Sep 10 08:21:46 2013 Subject: [odb-users] Dynamic Database usage for scripting? In-Reply-To: References: Message-ID: Hi Rafal, Rafal Gm writes: > I'm just wondering know, because ODB will create the table > "dynamic_object" for that class, but would it be possile to > use one class for multiple tables? No. But seeing that you've converted the column name to a string, nothing prevents you from also converting the table name: #pragma db object struct name { std::string table; std::string column; }; #pragma db object class dynamic_object { std::map data; }; Things will still be stored in a single table, though. Boris From boris at codesynthesis.com Tue Sep 10 08:35:42 2013 From: boris at codesynthesis.com (Boris Kolpackov) Date: Tue Sep 10 08:37:20 2013 Subject: [odb-users] Mapping a templated wrapper class In-Reply-To: References: Message-ID: Hi Cort, R. Cortland Tompkins writes: > [...] went back to using value_traits instead of wrapper_traits, > and modified the MS and Oracle callbacks as required. > > On-the-fly serialization is an improvement, but the ODB compiler still > cannot map my wrapper type automatically. ODB won't be able to do it with the value_traits approach. That is, there is no support for mapping type templates, only types. The wrapper (in ODB sense) trick worked because ODB, after not finding the type specification for the wrapper itself (which is a template), will then look if there is one for the wrapped type (which is not a template). You can still make it work by combining the two approaches. Here is an outline: #pragma db value type("TEXT") class archiveable_base { public: virtual std::string serialize () const = 0; virtual void deserialize (const std::string&) = 0; }; // Provide the value_traits specialization // using serialize()/deserialize() to get/set data. template class archiveable: public archiveable_base { public: ... // Implement these. // virtual std::string serialize () const; virtual void deserialize (const std::string&); }; // Provide wrapper_traits partial specialization for archiveable. Note // the wrapped_type typedef. // namespace odb { template class wrapper_traits > { public: typedef archiveable_base wrapped_type; typedef archiveable_base unrestricted_wrapped_type; typedef archiveable wrapper_type; static const bool null_handler = false; static const bool null_default = false; static const wrapped_type& get_ref (const wrapper_type& o) { return o; // Implicit conversion from derived to base. } static unrestricted_wrapped_type& set_ref (wrapper_type& o) { return o; // Implicit conversion from derived to base. } }; } Boris From wanghuisoftware at 126.com Tue Sep 10 09:12:05 2013 From: wanghuisoftware at 126.com (=?GBK?B?zfW71A==?=) Date: Tue Sep 10 09:12:22 2013 Subject: [odb-users] ask a question Message-ID: <76b66e7d.29bd9.14108001593.Coremail.wanghuisoftware@126.com> hello , i want to know how to create an odb view based on database view. like this #pragma db object(DDDD) view(v_DDDD)? thanks very much! From boris at codesynthesis.com Wed Sep 11 06:04:55 2013 From: boris at codesynthesis.com (Boris Kolpackov) Date: Wed Sep 11 06:06:32 2013 Subject: [odb-users] ask a question In-Reply-To: <76b66e7d.29bd9.14108001593.Coremail.wanghuisoftware@126.com> References: <76b66e7d.29bd9.14108001593.Coremail.wanghuisoftware@126.com> Message-ID: Hi, wanghuisoftware@126.com writes: > i want to know how to create an odb view based on database view. When it comes to ODB views, there is no difference between database tables and database views since they can be queried in exactly the same way. So to create an ODB view based on a database view you will use the table syntax: #pragma db view table("my_view") struct my_view { #pragma db column("col1") type("INTEGER") unsigned long val1; #pragma db column("col2") type("TEXT") std::string val2; }; For more information, see Section 9.2, "Table Views". It is also possible to create a native ODB view based a database view (Section 9.5, "Native Views"). Boris From wanghuisoftware at 126.com Wed Sep 11 06:51:00 2013 From: wanghuisoftware at 126.com (=?GBK?B?zfW71A==?=) Date: Wed Sep 11 06:51:06 2013 Subject: [odb-users] ask a question In-Reply-To: References: <76b66e7d.29bd9.14108001593.Coremail.wanghuisoftware@126.com> Message-ID: <6a231be1.8e2b.1410ca547af.Coremail.wanghuisoftware@126.com> Thanks a lot for your answer! From wanghuisoftware at 126.com Wed Sep 11 07:22:54 2013 From: wanghuisoftware at 126.com (=?GBK?B?zfW71A==?=) Date: Wed Sep 11 07:23:02 2013 Subject: [odb-users] ask a question In-Reply-To: References: <76b66e7d.29bd9.14108001593.Coremail.wanghuisoftware@126.com> Message-ID: <645b3a2e.9096.1410cc27e05.Coremail.wanghuisoftware@126.com> if i use "#pragma db view(SPSDAO::SpsIndividual) table("v_Individuals") readonly" it generate error " ??: ?? "v_Individuals" ???"?but it actually existed. At 2013-09-11 18:04:55,"Boris Kolpackov" wrote: >Hi, > >wanghuisoftware@126.com writes: > >> i want to know how to create an odb view based on database view. > >When it comes to ODB views, there is no difference between database >tables and database views since they can be queried in exactly the >same way. So to create an ODB view based on a database view you will >use the table syntax: > >#pragma db view table("my_view") >struct my_view >{ > #pragma db column("col1") type("INTEGER") > unsigned long val1; > > #pragma db column("col2") type("TEXT") > std::string val2; >}; > >For more information, see Section 9.2, "Table Views". It is also >possible to create a native ODB view based a database view (Section >9.5, "Native Views"). > >Boris From boris at codesynthesis.com Thu Sep 12 05:06:42 2013 From: boris at codesynthesis.com (Boris Kolpackov) Date: Thu Sep 12 05:08:17 2013 Subject: [odb-users] ask a question In-Reply-To: <645b3a2e.9096.1410cc27e05.Coremail.wanghuisoftware@126.com> References: <76b66e7d.29bd9.14108001593.Coremail.wanghuisoftware@126.com> <645b3a2e.9096.1410cc27e05.Coremail.wanghuisoftware@126.com> Message-ID: Hi, wanghuisoftware@126.com writes: > if i use "#pragma db view(SPSDAO::SpsIndividual) table("v_Individuals") > readonly" > > it generate error "[Error: Relations "v_Individuals" does not exist]", but > it actually existed. I am guessing you are using PostgreSQL and this is most likely a capitalization issue. When you create a view like this: CREATE VIEW v_Individuals ... The actual view created is called v_individuals. At the same time, ODB always quotes all the database identifiers so the SELECT statement issued for your view will be: SELECT ... FROM "v_Individuals" ... As a result, you either need to quote the name when creating the view: CREATE VIEW "v_Individuals" ... Or use the lower-case name in the pragma: #pragma db view(SPSDAO::SpsIndividual) table("v_individuals") Boris From amit.danziger at gmail.com Sun Sep 15 07:37:20 2013 From: amit.danziger at gmail.com (Amit Danziger) Date: Sun Sep 15 07:37:29 2013 Subject: [odb-users] Question - using ODB with g++ 3.2.3 Message-ID: Officially ODB is supported with g++ 4.2.x - 4.7.x. I am aware of this. But unfortunately I am using RHEL 3 which includes g++ (GCC) 3.2.3 (Red Hat Linux 3.2.3-20). Does anyone have any idea whether I could use ODB with an old compiler? Any specific issues/features I should check? Thank you, Amit. From davejohansen at gmail.com Sun Sep 15 11:44:04 2013 From: davejohansen at gmail.com (Dave Johansen) Date: Sun Sep 15 11:44:11 2013 Subject: [odb-users] Question - using ODB with g++ 3.2.3 In-Reply-To: References: Message-ID: On Sun, Sep 15, 2013 at 4:37 AM, Amit Danziger wrote: > Officially ODB is supported with g++ 4.2.x - 4.7.x. > I am aware of this. But unfortunately I am using RHEL 3 which includes g++ > (GCC) 3.2.3 (Red Hat Linux 3.2.3-20). > > Does anyone have any idea whether I could use ODB with an old compiler? > Any specific issues/features I should check? libodb and the code generated by the ODB compiler support g++ 4.2 and greater, but the ODB compiler itself requires plugin support which is only available in g++ 4.5 and greater. I'm working on getting ODB packages setup as part of the EPEL for RHEL 5/6, but that probably won't help out much with RHEL 3 since the devtoolset that I'm using to be build it ( https://access.redhat.com/site/documentation/Red_Hat_Developer_Toolset/ ) is only available for RHEL 5/6. From boris at codesynthesis.com Mon Sep 16 04:23:34 2013 From: boris at codesynthesis.com (Boris Kolpackov) Date: Mon Sep 16 04:25:15 2013 Subject: [odb-users] Question - using ODB with g++ 3.2.3 In-Reply-To: References: Message-ID: Hi Amit, Amit Danziger writes: > Officially ODB is supported with g++ 4.2.x - 4.7.x. > I am aware of this. But unfortunately I am using RHEL 3 which includes g++ > (GCC) 3.2.3 (Red Hat Linux 3.2.3-20). > > Does anyone have any idea whether I could use ODB with an old compiler? > Any specific issues/features I should check? To add to what Dave already said, for building ODB-based applications officially we only support g++ 4.2 and up. By officially I mean we make sure every test in the ODB test suite compiles and runs fine with this version, for every release. You may be able to get away with g++ 3.4 seeing that we managed to support VC++ 8. But I doubt 3.2 will work, it is just too old. Also, as Dave mentioned, the ODB compiler has even stricter g++ requirements (4.5 and up). But you could always generate the code on a newer box and then copy it over and compile on EL3. Not ideal but workable. Boris From durga.disc at gmail.com Sun Sep 29 07:17:26 2013 From: durga.disc at gmail.com (dd) Date: Sun Sep 29 07:17:54 2013 Subject: [odb-users] person.sql Message-ID: Hi, I am trying compile hello world example for sqlite. odb -d sqlite --genrate-query person.hxx I tried to generate person.sql with above command. It didn't create. How to create? Thanks. From Paul.Harrison at manchester.ac.uk Sun Sep 29 12:53:15 2013 From: Paul.Harrison at manchester.ac.uk (Paul Harrison) Date: Sun Sep 29 12:53:19 2013 Subject: [odb-users] template ambiguity with gcc4.8 Message-ID: Hi, we have some code that compiles fine with gcc4.2 and gcc4.4, but with gcc4.8 we get In file included from /home/rgn/develop/emer/branches/newpersist/emerlin/include/configs_db/tel_configs_db.h:20:0, from /home/rgn/develop/emer/branches/newpersist/emerlin/include/emerlin_msgs/band_table.h:15, from /home/rgn/develop/emer/branches/newpersist/emerlin/emerlin_msgs/source/band_table.C:9: /home/rgn/develop/emer/branches/newpersist/emerlin/include/persist2/odb_lib_impl.h: In instantiation of ?void ODB_Library::update_collection(boost::shared_ptr&, std::list >&, std::list >&) [with P = Band_Table_Entry_P; C = Local_Oscillator_P]?: /home/rgn/develop/emer/branches/newpersist/emerlin/emerlin_msgs/source/band_table.C:576:59: required from here /home/rgn/develop/emer/branches/newpersist/emerlin/include/persist2/odb_lib_impl.h:203:9: error: call of overloaded ?erase(const boost::shared_ptr&)? is ambiguous _database->erase(*i); ^ /home/rgn/develop/emer/branches/newpersist/emerlin/include/persist2/odb_lib_impl.h:203:9: note: candidates are: In file included from /usr/local/include/odb/mysql/database.hxx:440:0, from /home/rgn/develop/emer/branches/newpersist/emerlin/include/persist2/odb_lib.h:24, from /home/rgn/develop/emer/branches/newpersist/emerlin/include/persist2/odb_lib_impl.h:11, from /home/rgn/develop/emer/branches/newpersist/emerlin/include/configs_db/tel_configs_db.h:20, from /home/rgn/develop/emer/branches/newpersist/emerlin/include/emerlin_msgs/band_table.h:15, from /home/rgn/develop/emer/branches/newpersist/emerlin/emerlin_msgs/source/band_table.C:9: /usr/local/include/odb/mysql/database.ixx:280:17: note: void odb::mysql::database::erase(const P&) [with T = Local_Oscillator_P; P = boost::shared_ptr] inline void database:: ^ /usr/local/include/odb/mysql/database.ixx:326:17: note: void odb::mysql::database::erase(const typename odb::object_traits::pointer_type&) [with T = Local_Oscillator_P; typename odb::object_traits::pointer_type = boost::shared_ptr] inline void database:: ^ The code that is doing the calling is //remove values for(typename std::set >::iterator i = rem.begin(); i != rem.end(); ++i){ _database->erase(*i); } itself a template, but with the shared pointer declared with using boost::shared_ptr; At first sight gcc4.8 is correct - these erase functions in odb/mysql/database.hxx do end up being ambiguous with the given template parameters - which makes me wonder how this gets past earlier gcc versions - is there a trick to resolve the ambiguity when calling, because I have to admit that I cannot think of one. (Apart from a workaround of calling erase with the an object reference, or object Id - this is the only place in our code where erase is called with smart pointer to the object). Regards, Paul Harrison From boris at codesynthesis.com Mon Sep 30 03:58:00 2013 From: boris at codesynthesis.com (Boris Kolpackov) Date: Mon Sep 30 04:00:24 2013 Subject: [odb-users] template ambiguity with gcc4.8 In-Reply-To: References: Message-ID: Hi Paul, Paul Harrison writes: > The code that is doing the calling is > > for(typename std::set >::iterator i = rem.begin(); i != rem.end(); ++i){ > _database->erase(*i); > } You only need to specify the object type explicitly if erasing by object id. If you don't specify the type, then the second version of erase() will never be considered and you will not get the ambiguity: _database->erase(*i) Boris From boris at codesynthesis.com Mon Sep 30 04:02:54 2013 From: boris at codesynthesis.com (Boris Kolpackov) Date: Mon Sep 30 04:05:17 2013 Subject: [odb-users] person.sql In-Reply-To: References: Message-ID: Hi, dd writes: > I am trying compile hello world example for sqlite. > > odb -d sqlite --genrate-query person.hxx > > I tried to generate person.sql with above command. It didn't create. How > to create? You need to pass the --generate-schema (or -s, for short) option. Also, for SQLite, by default, the schema creation statements are embedded into the generated C++ code. If you want the schema to be generated as standalone .sql file, then you will also need to pass the '--schema-format sql' option. BTW, all this is covered in the ODB compiler command line manual (man pages): http://www.codesynthesis.com/products/odb/doc/odb.xhtml Boris