From dieter.govaerts at bricsys.com Fri Dec 2 03:52:57 2016 From: dieter.govaerts at bricsys.com (Dieter Govaerts) Date: Fri Dec 2 03:53:04 2016 Subject: [odb-users] Joining underscore for column pragma on composite values Message-ID: <1480668777.942911586@apps.rackspace.com> Hello, It's a small thing but I was wondering whether there is a way to avoid the joining underscore between the specified column pragma on a composite value and its member names. I would like it to be a $-sign instead. #pragma db value class name { std::string first_; std::string last_; }; #pragma db object class person { #pragma db column("person$") name name_; }; Above example results in a column named "person$_first" instead of my preferred "person$first". It's just because we aggreed unpon such scheme with the other team. Best regards, Dieter From tomstoffer at gmail.com Fri Dec 2 07:37:45 2016 From: tomstoffer at gmail.com (Tom Stoffer) Date: Fri Dec 2 07:38:01 2016 Subject: [odb-users] Re: odb-users Digest, Vol 75, Issue 9 In-Reply-To: <201611201700.uAKH03Mx028010@codesynthesis.com> References: <201611201700.uAKH03Mx028010@codesynthesis.com> Message-ID: <734CD6E6-454F-4406-AA07-46AB04F0F4C5@gmail.com> Help > On 20 Nov 2016, at 17:00, odb-users-request@codesynthesis.com wrote: > > Send odb-users mailing list submissions to > odb-users@codesynthesis.com > > To subscribe or unsubscribe via the World Wide Web, visit > http://codesynthesis.com/mailman/listinfo/odb-users > or, via email, send a message with subject or body 'help' to > odb-users-request@codesynthesis.com > > You can reach the person managing the list at > odb-users-owner@codesynthesis.com > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of odb-users digest..." > > > Today's Topics: > > 1. ODB Compiler VS 2015 (Andrew Lamping) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Fri, 18 Nov 2016 13:39:33 -0500 > From: Andrew Lamping > Subject: [odb-users] ODB Compiler VS 2015 > To: odb-users@codesynthesis.com > Message-ID: > > Content-Type: text/plain; charset=UTF-8 > > Anyone have any info as to how to rebuild the ODB compiler on Windows? > Thanks. > > Andy > > > ------------------------------ > > _______________________________________________ > odb-users mailing list > odb-users@codesynthesis.com > http://codesynthesis.com/mailman/listinfo/odb-users > > > End of odb-users Digest, Vol 75, Issue 9 > **************************************** From boris at codesynthesis.com Fri Dec 2 10:49:58 2016 From: boris at codesynthesis.com (Boris Kolpackov) Date: Fri Dec 2 10:50:08 2016 Subject: [odb-users] Joining underscore for column pragma on composite values In-Reply-To: <1480668777.942911586@apps.rackspace.com> References: <1480668777.942911586@apps.rackspace.com> Message-ID: Hi Dieter, Dieter Govaerts writes: > Above example results in a column named "person$_first" instead of > my preferred "person$first". I think you can "fix up" your names with the --column-regex ODB compiler option. Boris From boris at codesynthesis.com Mon Dec 5 10:17:04 2016 From: boris at codesynthesis.com (Boris Kolpackov) Date: Mon Dec 5 10:17:13 2016 Subject: [odb-users] Windows builds.. In-Reply-To: References: Message-ID: Hi Andrew, Andrew Cunningham writes: > The various windows builds create DLLS in bin64 such as > odb-2.5-vc12.dll > but the import libraries in lib64 end up being > odb.lib > > That creates all sorts of problems when trying to use multiple versions of > Visual Studio and the same ODB version. Well, I don't see how this by itself creates problems. Perhaps what's creating problems it the fact that "VC++ Directories" are shared among various Visual Studio versions (one of those "brilliant" ideas from MS)? If that's the case, then the way we work around this is with this trick: we include the VC version into the "VC++ Directories" paths via a macro. For example: C:\projects\libodb-vc$(VisualStudioVersion)\lib Then we name our directories like so: libodb-vc11.0 libodb-vc12.0 libodb-vc14.0 ... > I would prefer the import libraries be (say) odb-2.5-vc12.lib This will make migrating VC projects (tests, examples, etc) even more painful. But, in any case, all this .vc(x)proj stuff is going to EOL'ed soon and once we use build2 you will be able to name your libraries however you like, for example: b config.bin.lib.suffix=-andrews-vc12 Boris From dieter.govaerts at bricsys.com Tue Dec 6 05:52:14 2016 From: dieter.govaerts at bricsys.com (Dieter Govaerts) Date: Tue Dec 6 05:52:21 2016 Subject: [odb-users] Joining underscore for column pragma on composite values In-Reply-To: References: <1480668777.942911586@apps.rackspace.com> Message-ID: <1481021534.14719708@apps.rackspace.com> Hello Boris, Yes, thank you. That does the trick: --column-regex '/(.+)\$_(.+)/$1\$$2/' Unfortunately there seems to be a bug in 2.4.0 because it only works for non-TEXT columns (SQLite). Change log before: Change log after: Best regards, Dieter Govaerts On Friday, 2 December, 2016 16:49, "Boris Kolpackov" said: > Hi Dieter, > > Dieter Govaerts writes: > >> Above example results in a column named "person$_first" instead of >> my preferred "person$first". > > I think you can "fix up" your names with the --column-regex ODB > compiler option. > > Boris > From andrew at a-cunningham.com Mon Dec 5 12:12:28 2016 From: andrew at a-cunningham.com (Andrew Cunningham) Date: Tue Dec 6 08:56:10 2016 Subject: [odb-users] Windows builds.. In-Reply-To: References: Message-ID: Hi Boris, I take you your points. But given the vagaries of Windows compilers , their various incompatibilities and resultant "DLL-hell" , I think BOOST do it the right way by spelling out "ad-nauseaum" how a .DLL was built. e.g. boost_atomic-vc140-mt-1_62.dll But I gather, build2 will let us do that, or any such combination, as well. Andrew On Mon, Dec 5, 2016 at 7:17 AM, Boris Kolpackov wrote: > Hi Andrew, > > Andrew Cunningham writes: > > > The various windows builds create DLLS in bin64 such as > > odb-2.5-vc12.dll > > but the import libraries in lib64 end up being > > odb.lib > > > > That creates all sorts of problems when trying to use multiple versions > of > > Visual Studio and the same ODB version. > > Well, I don't see how this by itself creates problems. Perhaps what's > creating problems it the fact that "VC++ Directories" are shared among > various Visual Studio versions (one of those "brilliant" ideas from MS)? > If that's the case, then the way we work around this is with this trick: > we include the VC version into the "VC++ Directories" paths via a macro. > For example: > > C:\projects\libodb-vc$(VisualStudioVersion)\lib > > Then we name our directories like so: > > libodb-vc11.0 > libodb-vc12.0 > libodb-vc14.0 > ... > > > > I would prefer the import libraries be (say) odb-2.5-vc12.lib > > This will make migrating VC projects (tests, examples, etc) even more > painful. > > But, in any case, all this .vc(x)proj stuff is going to EOL'ed soon > and once we use build2 you will be able to name your libraries however > you like, for example: > > b config.bin.lib.suffix=-andrews-vc12 > > Boris > From boris at codesynthesis.com Tue Dec 6 11:03:40 2016 From: boris at codesynthesis.com (Boris Kolpackov) Date: Tue Dec 6 11:03:50 2016 Subject: [odb-users] Joining underscore for column pragma on composite values In-Reply-To: <1481021534.14719708@apps.rackspace.com> References: <1480668777.942911586@apps.rackspace.com> <1481021534.14719708@apps.rackspace.com> Message-ID: Hi Dieter, Dieter Govaerts writes: > Unfortunately there seems to be a bug in 2.4.0 because it only works > for non-TEXT columns (SQLite). I've adjusted your original example like this: #include #pragma db value struct name { int first_; std::string last_; }; #pragma db object struct person { #pragma db column("person$") name name_; #pragma db id int id; }; Without your --column-regex I get: CREATE TABLE "person" ( "person$_first" INTEGER NOT NULL, "person$_last" TEXT NOT NULL, "id" INTEGER NOT NULL PRIMARY KEY); And with --column-regex '/(.+)\$_(.+)/$1\$$2/': CREATE TABLE "person" ( "person$first" INTEGER NOT NULL, "person$last" TEXT NOT NULL, "id" INTEGER NOT NULL PRIMARY KEY); So there must something else going on. If you can create a test that reproduces the problem, I can take a look. Boris From haupt.wolfgang at gmail.com Fri Dec 9 08:09:40 2016 From: haupt.wolfgang at gmail.com (Wolfgang Haupt) Date: Fri Dec 9 08:10:03 2016 Subject: [odb-users] libodb-mysql looking for libmysqlclient_r Message-ID: Hi, afaik libmysqlclient has thread support integrated in the normal build, hence there is no libmysqlclient_r.so/a anymore. Is it possible to disable looking for _r postfix without patching the configure script, in the current stable release 2.4? Best Regards, Wolfgang From micrsosft at live.com Sat Dec 10 11:55:24 2016 From: micrsosft at live.com (zhigang lee) Date: Mon Dec 12 10:32:43 2016 Subject: [odb-users] About Use of C++ ORM ODB In-Reply-To: References: Message-ID: Sent from Mail for Windows 10 From: zhigang lee Sent: Sunday, December 11, 2016 00:43 To: announcements@codesynthesis.com Subject: About Use of C++ ORM ODB Excuse me? Having problems using the ODB.Problem may be small, but I do not know how to solve. No.1: Multiple dynamic libraries using ODB. Correspond to different database engine create dll module. Example: in odb_mssqlhelper.dll dealing with all the odb code for mssql. in odb_mysqlhelper.dll dealing with all the odb code for mysql. ??? These modules use the boost date and UUID Compile odb_mysqlhelper.dll and odb_mssqlhelper.dll now all goes well No.2: In order to switch the database engine at run time, we created odb_databasehelper.dll. According to configured using different dbhelper class. But odb_databasehelper.dll at compile-time error occurs. No3: Error details and code examples Example odb header code: // file : System_Country.hxx // copyright : not copyrighted - public domain #ifndef LNSF_SYSDB_COUNTRY_OBJ_MSSQL_HXX #define LNSF_SYSDB_COUNTRY_OBJ_MSSQL_HXX #include "stdafx.h" //#include #include #include // std::size_t #include #include #include #include #include #include #include #include #include using boost::shared_ptr; using boost::weak_ptr; using odb::boost::lazy_shared_ptr; using odb::boost::lazy_weak_ptr; using boost::uuids::uuid; using boost::gregorian::date; #include #include "Lnsf_MssqlDbHelper_Config.hpp" #pragma db object namespace LNSF_DBHELP_MSSQL { class LNSF_MSSQLDBHELPER_API Lnsf_System_Country { public: Lnsf_System_Country(){} private: friend class odb::access; #pragma db id uuid Cid; uuid Pid; std::wstring SystemName; std::wstring LocalName; unsigned int AreaCode; time_t Founding; date Foundtime; #pragma db type("NVARCHAR(1024)") null std::wstring Flag; #pragma db type("NVARCHAR(512)") null std::wstring Capital; #pragma db type("NVARCHAR(1024)") null std::wstring Description; public: uuid GetCid(){ return Cid; } void SetCid(uuid gCid){ Cid = gCid; } uuid GetPid(){ return Pid; } void SetPid(uuid gPid){ Pid = gPid; } std::wstring GetSystemName(){ return SystemName; } void SetSystemName(const std::wstring&strSystemName){ SystemName = strSystemName; } std::wstring GetLocalName(){ return LocalName; } void SetLocalName(const std::wstring&strLocalName){ LocalName = strLocalName; } unsigned int GetAreaCode(){ return AreaCode; } void SetAreaCode(unsigned int nAreaCode){ AreaCode = nAreaCode; } time_t GetFounding(){ return Founding; } void SetFounding(time_t tFounding){ Founding = tFounding; } date GetFoundTime(){ return Foundtime; } void SetFoundTime(date dTime){ Foundtime = dTime; } std::wstring GetFlag(){ return Flag; } void SetFlag(const std::wstring&strFlag){ Flag = strFlag; } std::wstring GetCapital(){ return Capital; } void SetCapital(const std::wstring&strCapital){ Capital = strCapital; } std::wstring GetDescription(){ return Description; } void SetDescription(const std::wstring&strDescription){ Description = strDescription; } }; } #endif This header file custom build tool command line: odb.exe --std c++11 --database mssql --profile boost --generate-query --generate-schema --generate-session --table-prefix boost_ System_Country.hxx This header files include all odb code build success. Inermediate module header code: Config header files /* *Lnsf Databse Helper Config Header Files *@Micrsosft@live.com *2016-4-4 */ #ifndef __LNSF_DBHELP_CONFIG__ #define __LNSF_DBHELP_CONFIG__ #include #include // std::auto_ptr #include // std::exit #include #include // std::size_t #include #include #include #include //import Database Helper Library #pragma comment(lib, "Lnsf_MssqlDbHelper.lib") #pragma comment(lib, "Lnsf_MysqlDbHelper.lib") #pragma comment(lib, "Lnsf_OracleDbHelper.lib") #include #include #include #include #include #include #include #include #include #include #include #include #include using namespace boost; using boost::uuids::uuid; #include #include #include #include #include using boost::shared_ptr; using boost::weak_ptr; using odb::boost::lazy_shared_ptr; using odb::boost::lazy_weak_ptr; using boost::gregorian::date; #include "Lnsf_DbConvertHelper.hpp" static int DATA_ENVIRONMENT = LNSF::GetDatabaseEnvironment(); using namespace LNSF; using namespace std; using namespace odb::core; #endif Handle Header Files Code #pragma once #include // std::auto_ptr #include #include #include // std::exit #include #include #include #include #include #include #include #include #include #include #include #include #include "Lnsf_DatabaseConfig.hpp" #define LNSF_SYSTEM_DB L"Lnsf_System" #define LNSF_USEBAS_DB L"Lnsf_Userbase" #define LNSF_RELATE_DB L"Lnsf_Relate" #define LNSF_ENTERP_DB L"Lnsf_Enterprise" using namespace boost::gregorian; using namespace odb::core; namespace LNSF_DBHELP { template class System_DataManager { public: System_DataManager(); typedef odb::query Query; bool insert(T item, __int64 &nRowID); bool insert(T item, GUID &gID); bool insert(T item, uuid &uID); bool insert(T item, std::string &strID); ~System_DataManager(){} }; template System_DataManager::System_DataManager() { } template bool System_DataManager::insert(T item, __int64 &nRowID) { auto_ptr db(Connect_LnsfSystem()); try { transaction t(db->begin()); nRowID = db->persist(item); t.commit(); } catch (const odb::exception& e) { cerr << e.what() << endl; AddinException(LNSF_SYSTEM_DB, e.what()); return false; } return true; } template bool System_DataManager::insert(T item, GUID &gID) { auto_ptr db(Connect_LnsfSystem()); try { transaction t(db->begin()); gID = db->persist(item); t.commit(); } catch (const odb::exception& e) { cerr << e.what() << endl; //???????????????? AddinException(LNSF_SYSTEM_DB,e.what()); return false; } return true; } template bool System_DataManager::insert(T item, uuid &uID) { auto_ptr db(Connect_LnsfSystem()); try { transaction t(db->begin()); uID = db->persist(item); t.commit(); } catch (const odb::exception& e) { cerr << e.what() << endl; //???????????????? AddinException(LNSF_SYSTEM_DB, e.what()); return false; } return true; } template bool System_DataManager::insert(T item, std::string &strID) { auto_ptr db(Connect_LnsfSystem()); try { transaction t(db->begin()); strID = db->persist(item); t.commit(); } catch (const odb::exception& e) { //transaction t(db->begin()); cerr << e.what() << endl; AddinException(LNSF_SYSTEM_DB, e.what()); //t.rollback(); return false; } return true; } Template class and query define header files code #ifndef __LNSF_DBSYSTEM_TEMPLATE__ #define __LNSF_DBSYSTEM_TEMPLATE__ #include "Lnsf_DatabaseConfig.hpp" #include "Lnsf_DatabaseHandle.hpp" #include #include typedef odb::query countryQuery; typedef std::vectorvCountryList; class CDb_System_Country_Handle :public LNSF_DBHELP::System_DataManager { public: CDb_System_Country_Handle(){} ~CDb_System_Country_Handle(){}; }; Database table operate class header file code #pragma once #include "Lnsf_DatabaseFamily.hpp" namespace LNSF_DBHELP { class CLnsf_SystemCountry_Handle { public: CLnsf_SystemCountry_Handle(); ~CLnsf_SystemCountry_Handle(); public: bool System_Country_Add(LNSF_SYSDB_COUNTRY tagCountry); bool System_Country_BatchAdd(vDataCountryList vCountryList); bool System_Country_Update(LNSF_SYSDB_COUNTRY tagCountry); bool System_Country_CheckExist(LNSF_SYSDB_COUNTRY tagCountry); bool System_Country_Find(GUID gID, LNSF_SYSDB_COUNTRY &tagCountry); bool System_Country_Erase(GUID gID); bool System_Country_GetByID(GUID gID, LNSF_SYSDB_COUNTRY &tagItems); bool System_Country_QueryItem(int nCondition, LNSF_SYSDB_COUNTRY tagCountry, vDataCountryList& vQueryList); bool System_Country_Clear(); long long System_Country_Exec(std::string &strSql); std::wstring GetFullCountryAddr(GUID gID, bool bSysname,bool bSpace); }; No.4:Build error info: Output info: >------ Build started: Project: Lnsf_DatabaseHelper, Configuration: Debug x64 ------ 1> stdafx.cpp 1> SystemSpace_Handle.cpp 1> SystemCountry_Handle.cpp 1>f:\livenetframework\lnsf_framework\lnsf_framework_source\lnsf_databasehelper\Lnsf_DatabaseHandle.hpp(524): error C2664: 'std::auto_ptr::auto_ptr(std::auto_ptr_ref<_Ty>) throw()' : cannot convert argument 1 from 'boost::shared_ptr' to 'LNSF_DBHELP_MSSQL::Lnsf_System_Country *' 1> with 1> [ 1> T=LNSF_DBHELP_MSSQL::Lnsf_System_Country 1> , _Ty=LNSF_DBHELP_MSSQL::Lnsf_System_Country 1> ] 1> No user-defined-conversion operator available that can perform this conversion, or the operator cannot be called 1> f:\livenetframework\lnsf_framework\lnsf_framework_source\lnsf_databasehelper\Lnsf_DatabaseHandle.hpp(519) : while compiling class template member function 'LNSF_DBHELP_MSSQL::Lnsf_System_Country LNSF_DBHELP::System_DataManager::GetById(boost::uuids::uuid)' 1> SystemCountry_Handle.cpp(384) : see reference to function template instantiation 'LNSF_DBHELP_MSSQL::Lnsf_System_Country LNSF_DBHELP::System_DataManager::GetById(boost::uuids::uuid)' being compiled 1> f:\livenetframework\lnsf_framework\lnsf_framework_source\lnsf_databasehelper\Lnsf_TemplateSystem.hpp(511) : see reference to class template instantiation 'LNSF_DBHELP::System_DataManager' being compiled 1>F:\LiveNetFramework\Lnsf_Framework\Lnsf_Include\Lnsf_DataBaseDrive\Odb_BaseSdks\odb/database.ixx(180): error C2440: 'initializing' : cannot convert from 'LNSF_DBHELP_MSSQL::Lnsf_System_Country *' to 'const object_pointer &' 1> Reason: cannot convert from 'LNSF_DBHELP_MSSQL::Lnsf_System_Country *' to 'const object_pointer' 1> Constructor for class 'boost::shared_ptr' is declared 'explicit' 1> SystemCountry_Handle.cpp(107) : see reference to function template instantiation 'odb::access::object_traits::id_type odb::database::persist(T *)' being compiled 1> with 1> [ 1> T=LNSF_DBHELP_MSSQL::Lnsf_System_Country 1> ] Error list info: 1?Error 2 error C2440: 'initializing' : cannot convert from 'LNSF_DBHELP_MSSQL::Lnsf_System_Country *' to 'const object_pointer &' F:\LiveNetFramework\Lnsf_Framework\Lnsf_Include\Lnsf_DataBaseDrive\Odb_BaseSdks\odb\database.ixx 180 2?Error 1 error C2664: 'std::auto_ptr::auto_ptr(std::auto_ptr_ref<_Ty>) throw()' : cannot convert argument 1 from 'boost::shared_ptr' to 'LNSF_DBHELP_MSSQL::Lnsf_System_Country *' f:\livenetframework\lnsf_framework\lnsf_framework_source\lnsf_databasehelper\Lnsf_DatabaseHandle.hpp 524 If you have time please answer this question. Thank you so much Sent from Mail for Windows 10 From boris at codesynthesis.com Mon Dec 12 10:40:37 2016 From: boris at codesynthesis.com (Boris Kolpackov) Date: Mon Dec 12 10:40:46 2016 Subject: [odb-users] libodb-mysql looking for libmysqlclient_r In-Reply-To: References: Message-ID: Hi Wolfgang, Wolfgang Haupt writes: > afaik libmysqlclient has thread support integrated in the normal build, > hence there is no libmysqlclient_r.so/a anymore. Yes, it seems in more recent versions it is always multi-threaded and the _r suffix was dropped. There are still older distributions though that use _r. > Is it possible to disable looking for _r postfix without patching the > configure script, in the current stable release 2.4? Not that I can see. If you can create a _r symlink while building, then it should work (the result should look for the library without _r because of the soname). Boris From haupt.wolfgang at gmail.com Mon Dec 12 12:19:06 2016 From: haupt.wolfgang at gmail.com (Wolfgang Haupt) Date: Mon Dec 12 12:19:30 2016 Subject: [odb-users] libodb-mysql looking for libmysqlclient_r In-Reply-To: References: Message-ID: Hi Boris, thanks for your answer. I'll keep my configure patch then. Best Regards, Wolfgang Boris Kolpackov schrieb am Mo., 12. Dez. 2016 um 16:40 Uhr: > Hi Wolfgang, > > Wolfgang Haupt writes: > > > afaik libmysqlclient has thread support integrated in the normal build, > > hence there is no libmysqlclient_r.so/a anymore. > > Yes, it seems in more recent versions it is always multi-threaded and > the _r suffix was dropped. There are still older distributions though > that use _r. > > > > Is it possible to disable looking for _r postfix without patching the > > configure script, in the current stable release 2.4? > > Not that I can see. If you can create a _r symlink while building, then > it should work (the result should look for the library without _r because > of the soname). > > Boris > From alejandro_pnz at icloud.com Mon Dec 12 22:08:48 2016 From: alejandro_pnz at icloud.com (Alexander Igorevich) Date: Tue Dec 13 08:48:00 2016 Subject: [odb-users] Data migration in SQLite Message-ID: Hi. I've read ODB manual ch. 13 and now I try to migrate my database version. I use sample from the end of chapter 13.2: schema_version v (db.schema_version ()); schema_version bv (schema_catalog::base_version (db)); schema_version cv (schema_catalog::current_version (db)); if (v == 0) { // No schema in the database. Create the schema and // initialize the database. // transaction t (db.begin ()); schema_catalog::create_schema (db); // Populate the database with initial data, if any. t.commit (); } else if (v < cv) { // Old schema (and data) in the database, migrate them. // if (v < bv) { // Error: migration from this version is no longer supported. } for (v = schema_catalog::next_version (db, v); v <= cv; v = schema_catalog::next_version (db, v)) { transaction t (db.begin ()); schema_catalog::migrate_schema_pre (db, v); // Data migration goes here. schema_catalog::migrate_schema_post (db, v); t.commit (); } } else if (v > cv) { // Error: old application trying to access new database. } But after running this code on the database (it works great and function calling right), there is no new added tables (classes) in the database. I've add version notation to new class like that: #pragma db model version(2, 2, open) In old (1st version scheme) classes has notation like that: #pragma db model version(1, 1, closed) The question why migrate_schema doesn't create table for the new class? (if I remove database, code above successfully create database from the scratch with the class)? From boris at codesynthesis.com Tue Dec 13 09:34:46 2016 From: boris at codesynthesis.com (Boris Kolpackov) Date: Tue Dec 13 09:34:55 2016 Subject: [odb-users] Data migration in SQLite In-Reply-To: References: Message-ID: Hi Alexander, Alexander Igorevich writes: > #pragma db model version(2, 2, open) > > #pragma db model version(1, 1, closed) This means no migration is possible from version 1 to 2 which means you should end up here: > if (v < bv) > { > // Error: migration from this version is no longer supported. > } Did you actually run it under the debugger to examine the control flow? Boris From alejandro_pnz at icloud.com Tue Dec 13 09:46:57 2016 From: alejandro_pnz at icloud.com (Alexander Igorevich) Date: Tue Dec 13 09:47:14 2016 Subject: [odb-users] Data migration in SQLite In-Reply-To: References: Message-ID: > On Dec 13, 2016, at 5:34 PM, Boris Kolpackov wrote: > > Hi Alexander, > > Alexander Igorevich writes: > >> #pragma db model version(2, 2, open) >> >> #pragma db model version(1, 1, closed) > > This means no migration is possible from version 1 to 2 which means > you should end up here: > > >> if (v < bv) >> { >> // Error: migration from this version is no longer supported. >> } > > Did you actually run it under the debugger to examine the control > flow? > > Boris Yea, I run it under debugger - it works like should works - after adding new class (2nd version), running next code segment: for (v = schema_catalog::next_version (db, v); v <= cv; v = schema_catalog::next_version (db, v)) { transaction t (db.begin ()); schema_catalog::migrate_schema_pre (db, v); // Data migration goes here. schema_catalog::migrate_schema_post (db, v); t.commit (); } I?ve tried to use different functions at this place - schema_catalog::migrate_schema_pre, schema_catalog::migrate_schema_post, schema_catalog:migrate_schema, schema_catalog::migrate_data, but no one of them doesn?t add new class in the database. If I re-create database, this class is added perfectly. How can I add new class using migrate function of the ODB? From boris at codesynthesis.com Tue Dec 13 10:57:04 2016 From: boris at codesynthesis.com (Boris Kolpackov) Date: Tue Dec 13 10:57:13 2016 Subject: [odb-users] Data migration in SQLite In-Reply-To: References: Message-ID: Hi Alexander, Alexander Igorevich writes: > Yea, I run it under debugger - it works like should works - after adding > new class (2nd version), running next code segment: You shouldn't even be running this code fragment with your version pragma: #pragma db model version(2, 2, open) This says: "we support migration from oldest version 2 to current version 2". So when you run your code on database version 1 you should get to the error condition (attempt to migrate from a version that is too old) rather than to try and run any migration steps. What you perhaps meant is this pragma: #pragma db model version(1, 2, open) Boris From alejandro_pnz at icloud.com Tue Dec 13 11:17:06 2016 From: alejandro_pnz at icloud.com (Alexander Igorevich) Date: Tue Dec 13 11:17:20 2016 Subject: [odb-users] Data migration in SQLite In-Reply-To: References: Message-ID: <6756BB08-DAF4-410B-8964-B284E0419CDF@icloud.com> > On Dec 13, 2016, at 6:57 PM, Boris Kolpackov wrote: > > Hi Alexander, > > Alexander Igorevich writes: > >> Yea, I run it under debugger - it works like should works - after adding >> new class (2nd version), running next code segment: > > You shouldn't even be running this code fragment with your version > pragma: > > #pragma db model version(2, 2, open) > > This says: "we support migration from oldest version 2 to current > version 2". So when you run your code on database version 1 you > should get to the error condition (attempt to migrate from a > version that is too old) rather than to try and run any migration > steps. > > What you perhaps meant is this pragma: > > #pragma db model version(1, 2, open) > > Boris I?ve try it out, but it doesn?t help - if I don?t remove database, new class doesn?t created. From obermann.lukas at gmail.com Tue Dec 13 11:24:43 2016 From: obermann.lukas at gmail.com (Lukas Obermann) Date: Tue Dec 13 11:24:58 2016 Subject: [odb-users] Sections in view's result causes exception Message-ID: <2E9AD32A-7168-4FD2-8686-466B4A3C7163@gmail.com> Hi there, When I try to load a section from a result I get following exception: section instance is not part of an object (section was copied?) The code is like this: odb::result res(m_cdb.getDB()->query(data_query)); for (odb::result::iterator i = res.begin(); i != res.end(); i++) { .. m_cdb.getDB()->load(*(i->data), i->data->section_container); .. } where data is a std::shared_ptr, and ODBData is having different sections. As the sections work without issues on other parts where I do not use Views I assume that this has something to do with the View. Not sure what I am doing wrong. Any help is appreciated! Thanks, Lukas From boris at codesynthesis.com Wed Dec 14 11:48:42 2016 From: boris at codesynthesis.com (Boris Kolpackov) Date: Wed Dec 14 11:48:51 2016 Subject: [odb-users] Sections in view's result causes exception In-Reply-To: <2E9AD32A-7168-4FD2-8686-466B4A3C7163@gmail.com> References: <2E9AD32A-7168-4FD2-8686-466B4A3C7163@gmail.com> Message-ID: Hi Lukas, Lukas Obermann writes: > m_cdb.getDB()->load(*(i->data), i->data->section_container); Can you try to "unpack" it like this and see what happens: std::shared_ptr d (i->data); assert (d != nullptr); m_cdb.getDB()->load (*d, d->section_container); > As the sections work without issues on other parts where I do not use > Views I assume that this has something to do with the View. I don't see how the view can affect it. My only guess is that i->data is NULL and you get the exception a second before getting a segfault ;-). Boris From boris at codesynthesis.com Wed Dec 14 11:56:08 2016 From: boris at codesynthesis.com (Boris Kolpackov) Date: Wed Dec 14 11:56:17 2016 Subject: [odb-users] Data migration in SQLite In-Reply-To: <6756BB08-DAF4-410B-8964-B284E0419CDF@icloud.com> References: <6756BB08-DAF4-410B-8964-B284E0419CDF@icloud.com> Message-ID: Hi Alexander, Alexander Igorevich writes: > I?ve try it out, but it doesn?t help - if I don?t remove database, > new class doesn?t created. Ok, then you will need to send a minimal but complete test case that reproduces the problem. Boris From obermann.lukas at gmail.com Wed Dec 14 13:44:55 2016 From: obermann.lukas at gmail.com (Lukas Obermann) Date: Wed Dec 14 13:45:10 2016 Subject: [odb-users] Sections in view's result causes exception In-Reply-To: References: <2E9AD32A-7168-4FD2-8686-466B4A3C7163@gmail.com> Message-ID: Hi Boris, unfortunately i->data is not NULL ? Looking at the section in the debugger it returns following section_container odb::section state_ odb::section::(anonymous struct) loaded unsigned char '\0? changed unsigned char '\0' armed unsigned char '\0' restore unsigned char '\0? user unsigned char '\0? also the assert is not triggered. Lukas > Am 14.12.2016 um 17:48 schrieb Boris Kolpackov : > > Hi Lukas, > > Lukas Obermann writes: > >> m_cdb.getDB()->load(*(i->data), i->data->section_container); > > Can you try to "unpack" it like this and see what happens: > > std::shared_ptr d (i->data); > > assert (d != nullptr); > > m_cdb.getDB()->load (*d, d->section_container); > > >> As the sections work without issues on other parts where I do not use >> Views I assume that this has something to do with the View. > > I don't see how the view can affect it. My only guess is that i->data > is NULL and you get the exception a second before getting a segfault ;-). > > Boris From alejandro_pnz at icloud.com Wed Dec 14 22:00:15 2016 From: alejandro_pnz at icloud.com (Alexander Igorevich) Date: Wed Dec 14 22:00:31 2016 Subject: [odb-users] Data migration in SQLite In-Reply-To: References: <6756BB08-DAF4-410B-8964-B284E0419CDF@icloud.com> Message-ID: <3387D031-4B65-4FC4-8D98-6F92318EC292@icloud.com> > On Dec 14, 2016, at 7:56 PM, Boris Kolpackov wrote: > > Hi Alexander, > > Alexander Igorevich writes: > >> I?ve try it out, but it doesn?t help - if I don?t remove database, >> new class doesn?t created. > > Ok, then you will need to send a minimal but complete test case that > reproduces the problem. > > Boris > > Thanks Boris. After I make a test project for you, I?ve try it out and it works. The research has shown that I didn?t include some of the generated classes parts ( .cxx) in PRO-file (I use Qt). Thus, the issue is complete, migration works perfect. From boris at codesynthesis.com Thu Dec 15 05:36:54 2016 From: boris at codesynthesis.com (Boris Kolpackov) Date: Thu Dec 15 05:37:04 2016 Subject: [odb-users] Sections in view's result causes exception In-Reply-To: References: <2E9AD32A-7168-4FD2-8686-466B4A3C7163@gmail.com> Message-ID: Hi Lukas, I just extended one of our object loading view tests to cover pretty much your use-case and it passes. Can you try to create a minimal but complete test case that reproduces this problem? Boris From rnbzilla at gmail.com Tue Dec 20 10:13:07 2016 From: rnbzilla at gmail.com (Roger Noble) Date: Tue Dec 20 13:32:07 2016 Subject: [odb-users] odb location pragmas failure with boost and gcc 6 Message-ID: <741141692.0xATCDHW0N@flamsteed> Hi, I have a problem with an apparent interaction between odb location pragmas and the boost library headers with gcc 6.x and Fedora 25, though there was the same problem with Fedora 24. The attached code snippet illustrates this, running odb on it with odb --database mysql odbtest.h produces the following errors: odbtest.h:36:13: error: db pragma 'id' is not associated with a declaration odbtest.h:36:17: error: db pragma 'auto' is not associated with a declaration odbtest.h:24:12: error: db pragma 'object' is not associated with a declaration odbtest.h:24:19: error: db pragma 'table' is not associated with a declaration odbtest.h:24:19: error: db pragma 'table' is not associated with a declaration Remove any one of the boost includes and it works OK. Note however that it's not so simple as a single header file - other combinations of boost headers can produce the errors as well. Poking around inside the parser code it appears that when it fails the insert of the location pragmas in parser::impl::emit_class // Add location pragmas if any. // { loc_pragmas::const_iterator i (loc_pragmas_.find (c)); if (i != loc_pragmas_.end ()) decls.insert (i->second.begin (), i->second.end ()); } is placing the pragmas into decls after the following declaration rather than before it. In parser::impl::tree_decl::operator< the numerical values of xloc and yloc when this happens are such that the pragma is placed after its declaration, although the file path and line and column numbers returned by LOCATION_FILE, LOCATION_LINE and LOCATION_COLUMN for both xloc and yloc are all correct. There were no problems with gcc 5.x. The versions in use are: gcc 6.2.1 (Fedora 6.2.1-2.fc25) odb 2.4.0 (Fedora 2.4.0-15.fc25) boost 1.60 (Fedora 1.60.0-10.fc25) both x86_64. Regards, Roger -- Roger Noble rnbzilla@gmail.com -------------- next part -------------- A non-text attachment was scrubbed... Name: odbtest.h Type: text/x-chdr Size: 939 bytes Desc: not available Url : http://codesynthesis.com/pipermail/odb-users/attachments/20161220/14f9f186/odbtest.h From anaswara.nn at gmail.com Wed Dec 21 23:51:17 2016 From: anaswara.nn at gmail.com (Anaswara Nair) Date: Wed Dec 21 23:51:29 2016 Subject: [odb-users] Object already persistent Message-ID: Hi, I have a sqlite database with many tables. Table A's primary key is referenced as foreign key by Table B. Now while populating the tables, I need to create an entry in Table A only if corresponding entry in Table B is possible. Since nested transaction is not possible, I tried the following: transaction t(db->begin()); db->persist(objTableA); { for (vector::iterator iter = Flds.begin(); iter != Flds.end(); ++iter) { TableB objTableB(iter->GetName(), iter->GetValue(), std::make_shared(objTableA)); db->persist(objTableB); } } t.commit(); But, it throws the exception as object already persistent in the persist statement of TableB.What can be done here? From boris at codesynthesis.com Thu Dec 22 10:22:08 2016 From: boris at codesynthesis.com (Boris Kolpackov) Date: Thu Dec 22 10:22:25 2016 Subject: [odb-users] Object already persistent In-Reply-To: References: Message-ID: Hi, Anaswara Nair writes: > But, it throws the exception as object already persistent in the persist > statement of TableB. What can be done here? You could first try to check whether there is already an entry for B (e.g., using a light view). Or you could catch the exception and either abort the transaction or erase the A entry. Boris From boris at codesynthesis.com Thu Dec 22 11:26:13 2016 From: boris at codesynthesis.com (Boris Kolpackov) Date: Thu Dec 22 11:26:32 2016 Subject: [odb-users] odb location pragmas failure with boost and gcc 6 In-Reply-To: <741141692.0xATCDHW0N@flamsteed> References: <741141692.0xATCDHW0N@flamsteed> Message-ID: Hi Roger, Thanks for the test case and analysis. I could reproduce it and also reduced it to this: #include #include #include #include #pragma db object struct Board_Option_P { #pragma db id auto int id; }; Interestingly, commenting any include out makes the issue disappear. I've also got the actual location values for the struct and the two pragmas. For a successful run (i.e., with the first header commented out) the values are: struct 1377050792 id 1333997889 auto 1333997987 And for an unsuccessful run: struct 1056301224 id 2147498138 auto 2147498139 So the pragma locations in this case look bogus. I am still looking into this and will keep you updated. Boris From rnbzilla at gmail.com Thu Dec 22 17:23:47 2016 From: rnbzilla at gmail.com (Roger Noble) Date: Fri Dec 23 03:16:46 2016 Subject: [odb-users] odb location pragmas failure with boost and gcc 6 In-Reply-To: References: <741141692.0xATCDHW0N@flamsteed> Message-ID: <1893820.2Me1UerCld@flamsteed> Hi Boris, On Thursday, 22 December 2016 18:26:13 GMT Boris Kolpackov wrote: > Thanks for the test case and analysis. > So the pragma locations in this case look bogus. > > I am still looking into this and will keep you updated. Many thanks. Glad it could be reproduced. Roger -- Roger Noble rnbzilla@gmail.com From boris at codesynthesis.com Fri Dec 23 03:30:46 2016 From: boris at codesynthesis.com (Boris Kolpackov) Date: Fri Dec 23 03:30:59 2016 Subject: [odb-users] odb location pragmas failure with boost and gcc 6 In-Reply-To: <1893820.2Me1UerCld@flamsteed> References: <741141692.0xATCDHW0N@flamsteed> <1893820.2Me1UerCld@flamsteed> Message-ID: <20161223083046.GA18521@codesynthesis.com> Hi Roger, Ok, the fix is in: http://scm.codesynthesis.com/?p=odb/odb.git;a=commit;h=ec777147024fde72e4411cc6b1e1e49f4a1d1804 I will ask Dave Johansen if he can apply it to ODB packages for GCC 6-based RH distributions. Boris From obermann.lukas at gmail.com Fri Dec 23 06:09:11 2016 From: obermann.lukas at gmail.com (Lukas Obermann) Date: Fri Dec 23 06:09:27 2016 Subject: [odb-users] Sections in view's result causes exception In-Reply-To: References: <2E9AD32A-7168-4FD2-8686-466B4A3C7163@gmail.com> Message-ID: Hi Boris, I am trying to provide you with a sample, but running into some strange issues with the sample the last days. I have upload the code here: https://github.com/lobermann/odb_section_sample So, using the same cmake files and basically the same code as in the project, I am getting exceptions when trying to run it on MacOS and Linux. terminate called after throwing an instance of 'odb::unknown_schema' what(): unknown database schema '' Aborted It is using following odb command: /usr/bin/odb --multi-database dynamic -d sqlite -d mysql -d common --generate-query --generate-session --generate-schema --generate-prepared --std c++11 --schema-format embedded --output-dir /root/devel/odbSectionsSample/linux_build/odb_gen --hxx-suffix .h --ixx-suffix _inline.h --cxx-suffix .cpp --odb-file-suffix sqlite:_odb_sqlite --odb-file-suffix mysql:_odb_mysql --odb-file-suffix common:_odb -I/usr/local/include ODBData.h I am pretty much out of ideas now why this is happening on the sample. I see the schema code in the generated files with a empty name, as it should be. Any ideas? Thank you, Lukas > Am 15.12.2016 um 11:36 schrieb Boris Kolpackov : > > Hi Lukas, > > I just extended one of our object loading view tests to cover pretty > much your use-case and it passes. > > Can you try to create a minimal but complete test case that reproduces > this problem? > > Boris From rnbzilla at gmail.com Fri Dec 23 06:21:30 2016 From: rnbzilla at gmail.com (Roger Noble) Date: Fri Dec 23 13:16:58 2016 Subject: [odb-users] odb location pragmas failure with boost and gcc 6 In-Reply-To: <20161223083046.GA18521@codesynthesis.com> References: <741141692.0xATCDHW0N@flamsteed> <1893820.2Me1UerCld@flamsteed> <20161223083046.GA18521@codesynthesis.com> Message-ID: <14263910.AayA3FmaA9@flamsteed> Hi Boris, On Friday, 23 December 2016 10:30:46 GMT Boris Kolpackov wrote: > Ok, the fix is in: > > http://scm.codesynthesis.com/?p=odb/odb.git;a=commit;h=ec777147024fde72e4411 > cc6b1e1e49f4a1d1804 > Thanks, that's fixed it for my build - that was quick! Regards, Roger -- Roger Noble rnbzilla@gmail.com From christian at gsvitec.com Fri Dec 23 17:43:15 2016 From: christian at gsvitec.com (Christian Sell) Date: Fri Dec 23 17:43:23 2016 Subject: [odb-users] cannot load image bytes through section Message-ID: <1218576152.919469.1482532995365@communicator.strato.de> hello, I am using SQLite, and heres my mappping #pragma db type("BLOB") section(image_section) std::vector image_data; heres the code: odb::ransaction tr(database->begin()); database->load(*obj, obj->image_section); the data in the database is perfect, and it was written through the same mechanism. However, when loading, I get a correct size in image_data.size(), but the data inside image_data is garbage can anyone help? thanks, Christian From odb at a-cunningham.com Fri Dec 23 18:18:11 2016 From: odb at a-cunningham.com (Andrew Cunningham) Date: Fri Dec 23 18:18:25 2016 Subject: [odb-users] cannot load image bytes through section In-Reply-To: <1218576152.919469.1482532995365@communicator.strato.de> References: <1218576152.919469.1482532995365@communicator.strato.de> Message-ID: Christian, There have been several fixes to 2.4.0 with regards to sections. Try the latest 2.5.0a11 Andrew On Fri, Dec 23, 2016 at 2:43 PM, Christian Sell wrote: > hello, > > I am using SQLite, and heres my mappping > > #pragma db type("BLOB") section(image_section) > std::vector image_data; > > heres the code: > > odb::ransaction tr(database->begin()); > database->load(*obj, obj->image_section); > > the data in the database is perfect, and it was written through the same > mechanism. However, when loading, I get a correct size in > image_data.size(), but the data inside image_data is garbage > > can anyone help? > thanks, Christian > > From christian at gsvitec.com Fri Dec 23 18:59:39 2016 From: christian at gsvitec.com (Christian Sell) Date: Fri Dec 23 18:59:48 2016 Subject: [odb-users] cannot load image bytes through section In-Reply-To: References: <1218576152.919469.1482532995365@communicator.strato.de> Message-ID: <1090761655.919761.1482537579328@communicator.strato.de> thanks. where would I get that from? -C > Andrew Cunningham hat am 24. Dezember 2016 um 00:18 geschrieben: > > > Christian, > There have been several fixes to 2.4.0 with regards to sections. Try the > latest 2.5.0a11 > > Andrew > > On Fri, Dec 23, 2016 at 2:43 PM, Christian Sell > wrote: > > > hello, > > > > I am using SQLite, and heres my mappping > > > > #pragma db type("BLOB") section(image_section) > > std::vector image_data; > > > > heres the code: > > > > odb::ransaction tr(database->begin()); > > database->load(*obj, obj->image_section); > > > > the data in the database is perfect, and it was written through the same > > mechanism. However, when loading, I get a correct size in > > image_data.size(), but the data inside image_data is garbage > > > > can anyone help? > > thanks, Christian > > > > From odb at a-cunningham.com Fri Dec 23 19:10:26 2016 From: odb at a-cunningham.com (Andrew Cunningham) Date: Fri Dec 23 19:10:40 2016 Subject: [odb-users] cannot load image bytes through section In-Reply-To: <1090761655.919761.1482537579328@communicator.strato.de> References: <1218576152.919469.1482532995365@communicator.strato.de> <1090761655.919761.1482537579328@communicator.strato.de> Message-ID: Hi Christian, Boris posted this message on the list recently.... if you have Linux you will have to build the ODB compiler from the source. Andrew .... I've built another pre-release with the fix. Can you confirm everything is working now? http://codesynthesis.com/~boris/tmp/odb/pre-release/a11/ ...... On Fri, Dec 23, 2016 at 3:59 PM, Christian Sell wrote: > thanks. where would I get that from? > -C > > > Andrew Cunningham hat am 24. Dezember 2016 um > 00:18 geschrieben: > > > > > > Christian, > > There have been several fixes to 2.4.0 with regards to sections. Try the > > latest 2.5.0a11 > > > > Andrew > > > > On Fri, Dec 23, 2016 at 2:43 PM, Christian Sell > > wrote: > > > > > hello, > > > > > > I am using SQLite, and heres my mappping > > > > > > #pragma db type("BLOB") section(image_section) > > > std::vector image_data; > > > > > > heres the code: > > > > > > odb::ransaction tr(database->begin()); > > > database->load(*obj, obj->image_section); > > > > > > the data in the database is perfect, and it was written through the > same > > > mechanism. However, when loading, I get a correct size in > > > image_data.size(), but the data inside image_data is garbage > > > > > > can anyone help? > > > thanks, Christian > > > > > > > From christian at gsvitec.com Sat Dec 24 07:05:58 2016 From: christian at gsvitec.com (Christian Sell) Date: Sat Dec 24 07:06:08 2016 Subject: [odb-users] cannot load image bytes through section In-Reply-To: References: <1218576152.919469.1482532995365@communicator.strato.de> <1090761655.919761.1482537579328@communicator.strato.de> Message-ID: <1768853872.923321.1482581158578@communicator.strato.de> ok, thanks. Took me a day to build and install, but now loading binary data through a section works. Seems it was simply broken in 2.4.0. Chris > Andrew Cunningham hat am 24. Dezember 2016 um 01:10 geschrieben: > > > Hi Christian, > Boris posted this message on the list recently.... if you have Linux you > will have to build the ODB compiler from the source. > > Andrew > > .... > I've built another pre-release with the fix. Can you confirm everything > is working now? > http://codesynthesis.com/~boris/tmp/odb/pre-release/a11/ > ...... > > > On Fri, Dec 23, 2016 at 3:59 PM, Christian Sell > wrote: > > > thanks. where would I get that from? > > -C > > > > > Andrew Cunningham hat am 24. Dezember 2016 um > > 00:18 geschrieben: > > > > > > > > > Christian, > > > There have been several fixes to 2.4.0 with regards to sections. Try the > > > latest 2.5.0a11 > > > > > > Andrew > > > > > > On Fri, Dec 23, 2016 at 2:43 PM, Christian Sell > > > wrote: > > > > > > > hello, > > > > > > > > I am using SQLite, and heres my mappping > > > > > > > > #pragma db type("BLOB") section(image_section) > > > > std::vector image_data; > > > > > > > > heres the code: > > > > > > > > odb::ransaction tr(database->begin()); > > > > database->load(*obj, obj->image_section); > > > > > > > > the data in the database is perfect, and it was written through the > > same > > > > mechanism. However, when loading, I get a correct size in > > > > image_data.size(), but the data inside image_data is garbage > > > > > > > > can anyone help? > > > > thanks, Christian > > > > > > > > > > From ratkaisut at gmail.com Sat Dec 24 14:27:47 2016 From: ratkaisut at gmail.com (Sten Kultakangas) Date: Sat Dec 24 14:27:59 2016 Subject: [odb-users] do not use PRAGMA_DB macro if ODB is using gcc 6.x as underlying compiler Message-ID: Hello I found a problem related to the PRAGMA_DB macro expansion in gcc 6.2. Let's consider the following example: PRAGMA_DB(object) struct country { PRAGMA_DB(id) std::string code_; std::string name_; }; PRAGMA_DB(object) struct employee { PRAGMA_DB(id) unsigned long id_; std::string first_; }; PRAGMA_DB(view object(employee) object(country inner: employee::first_ == country::name_)) struct employee_country_objects { shared_ptr e; shared_ptr res; }; If ODB has been build to use gcc 6.2, then the above example will produce the following error: employee_.hxx:44:24: error: unable to find associated object for object pointer employee_.hxx:44:24: info: use associated object alias as this data member name When you change replace the line preceding the view definition with the following line #pragma db view object(employee) object(country inner: employee::first_ == country::name_) the above example will be compiled fine. So if you use the -Wall option, then you'll probably want to use -Wall -Wno-unknown-pragmas Best regards, Sten Kultakangas From boris at codesynthesis.com Mon Dec 26 02:03:25 2016 From: boris at codesynthesis.com (Boris Kolpackov) Date: Mon Dec 26 02:03:35 2016 Subject: [odb-users] cannot load image bytes through section In-Reply-To: <1768853872.923321.1482581158578@communicator.strato.de> References: <1218576152.919469.1482532995365@communicator.strato.de> <1090761655.919761.1482537579328@communicator.strato.de> <1768853872.923321.1482581158578@communicator.strato.de> Message-ID: Hi Christian, Christian Sell writes: > Seems it was simply broken in 2.4.0. There was a bug in handling the underlying image buffer growth. Boris From boris at codesynthesis.com Mon Dec 26 02:14:17 2016 From: boris at codesynthesis.com (Boris Kolpackov) Date: Mon Dec 26 02:14:27 2016 Subject: [odb-users] do not use PRAGMA_DB macro if ODB is using gcc 6.x as underlying compiler In-Reply-To: References: Message-ID: Hi Sten, Sten Kultakangas writes: > If ODB has been build to use gcc 6.2, then the above example will > produce the following error: > > employee_.hxx:44:24: error: unable to find associated object for object pointer > employee_.hxx:44:24: info: use associated object alias as this data member name I could reproduce this (thanks for the test case) and it seems to be another GCC 6-specific issue. Everything works fine with GCC 5. I will look into this and will keep you updated. Boris From boris at codesynthesis.com Mon Dec 26 02:29:53 2016 From: boris at codesynthesis.com (Boris Kolpackov) Date: Mon Dec 26 02:30:03 2016 Subject: [odb-users] Sections in view's result causes exception In-Reply-To: References: <2E9AD32A-7168-4FD2-8686-466B4A3C7163@gmail.com> Message-ID: Hi Lukas, I would suggest that you try to simplify your test by getting rid of everything non-essential: CMake, multi-database support, etc. Ideally, what I would like to get is a header file, a source file (with main()), and the ODB command line you used to compile the header. Boris From obermann.lukas at gmail.com Mon Dec 26 08:16:18 2016 From: obermann.lukas at gmail.com (Lukas Obermann) Date: Mon Dec 26 08:16:33 2016 Subject: [odb-users] Sections in view's result causes exception In-Reply-To: References: <2E9AD32A-7168-4FD2-8686-466B4A3C7163@gmail.com> Message-ID: <526B78F7-9041-4765-9410-41F4D1703A26@gmail.com> Hi Boris, ok, I did remove everything not needed until it started to work, and then added in one part after another. While not yet being able to reproduce the initial issue I had yet, I came across something that may relate to it. The odb::unknown_schema exception is thrown when first creating a library out of the odb files and then linking it to the main, but only when ?multi-database dynamic is enabled. When compiling everything at once, without the library step, it does not throw the exception. So, with the code in the repo, with the following commands it works: /usr/bin/odb --multi-database dynamic -d sqlite -d common --generate-query --generate-session --generate-schema --generate-prepared --std c++11 --schema-format embedded -I/usr/local/include ODBData.h /usr/bin/odb --multi-database dynamic -d sqlite -d common --generate-query --generate-session --generate-schema --generate-prepared --std c++11 --schema-format embedded -I/usr/local/include ODBFile.h /usr/bin/c++ -std=gnu++11 -o ODBFile-odb.cxx.o -c ODBFile-odb.cxx /usr/bin/c++ -std=gnu++11 -o ODBFile-odb-sqlite.cxx.o -c ODBFile-odb-sqlite.cxx /usr/bin/c++ -std=gnu++11 -o ODBData-odb.cxx.o -c ODBData-odb.cxx /usr/bin/c++ -std=gnu++11 -o ODBData-odb-sqlite.cxx.o -c ODBData-odb-sqlite.cxx /usr/bin/c++ -std=gnu++11 -o main.cpp.o -c main.cpp /usr/bin/c++ main.cpp.o ODBFile-odb.cxx.o ODBFile-odb-sqlite.cxx.o ODBData-odb.cxx.o ODBData-odb-sqlite.cxx.o -lodb -lodb-sqlite -lsqlite3 And the with the following it throws an odb::unknown_schema exception: /usr/bin/odb --multi-database dynamic -d sqlite -d common --generate-query --generate-session --generate-schema --generate-prepared --std c++11 --schema-format embedded -I/usr/local/include ODBData.h /usr/bin/odb --multi-database dynamic -d sqlite -d common --generate-query --generate-session --generate-schema --generate-prepared --std c++11 --schema-format embedded -I/usr/local/include ODBFile.h /usr/bin/c++ -std=gnu++11 -o ODBFile-odb.cxx.o -c ODBFile-odb.cxx /usr/bin/c++ -std=gnu++11 -o ODBFile-odb-sqlite.cxx.o -c ODBFile-odb-sqlite.cxx /usr/bin/c++ -std=gnu++11 -o ODBData-odb.cxx.o -c ODBData-odb.cxx /usr/bin/c++ -std=gnu++11 -o ODBData-odb-sqlite.cxx.o -c ODBData-odb-sqlite.cxx /usr/bin/ar qc libodb_binding.a ODBFile-odb.cxx.o ODBFile-odb-sqlite.cxx.o ODBData-odb.cxx.o ODBData-odb-sqlite.cxx.o /usr/bin/c++ -std=gnu++11 -o main.cpp.o -c main.cpp /usr/bin/c++ main.cpp.o libodb_binding.a -lodb -lodb-sqlite -lsqlite3 I assume that this relates to the other exception that is thrown in the main program. Do you have an idea what could be happening here? Thanks, Lukas > Am 26.12.2016 um 08:29 schrieb Boris Kolpackov : > > Hi Lukas, > > I would suggest that you try to simplify your test by getting rid of > everything non-essential: CMake, multi-database support, etc. Ideally, > what I would like to get is a header file, a source file (with main()), > and the ODB command line you used to compile the header. > > Boris From boris at codesynthesis.com Mon Dec 26 09:49:10 2016 From: boris at codesynthesis.com (Boris Kolpackov) Date: Mon Dec 26 09:49:25 2016 Subject: [odb-users] Sections in view's result causes exception In-Reply-To: <526B78F7-9041-4765-9410-41F4D1703A26@gmail.com> References: <2E9AD32A-7168-4FD2-8686-466B4A3C7163@gmail.com> <526B78F7-9041-4765-9410-41F4D1703A26@gmail.com> Message-ID: Hi Lukas, Lukas Obermann writes: > The odb::unknown_schema exception is thrown when first creating a library > out of the odb files and then linking it to the main [...] This is a well known pitfall of static libraries. See this earlier post for details: http://www.codesynthesis.com/pipermail/odb-users/2013-May/001286.html Boris From obermann.lukas at gmail.com Mon Dec 26 10:06:38 2016 From: obermann.lukas at gmail.com (Lukas Obermann) Date: Mon Dec 26 10:06:53 2016 Subject: [odb-users] Sections in view's result causes exception In-Reply-To: References: <2E9AD32A-7168-4FD2-8686-466B4A3C7163@gmail.com> <526B78F7-9041-4765-9410-41F4D1703A26@gmail.com> Message-ID: <9D6CBEEC-1509-4ECB-B6B7-8847A759AC83@gmail.com> Hi Boris, thanks for pointing that out. I will see if I can link directly without the library step in between. I will keep you posted on the result. Thank you! Lukas > Am 26.12.2016 um 15:49 schrieb Boris Kolpackov : > > Hi Lukas, > > Lukas Obermann writes: > >> The odb::unknown_schema exception is thrown when first creating a library >> out of the odb files and then linking it to the main [...] > > This is a well known pitfall of static libraries. See this earlier post > for details: > > http://www.codesynthesis.com/pipermail/odb-users/2013-May/001286.html > > Boris From boris at codesynthesis.com Wed Dec 28 04:12:43 2016 From: boris at codesynthesis.com (Boris Kolpackov) Date: Wed Dec 28 04:19:36 2016 Subject: [odb-users] do not use PRAGMA_DB macro if ODB is using gcc 6.x as underlying compiler In-Reply-To: References: Message-ID: Hi Sten, Ok, the fix is in master: http://scm.codesynthesis.com/?p=odb/odb.git;a=commit;h=1f87ed70f983bc0fb920a0e1360de0977fe10c9f Thanks again for the report/test case and let me know if you run into any other issues with GCC 6. Boris From harriev9 at gmail.com Wed Dec 28 06:43:03 2016 From: harriev9 at gmail.com (harriev9) Date: Wed Dec 28 06:43:17 2016 Subject: [odb-users] Compiling ODB and others from source Message-ID: <1482925383.17053.1.camel@gmail.com> Hi, I am trying to compile ODB from the source. I fetched the code from: http://scm.codesynthesis.com/?s=odb/ but when i run ./bootstrap i get an error: configure.ac:12: error: possibly undefined macro: m4_equote now i found somewhere its better not to use ./bootstrap and use the configure from the repository. However the configure file was not in git. Can you tell me where to fetch it? or am i missing something. Greetings, Harrie Versteden From zwmosquito at 126.com Wed Dec 28 21:20:24 2016 From: zwmosquito at 126.com (Wayne Zhang) Date: Wed Dec 28 21:20:37 2016 Subject: [odb-users] Cross-compiling issue with ODB source code Message-ID: <309127bd.26bf.1594860da4f.Coremail.zwmosquito@126.com> Dear developers, Recently I compiled odb source code on my local VM ( Ubuntu 16.04.1, with gcc 4.9.3 ), and expected it could work on another Linux server ( Redhat with gcc 4.1.2, very old but I don't have root access to upgrade it ). It complained something like this: odb: /lib64/libc.so.6: version `GLIBC_2.14' not found (required by odb) odb: /usr/lib64/libstdc++.so.6: version `GLIBCXX_3.4.20' not found (required by /var/fpwork/w39zhang/CBTS_HA_POC/ODB_root/lib/libcutl-1.10.so) odb: /usr/lib64/libstdc++.so.6: version `GLIBCXX_3.4.11' not found (required by /var/fpwork/w39zhang/CBTS_HA_POC/ODB_root/lib/libcutl-1.10.so) odb: /usr/lib64/libstdc++.so.6: version `GLIBCXX_3.4.9' not found (required by /var/fpwork/w39zhang/CBTS_HA_POC/ODB_root/lib/libcutl-1.10.so) odb: /usr/lib64/libstdc++.so.6: version `GLIBCXX_3.4.15' not found (required by /var/fpwork/w39zhang/CBTS_HA_POC/ODB_root/lib/libcutl-1.10.so) odb: /lib64/libc.so.6: version `GLIBC_2.14' not found (required by /var/fpwork/w39zhang/CBTS_HA_POC/ODB_root/lib/libcutl-1.10.so) make: *** [gen] Error 1 I learnt from google that it was a cross-compiling issue but I don't have such experience to fix it. After trying in many ways ( passing "-static-libstdc++ -static-libgcc" to LDFLAGS, or hardcode "-Wl,-rpath" with Ubuntu libstdc++.so.6 in odb/libtool ), I have to admit my poor knowledge in Linux :'( I notice that odb executable and odb plugin "odb.so" in official release ( odb-2.4.0-x86_64-linux-gnu.tar.bz2 ) work quite perfectly on that Redhat server. They both have less dependencies than the one I have built. The differences between my plugin and the official one: ## plugin built by me $ ldd odb.so ./odb.so: /usr/lib64/libstdc++.so.6: version `GLIBCXX_3.4.15' not found (required by ./odb.so) ./odb.so: /usr/lib64/libstdc++.so.6: version `GLIBCXX_3.4.20' not found (required by /var/fpwork/w39zhang/CBTS_HA_POC/ODB_root/lib/libcutl-1.10.so) ./odb.so: /usr/lib64/libstdc++.so.6: version `GLIBCXX_3.4.11' not found (required by /var/fpwork/w39zhang/CBTS_HA_POC/ODB_root/lib/libcutl-1.10.so) ./odb.so: /usr/lib64/libstdc++.so.6: version `GLIBCXX_3.4.9' not found (required by /var/fpwork/w39zhang/CBTS_HA_POC/ODB_root/lib/libcutl-1.10.so) ./odb.so: /usr/lib64/libstdc++.so.6: version `GLIBCXX_3.4.15' not found (required by /var/fpwork/w39zhang/CBTS_HA_POC/ODB_root/lib/libcutl-1.10.so) ./odb.so: /lib64/libc.so.6: version `GLIBC_2.14' not found (required by /var/fpwork/w39zhang/CBTS_HA_POC/ODB_root/lib/libcutl-1.10.so) linux-vdso.so.1 => (0x00007fff8f5ff000) libcutl-1.10.so => /var/fpwork/w39zhang/CBTS_HA_POC/ODB_root/lib/libcutl-1.10.so (0x00007f701df92000) libstdc++.so.6 => /usr/lib64/libstdc++.so.6 (0x00007f701dc46000) libc.so.6 => /lib64/libc.so.6 (0x00007f701d8ed000) libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f701d6d1000) libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007f701d4c2000) libm.so.6 => /lib64/libm.so.6 (0x00007f701d23f000) /lib64/ld-linux-x86-64.so.2 (0x0000003307800000) ## official plugin ( odb-2.4.0-x86_64-linux-gnu.tar.bz2 ) $ ldd odb.so linux-vdso.so.1 => (0x00007fff6a7ff000) libm.so.6 => /lib64/libm.so.6 (0x00007f9f8c7f9000) libc.so.6 => /lib64/libc.so.6 (0x00007f9f8c4a0000) /lib64/ld-linux-x86-64.so.2 (0x0000003307800000) May I ask how did you do that? I want to static link with libcutl and stdc++ lib just like the offical release. And the different version of libc.so.6 is also a problem ( Ubuntu VM uses GLIBC 2.23 but Redhat server uses GLIBC 2.5 ). Expecting your reply. Thanks! Br, Wayne From harriev9 at gmail.com Thu Dec 29 05:02:09 2016 From: harriev9 at gmail.com (harriev9) Date: Thu Dec 29 05:02:25 2016 Subject: [odb-users] Re: Compiling ODB and others from source In-Reply-To: <1482925383.17053.1.camel@gmail.com> References: <1482925383.17053.1.camel@gmail.com> Message-ID: <1483005729.2161.0.camel@gmail.com> Hi, Sorry, found the answer in: http://www.codesynthesis.com/pipermail/odb-users/2013-June/001302.html On Wed, 2016-12-28 at 12:43 +0100, harriev9 wrote: > Hi, > > I am trying to compile ODB from the source. > I fetched the code from: > > http://scm.codesynthesis.com/?s=odb/ > > but when i run ./bootstrap i get an error: > > configure.ac:12: error: possibly undefined macro: m4_equote > > now i found somewhere its better not to use ./bootstrap and > use the configure from the repository. > > However the configure file was not in git. > > Can you tell me where to fetch it? or am i missing something. > > Greetings, > Harrie Versteden From boris at codesynthesis.com Fri Dec 30 01:44:00 2016 From: boris at codesynthesis.com (Boris Kolpackov) Date: Fri Dec 30 01:44:06 2016 Subject: [odb-users] Re: Compiling ODB and others from source In-Reply-To: <1483005729.2161.0.camel@gmail.com> References: <1482925383.17053.1.camel@gmail.com> <1483005729.2161.0.camel@gmail.com> Message-ID: Hi Harrie, You can also get a fairly recent packaged pre-release (currently a11) here: http://codesynthesis.com/~boris/tmp/odb/pre-release/ Boris From boris at codesynthesis.com Fri Dec 30 01:57:27 2016 From: boris at codesynthesis.com (Boris Kolpackov) Date: Fri Dec 30 01:57:35 2016 Subject: [odb-users] Cross-compiling issue with ODB source code In-Reply-To: <309127bd.26bf.1594860da4f.Coremail.zwmosquito@126.com> References: <309127bd.26bf.1594860da4f.Coremail.zwmosquito@126.com> Message-ID: Hi Wayne, Wayne Zhang writes: > [...] Redhat with gcc 4.1.2, very old but I don't have root access to > upgrade it. BTW, the recommended way to do this on RedHat/CentOS is to install Developer Tools (which include newer version of GCC) and use that to either build the ODB compiler or get the pre-built packages from EPEL. > odb: /lib64/libc.so.6: version `GLIBC_2.14' not found (required by odb) > > [...] > > After trying in many ways ( passing "-static-libstdc++ -static-libgcc" > to LDFLAGS, or hardcode "-Wl,-rpath" with Ubuntu libstdc++.so.6 in > odb/libtool ) [...] Linking statically to libstdc++ and libgcc generally helps but in your case you have a libc incompatibility. Linking statically to libc is a bad idea. > I notice that odb executable and odb plugin "odb.so" in official release ( odb-2.4.0-x86_64-linux-gnu.tar.bz2 ) work quite perfectly on that > Redhat server. [...] > > May I ask how did you do that? To achieve this we build these packages on a very old Debian distribution (Sarge). We link statically to libstdc++ and libgcc but not libc. Also note that if you go this route you will have to ship the entire GCC installation since the ODB plugin will only work with the version of GCC it was built with. In other words, you cannot build it with GCC 4.8 and then expect it to work with GCC 4.7 or 4.9. One thing you could try is use GCC from the official ODB package for RH to build a newer ODB compiler directly on RH. Boris From harriev9 at gmail.com Fri Dec 30 07:08:43 2016 From: harriev9 at gmail.com (harriev9) Date: Fri Dec 30 07:08:56 2016 Subject: [odb-users] Re: Compiling ODB and others from source In-Reply-To: References: <1482925383.17053.1.camel@gmail.com> <1483005729.2161.0.camel@gmail.com> Message-ID: <1483099723.2151.0.camel@gmail.com> Boris, Thank you. I will give it a try. Harrie On Fri, 2016-12-30 at 08:44 +0200, Boris Kolpackov wrote: > Hi Harrie, > > You can also get a fairly recent packaged pre-release (currently a11) > here: > > http://codesynthesis.com/~boris/tmp/odb/pre-release/ > > Boris