From Hugo.Mildenberger at web.de Fri Mar 1 05:51:27 2013 From: Hugo.Mildenberger at web.de (Hugo.Mildenberger@web.de) Date: Fri Mar 1 05:51:39 2013 Subject: [odb-users] Help, how to generate the hxx files automately by odb In-Reply-To: <20130221140943.d710c2812e6cb1b558a4a614@zotac.lan> References: <1360739763.19664.9.camel@localhost.localdomain> <20130221140943.d710c2812e6cb1b558a4a614@zotac.lan> Message-ID: <20130301115127.1af855b7944cc56719728096@zotac.lan> > > > I have a database based on mysql, how can i generate all hxx files > > > by odb not by myself manually? > > > > No, this is not yet supported. We do have plans for an SQL-to-C++ > > compiler, thought. > > I'd appreciate it very much if this functionality became integrated with ODB (and PostgreSQL). Such a program will foster a server-centric development style which in turn may result in a lean and consistent client - server interface, in enhanced maintainability, but also in a reduced network load if data processing is mainly done inside of stored procedures. Even updatable views spanning several tables are possible with a server-centric approach. But there would be also a great reduction of the effort required for the evaluation of a database design alternative (just run make once more to regenerate the client plugin), and unit-testing covering the whole client-server communication could be easily automated. In short, the integration of such a tool would mean a big relief to all those who have ever been forced to develop or maintain a poorly designed graphical user interface. > > > Best Below is a proof of concept of this idea. odb generated the database access code for a C++ class named "telecom", which tries to accesses a table of the same name. Now the very same code runs db->persist(telecom), db->update(telecom) and db->erase(telecom) without a problem also on a view having a trigger procedure attached. I'm interested to know what you think about this approach ... Hugo --- begin; drop table if exists telecom_table cascade; drop table if exists telecom_type cascade; drop view if exists telecom cascade; create table telecom_type ( id serial not null primary key, name text not null unique ); create table telecom_table ( type int references telecom_type(id) not null, priority text not null, uri text not null, purpose text not null, id serial not null primary key); create view telecom as select b.name as type, a.priority, a.uri, a.purpose, a.id from telecom_table as a, telecom_type as b where b.id = a.type; create or replace function telecom_modify() returns trigger language plpgsql as $function$ declare type_id integer; begin case tg_op when 'INSERT' then select id from telecom_type where name=new.type into type_id; if not found then with a as ( insert into telecom_type(name) values(new.type) returning id ) select id from a into type_id; end if; with a as ( insert into telecom_table(type, priority, uri, purpose) values(type_id, new.priority, new.uri, new.purpose) returning id ) select id from a into new.id; return new; when 'UPDATE' then select id from telecom_type where name=new.type into type_id; if not found then with a as ( insert into telecom_type(name) values(new.type) returning id ) select id from a into type_id; end if; with a as ( update telecom_table set type = type_id, priority = new.priority, uri = new.uri, purpose = new.purpose where id = old.id returning id ) select id from a into new.id; return new; when 'DELETE' then delete from telecom_table where id = old.id; if not found then return null; end if; return old; else raise EXCEPTION 'tg_op % is unknown',quote_literal(tg_op); end case; return new; end; $function$; create trigger telecom_trigger instead of insert or update or delete on telecom for each row execute procedure telecom_modify(); end; -- vim:ts=4:sw=4 -- Hugo Mildenberger From boris at codesynthesis.com Fri Mar 1 07:32:43 2013 From: boris at codesynthesis.com (Boris Kolpackov) Date: Fri Mar 1 07:32:52 2013 Subject: [odb-users] Help, how to generate the hxx files automately by odb In-Reply-To: <20130301115127.1af855b7944cc56719728096@zotac.lan> References: <1360739763.19664.9.camel@localhost.localdomain> <20130221140943.d710c2812e6cb1b558a4a614@zotac.lan> <20130301115127.1af855b7944cc56719728096@zotac.lan> Message-ID: Hi Hugo, Hugo.Mildenberger@web.de writes: > Below is a proof of concept of this idea. odb generated the database access > code for a C++ class named "telecom", which tries to accesses a table of > the same name. Now the very same code runs db->persist(telecom), > db->update(telecom) and db->erase(telecom) without a problem also on a > view having a trigger procedure attached. I'm interested to know what > you think about this approach ... I don't see anything wrong with this as an example of mapping a C++ class to a custom (existing) schema. At the same time, if we are talking about automatically generating C++ classes from the database schema, then this would be a good example why some (including myself) think that we could be opening a big can of worms ;-). Specifically, I don't see ODB being able to figure out what's going on in this example: i.e., that there is an "updatable" view of two tables and that it should map this view to an object instead of mapping the other two tables to two separate objects. ODB can't yet read someone's mind ;-). Boris From Hugo.Mildenberger at web.de Fri Mar 1 09:18:25 2013 From: Hugo.Mildenberger at web.de (Hugo.Mildenberger@web.de) Date: Fri Mar 1 09:18:39 2013 Subject: [odb-users] Help, how to generate the hxx files automately by odb In-Reply-To: References: <1360739763.19664.9.camel@localhost.localdomain> <20130221140943.d710c2812e6cb1b558a4a614@zotac.lan> <20130301115127.1af855b7944cc56719728096@zotac.lan> Message-ID: <20130301151825.438636c1989751a59fe324f5@zotac.lan> Hi Boris, On Fri, 1 Mar 2013 14:32:43 +0200 Boris Kolpackov wrote: > I don't see anything wrong with this as an example of mapping a C++ > class to a custom (existing) schema. > > At the same time, if we are talking about automatically generating > C++ classes from the database schema, then this would be a good example > why some (including myself) think that we could be opening a big can of > worms ;-). Leaving aside rotten cans and also neglecting the real costs of data round trips (e.g. http://blog.endpoint.com/2012/10/the-real-cost-of-data-roundtrip.html) plus the potential costs of inconsistencies and data leaks (which both become more likely with more data on the wire and more SQL statements created on the fly), the crucial question is where the complexity should reside. I do prefer clearly defined interfaces and thus self-contained, testable units on all implementation levels, but I can understand that you have to fear high support costs assuming that many of your clients may choose to use pre-existent databases with ODB, simply because you also provided a class mapper. > Specifically, I don't see ODB being able to figure out what's going on > in this example: i.e., that there is an "updatable" view of two tables > and that it should map this view to an object instead of mapping the > other two tables to two separate objects. ODB can't yet read someone's > mind ;-). It would be sufficient if a table-to-C++ class mapper was able to read his own command line options, say --views-only or --tables='odb_.*'. However, it might be difficult to read the mind of a database view when it comes to primary keys and data types. I haven't looked into this detail yet, but because the definition of a view lists and associates any table and column it draws the data from, it should also be possible to query the system tables for views as it is possible for 'real' tables. That way you could even detect the case when your traditional, read-only view model is appropriate and sufficient. Hugo From Hugo.Mildenberger at web.de Sat Mar 2 05:21:50 2013 From: Hugo.Mildenberger at web.de (Hugo.Mildenberger@web.de) Date: Sat Mar 2 05:21:58 2013 Subject: [odb-users] odb-2.2.1: calling db->persist() twice on the the instance results in two database entries Message-ID: <20130302112150.9b2f3495f56524089e0d6916@zotac.lan> ODB creates two copies of the same instance in the database if db->persist() was called twice on it. I looked up the documentation but did not found this being documented behaviour. Perhaps I missed something important here? I had expected db->persist() throwing an exception in this case. Specifically, this program: int main (int argc, char* argv[]) { cif::imp::telecom telecom("private","0","email","sombody.1@example.com"); try { std::auto_ptr db (new odb::pgsql::database (argc, argv)); odb::transaction t (db->begin ()); db->persist(telecom); telecom.set_type("voip"); telecom.set_uri("somebody.2@example.com"); db->persist(telecom); t.commit (); } catch (const odb::exception& e) { std::cerr << e.what () << std::endl; return 1; } return 0; } and this class definition: namespace odb { class access; } namespace cif { namespace imp { #pragma db object class telecom { public: [...] private: friend class odb::access; std::string _type; std::string _priority; std::string _uri; std::string _purpose; #pragma db id auto std::size_t _id; }; } /* namespace cif */ } /* namespace imp */ and this (PostgreSQL) table definition: /* This file was generated by ODB, object-relational mapping (ORM) * compiler for C++. */ DROP TABLE IF EXISTS "telecom" CASCADE; DROP VIEW IF EXISTS "telecom" CASCADE; CREATE TABLE "telecom" ( "type" TEXT NOT NULL, "priority" TEXT NOT NULL, "uri" TEXT NOT NULL, "purpose" TEXT NOT NULL, "id" BIGSERIAL NOT NULL PRIMARY KEY); resulted in: $ psql -c "select * from telecom" type | priority | uri | purpose | id -------+----------+------------------------+---------+---- email | 0 | sombody.1@example.com | private | 1 voip | 0 | somebody.2@example.com | private | 2 From Hugo.Mildenberger at web.de Sat Mar 2 06:11:16 2013 From: Hugo.Mildenberger at web.de (Hugo.Mildenberger@web.de) Date: Sat Mar 2 06:11:25 2013 Subject: [odb-users] odb-2.2.1: calling db->persist() twice on the same instance results in two database entries In-Reply-To: <20130302112150.9b2f3495f56524089e0d6916@zotac.lan> References: <20130302112150.9b2f3495f56524089e0d6916@zotac.lan> Message-ID: <20130302121116.0e17102c44da417d0da7b67c@zotac.lan> On Sat, 2 Mar 2013 11:21:50 +0100 Hugo.Mildenberger@web.de wrote: > ODB creates two copies of the same instance in the database if db->persist() was called twice on it. I looked up the documentation but did not found this being documented behaviour. Perhaps I missed something important here? I had expected db->persist() throwing an exception in this case. When analysing this problem using gdb, the reason appears to be that odb::database::persist() unconditionally passes "DEFAULT" instead of inserting the already known value for 'id' as it was returned from previous call to persist(). Consequently, st.execute() will never fail for a duplicate entry and thus the exception returned by "object_already_persistent()" will never been thrown, well, except for errors of a very different nature. (gdb) bt #0 odb::access::object_traits_impl::persist (db=..., obj=...) at odb/telecom-imp-odb.cxx:446 #1 0x00000000004033b3 in odb::database::persist_ (this=0x1cbbf50, obj=...) at /usr/include/odb/database.txx:37 #2 0x000000000040329d in odb::database::persist (this=0x1cbbf50, obj=...) at /usr/include/odb/database.ixx:78 #3 0x0000000000402cc6 in main (argc=1, argv=0x3aeb88f1b68) at telecom.cxx:24 (gdb) list telecom-imp-odb.cxx:446 441 sts.insert_image_version (im.version); 442 imb.version++; 443 } 444 445 insert_statement& st (sts.persist_statement ()); 446 if (!st.execute ()) 447 throw object_already_persistent (); 448 449 obj._id = static_cast< id_type > (st.id ()); 450 (gdb) print obj $2 = (odb::access::object_traits::object_type &) @0x3aeb88f19c0: {_type = "email", _priority = "0", _uri = "sombody.1@example.com", _purpose = "private", _id = 4} (gdb) print st $3 = ( odb::pgsql::insert_statement &) @0x1cc6fb0: { = { = { = {counter_ = 1, callback_ = 0x0}, _vptr.statement = 0x36ab19a1490 }, conn_ = @0x1cbc120, name_copy_ = "", name_ = 0x408290 ::persist_statement_name> "cif_imp_telecom_persist", text_copy_ = "", text_ = 0x408360 ::persist_statement> "INSERT INTO \"telecom\" (\"type\",\"priority\",\"uri\",\"purpose\",\"id\") VALUES ($1,$2,$3,$4,DEFAULT) RETURNING \"id\"", deallocated_ = false}, param_ = @0x1cc7348, native_param_ = @0x1cc7420, returning_ = true, id_ = 4} From boris at codesynthesis.com Sat Mar 2 06:27:49 2013 From: boris at codesynthesis.com (Boris Kolpackov) Date: Sat Mar 2 06:27:57 2013 Subject: [odb-users] odb-2.2.1: calling db->persist() twice on the the instance results in two database entries In-Reply-To: <20130302112150.9b2f3495f56524089e0d6916@zotac.lan> References: <20130302112150.9b2f3495f56524089e0d6916@zotac.lan> Message-ID: Hi Hugo, Hugo.Mildenberger@web.de writes: > #pragma db id auto > std::size_t _id; You have a persistent class with automatically-assigned id. This means that every time you persist an instance of this class, ODB will assign a new id, which by design cannot conflict with any existing id. I anticipate you will suggest that ODB should somehow recognize that the id has been assigned by a previous call to persist(). Note, however, that there is no way for ODB to know whether the value in the _id member is a valid object id or some uninitialized garbage. It is also pretty easy to make a check like this yourself. For example, you could initialize the _id member to 0 for transient objects (the assigned id can never be 0) and then check that it is 0 in the pre_persist callback. For example: #pragma db object callback(check) class telecom { public: telecom (): _id (0) {} void check (odb::callback_event e, odb::database&) const { if (e == odb::callback_event::pre_persist) if (_id != 0) throw odb::object_already_persistent (); } ... #pragma db id auto std::size_t _id; }; Boris From nachum.moshe at gmail.com Sun Mar 3 03:16:18 2013 From: nachum.moshe at gmail.com (Nachum Moshe) Date: Sun Mar 3 03:16:26 2013 Subject: [odb-users] Is ODB supported on FreeBSD platform Message-ID: Hi, I would like to use ODB with SQlite on FreeBSD platform. Is there any solution for that. Is ODB supported on this platform. If yes, I appreciate a reply with such instructions. Thanks, Nachum. From boris at codesynthesis.com Sun Mar 3 07:19:40 2013 From: boris at codesynthesis.com (Boris Kolpackov) Date: Sun Mar 3 07:19:48 2013 Subject: [odb-users] Is ODB supported on FreeBSD platform In-Reply-To: References: Message-ID: Hi Nachum, Nachum Moshe writes: > I would like to use ODB with SQlite on FreeBSD platform. Is there any > solution for that. Is ODB supported on this platform. While we haven't tested ODB on FreeBSD ourselves, I don't see why it won't work (and if there are any issues, we can always fix them). The trickiest part will probably be building the ODB compiler itself, for which we need a fairly recent version of GCC with plugin support. I am not too familiar with FreeBSD but I did some research and it appears gcc 4.6 is available as a lang/gcc port (installed as gcc46, g++46, etc). There is also a port for DragonEgg which also requires plugin support, so I am pretty sure the gcc build in FreeBSD has plugin support enabled. If all this is correct, then building the ODB compiler should be a breeze. First build libcutl: ./configure CC=gcc46 CXX=g++46 make make install Then, do the same for the ODB compiler itself: ./configure CC=gcc46 CXX=g++46 make make install This will build the ODB compiler which will use FreeBSD's g++46 for C++ parsing. Once this is done, building the runtimes (libodb and libodb-sqlite) should be straightforward. Note also that you don't have to use GCC 4.6 for runtimes (or your application). You can use the stock GCC (or any other version, or even Clang) instead. Let us know if you run into any issues. Boris From Patrick.Rotsaert at intoit.be Sun Mar 3 11:19:30 2013 From: Patrick.Rotsaert at intoit.be (Patrick Rotsaert) Date: Sun Mar 3 11:19:40 2013 Subject: [odb-users] Loading persistent object using custom joins Message-ID: <6790257A-8DE9-44E0-BDDD-A0209E704F95@intoit.be> Hi, I'm trying to find a way to load persistent objects using a join. I know joins can be done with views, but if I understand correctly, views contain only a subset of the objects involved. I'm interested in the 'complete' objects and possible operate on them. Consider following 2 objects: #pragma db object class employer { ... #pragma db id unsigned long id_; std::string name_; }; #pragma db object class employee { ... #pragma db id unsigned long id_; std::string first_; std::string last_; unsigned short age_; shared_ptr employer_; }; Suppose I'd like to query all employers that have employees under 30 years of age. In SQL speak, that would be something like: SELECT DISTINCT employer.* FROM employee NATURAL JOIN employer WHERE employee.age < 30 How can this be done, so I have an odb::result to work with? Thanks, Pat From boris at codesynthesis.com Sun Mar 3 12:00:10 2013 From: boris at codesynthesis.com (Boris Kolpackov) Date: Sun Mar 3 12:00:21 2013 Subject: [odb-users] Loading persistent object using custom joins In-Reply-To: <6790257A-8DE9-44E0-BDDD-A0209E704F95@intoit.be> References: <6790257A-8DE9-44E0-BDDD-A0209E704F95@intoit.be> Message-ID: Hi Patrick, Patrick Rotsaert writes: > I know joins can be done with views, but if I understand correctly, > views contain only a subset of the objects involved. More precisely, views can contain a subset or a full set of data members from one or more objects. > #pragma db object > class employer > { > ... > > #pragma db id > unsigned long id_; > > std::string name_; > }; > > #pragma db object > class employee > { > ... > > #pragma db id > unsigned long id_; > > std::string first_; > std::string last_; > > unsigned short age_; > > shared_ptr employer_; > }; > > Suppose I'd like to query all employers that have employees under 30 > years of age. In ODB you can reference data members from the pointed-to objects (one level deep) in queries. So, if, for example, you wanted to find all the employees that have "Example, Inc" as an employer, then you could do: typedef odb::query query; typedef odb::result result; result r (db.query (query::empployer->name == "Example, Inc")); Your query is a bit different, however. First of all, there is no "back" pointer from employer to employees, but even if we added one, it would have been a container and there is no support for using containers in queries, yet. > In SQL speak, that would be something like: > SELECT DISTINCT employer.* > FROM employee > NATURAL JOIN employer > WHERE employee.age < 30 > > How can this be done, so I have an odb::result to work with? The only way to achieve this that I can think of is to use a view to get the list of ids of all the employers that have employees under 30. Then, you can use these ids to load each employer: #pragma db view object(employer) \ object(employee) \ query((?) + "GROUP BY" + employer::id_) struct employers { #pragma db column(employer::id_) unsigned long id; }; typedef odb::query query; typedef odb::result result; result r (db.query (query::employee::age < 30)); for (const employers& es: r) { shared_ptr e (db.load (es.id)); ... } Boris From Patrick.Rotsaert at intoit.be Sun Mar 3 12:22:15 2013 From: Patrick.Rotsaert at intoit.be (Patrick Rotsaert) Date: Sun Mar 3 12:22:25 2013 Subject: [odb-users] Loading persistent object using custom joins In-Reply-To: References: <6790257A-8DE9-44E0-BDDD-A0209E704F95@intoit.be> Message-ID: <5F9F49EA-815A-4641-82F2-D0919BBB2203@intoit.be> Hi Boris, thanks for the swift answer. I think I'll manage it like that. Any chance there will be a future possibility to load objects directly from arbitrary SQL queries (select tablename.* from...), perhaps only specifying the part starting from 'from...' ? The built-in query language covers most of my use cases, but it's for that occasional special situation that I think that might be really useful. Pat On 3-mrt.-2013, at 18:00, Boris Kolpackov wrote: > Hi Patrick, > > Patrick Rotsaert writes: > >> I know joins can be done with views, but if I understand correctly, >> views contain only a subset of the objects involved. > > More precisely, views can contain a subset or a full set of data > members from one or more objects. > > >> #pragma db object >> class employer >> { >> ... >> >> #pragma db id >> unsigned long id_; >> >> std::string name_; >> }; >> >> #pragma db object >> class employee >> { >> ... >> >> #pragma db id >> unsigned long id_; >> >> std::string first_; >> std::string last_; >> >> unsigned short age_; >> >> shared_ptr employer_; >> }; >> >> Suppose I'd like to query all employers that have employees under 30 >> years of age. > > In ODB you can reference data members from the pointed-to objects (one > level deep) in queries. So, if, for example, you wanted to find all the > employees that have "Example, Inc" as an employer, then you could do: > > typedef odb::query query; > typedef odb::result result; > > result r (db.query (query::empployer->name == "Example, Inc")); > > Your query is a bit different, however. First of all, there is no "back" > pointer from employer to employees, but even if we added one, it would > have been a container and there is no support for using containers in > queries, yet. > > >> In SQL speak, that would be something like: >> SELECT DISTINCT employer.* >> FROM employee >> NATURAL JOIN employer >> WHERE employee.age < 30 >> >> How can this be done, so I have an odb::result to work with? > > The only way to achieve this that I can think of is to use a view to get > the list of ids of all the employers that have employees under 30. Then, > you can use these ids to load each employer: > > #pragma db view object(employer) \ > object(employee) \ > query((?) + "GROUP BY" + employer::id_) > struct employers > { > #pragma db column(employer::id_) > unsigned long id; > }; > > typedef odb::query query; > typedef odb::result result; > > result r (db.query (query::employee::age < 30)); > > for (const employers& es: r) > { > shared_ptr e (db.load (es.id)); > ... > } > > Boris From Hugo.Mildenberger at web.de Mon Mar 4 05:01:53 2013 From: Hugo.Mildenberger at web.de (Hugo.Mildenberger@web.de) Date: Mon Mar 4 05:02:03 2013 Subject: [odb-users] odb-2.2.1 should install the odb.so plugin into $(gcc -print-file-name=plugin) Message-ID: <20130304110153.5b753c2f4d25cceb0a2c7dc8@zotac.lan> Starting with odb-2.2.*, the 'odb.so' plugin gets installed into '/usr/libexec/odb/odb.so'. This is much better than installing into /usr/bin, but the odb plugin still depends on the version of gcc it was compiled with. So, if you switch between gcc versions, the plugin does not match the compiler version. On Gentoo at least, plugins can be installed into '/usr/libexec/gcc///plugin/', which should solve this problem because gcc then selects the right path depending on its own version. http://gcc.gnu.org/onlinedocs/gccint/Plugins-loading.html#Plugins-loading says: A plugin can be simply given by its short name (no dots or slashes). When simply passing -fplugin=name, the plugin is loaded from the plugin directory, so -fplugin=name is the same as -fplugin=`gcc -print-file-name=plugin`/name.so, using backquote shell syntax to query the plugin directory. $gcc -print-file-name=plugin /usr/lib/gcc/x86_64-pc-linux-gnu/4.7.2/plugin $ sudo gcc-config x86_64-pc-linux-gnu-4.6.3 * Switching native-compiler to x86_64-pc-linux-gnu-4.6.3 ... $ source /etc/profile $ gcc -print-file-name=plugin /usr/lib/gcc/x86_64-pc-linux-gnu/4.6.3/plugin From boris at codesynthesis.com Mon Mar 4 07:48:45 2013 From: boris at codesynthesis.com (Boris Kolpackov) Date: Mon Mar 4 07:48:53 2013 Subject: [odb-users] odb-2.2.1 should install the odb.so plugin into $(gcc -print-file-name=plugin) In-Reply-To: <20130304110153.5b753c2f4d25cceb0a2c7dc8@zotac.lan> References: <20130304110153.5b753c2f4d25cceb0a2c7dc8@zotac.lan> Message-ID: Hi Hugo, Hugo.Mildenberger@web.de writes: > So, if you switch between gcc versions, the plugin does not match the > compiler version. On Gentoo at least, plugins can be installed into > '/usr/libexec/gcc///plugin/', which should solve this > problem because gcc then selects the right path depending on its own > version. Yes, I can see how this can be a problem. > A plugin can be simply given by its short name (no dots or slashes). This functionality was added in GCC 4.6 and is not available in 4.5. Because of that and also because ODB can be installed into a separate --prefix compared to GCC, I don't think it would be a good idea to install the plugin into the GCC sub-directory by default. So we could have a configure option like --default-plugin-dir. On the other hand, if GCC is >=4.6 and ODB and GCC prefixes are the same, then I don't see any harm installing the plugin into GCC by default. The problem is there doesn't seem to be an easy way to figure out GCC's prefix. What do you think? Boris From boris at codesynthesis.com Mon Mar 4 08:26:46 2013 From: boris at codesynthesis.com (Boris Kolpackov) Date: Mon Mar 4 08:26:55 2013 Subject: [odb-users] Loading persistent object using custom joins In-Reply-To: <5F9F49EA-815A-4641-82F2-D0919BBB2203@intoit.be> References: <6790257A-8DE9-44E0-BDDD-A0209E704F95@intoit.be> <5F9F49EA-815A-4641-82F2-D0919BBB2203@intoit.be> Message-ID: Hi Patrick, Patrick Rotsaert writes: > Any chance there will be a future possibility to load objects directly > from arbitrary SQL queries (select tablename.* from...), perhaps only > specifying the part starting from 'from...' ? Hm, you are the first one asking for something like this. Views are normally the answer to the custom query needs (and they allows you to specify a custom SELECT statement or some portion of it). But in your case you want the actual objects, presumably so that you can update them. I think this particular example (i.e., find all the employers which have employees under 30) will be better handled by supporting containers in queries. Something along these lines: typedef odb::query employer_query; typedef odb::query employee_query; employer_query q (employer_query::employees.exist (employee_query::age < 30)); Another option that I just thought of would be to extend the view mechanism to support loading directly into an object. In other words, we could have a special kind of view which is essentially just a way to create arbitrary joins for object queries. Something along these lines: #pragma db view object(employer) object(employee) struct employer_loader { // Lack of data members indicates we are loading the first // associated object (employer). }; typedef odb::query query; typedef odb::result result; result r (db.query (query::employee::age < 30)); What do you think? Boris From Patrick.Rotsaert at intoit.be Mon Mar 4 08:34:02 2013 From: Patrick.Rotsaert at intoit.be (Patrick Rotsaert) Date: Mon Mar 4 08:34:12 2013 Subject: [odb-users] Loading persistent object using custom joins In-Reply-To: References: <6790257A-8DE9-44E0-BDDD-A0209E704F95@intoit.be> <5F9F49EA-815A-4641-82F2-D0919BBB2203@intoit.be> Message-ID: <52BB2B3A-F26B-4026-A94B-8845B106533B@intoit.be> Hi Boris, On 4-mrt.-2013, at 14:26, Boris Kolpackov wrote: > Another option that I just thought of would be to extend the view > mechanism to support loading directly into an object. In other words, > we could have a special kind of view which is essentially just a way > to create arbitrary joins for object queries. Something along these > lines: > > #pragma db view object(employer) object(employee) > struct employer_loader > { > // Lack of data members indicates we are loading the first > // associated object (employer). > }; > > typedef odb::query query; > typedef odb::result result; > > result r (db.query (query::employee::age < 30)); > > What do you think? This is exactly what I had in mind :) Pat From Hugo.Mildenberger at web.de Tue Mar 5 06:53:35 2013 From: Hugo.Mildenberger at web.de (Hugo.Mildenberger@web.de) Date: Tue Mar 5 06:53:46 2013 Subject: [odb-users] odb-2.2.1 should install the odb.so plugin into $(gcc -print-file-name=plugin) In-Reply-To: References: <20130304110153.5b753c2f4d25cceb0a2c7dc8@zotac.lan> Message-ID: <20130305125335.1209f5a03b8817eddc87d5af@zotac.lan> Hi Boris, On Mon, 4 Mar 2013 14:48:45 +0200 Boris Kolpackov wrote: > > A plugin can be simply given by its short name (no dots or slashes). > > This functionality was added in GCC 4.6 and is not available in 4.5. We live in a complicated world. So http://gcc.gnu.org/onlinedocs/gcc-4.5.1/gccint/Plugins.html, when saying "On most systems, you can query this plugin directory by invoking gcc -print-file-name=plugin (replace if needed gcc with the appropriate program path)." is wrong? The earliest available gcc-4.5 version is 4.5.1-r1 on my system. Passing -print-file-name=plugin works: $ sudo gcc-config x86_64-pc-linux-gnu-4.5.1 * Switching native-compiler to x86_64-pc-linux-gnu-4.5.1 ... $ source /etc/profile $ gcc --print-file-name=plugin /usr/lib/gcc/x86_64-pc-linux-gnu/4.5.1/plugin > Because of that and also because ODB can be installed into a separate > --prefix compared to GCC, I don't think it would be a good idea to > install the plugin into the GCC sub-directory by default. So we could > have a configure option like --default-plugin-dir. Sounds good. BTW, don't forget to update the error message informing the user that he should install the plugin into the same directory as odb (list the actual search path instead.) > On the other hand, if GCC is >=4.6 and ODB and GCC prefixes are the > same, then I don't see any harm installing the plugin into GCC by > default. The problem is there doesn't seem to be an easy way to > figure out GCC's prefix. I'm not sure what you have in mind here. If it's not cross-compilation, maybe one could extract this information by comparison of the results of '-print-filename=gcc' and '-print-sysroot' ? $ echo "gcc='$(gcc -print-file-name=gcc)'" gcc='/usr/lib/gcc/x86_64-pc-linux-gnu/4.7.2/../../../../lib64/gcc' $ echo "sysroot='$(gcc -print-sysroot)'" sysroot='' It is my understanding that ODB acts more like a filter, in so far that ODB generates source code later to be processed by a C++ compiler (which does not need to be gcc, in principle at least.) So, with cross-compilation, I'd think the plugin needs to be installed relative to the compiler determined by the '--host' configure option (an outline of the terminology is at http://gcc.gnu.org/onlinedocs/gccint/Configure-Terms.html.) Hugo From staywild at foxmail.com Tue Mar 5 06:35:17 2013 From: staywild at foxmail.com (=?ISO-8859-1?B?c3RheXdpbGQ=?=) Date: Tue Mar 5 08:25:11 2013 Subject: [odb-users] Help, problem in mysql Message-ID: Here I use the struct tm from in CI try to map this date type to datetime in MySQL database, while encountered a gcc compiling failure. Code: #pragma db type("datetime") null struct tm finishedtime; How to slove this problem? From boris at codesynthesis.com Tue Mar 5 08:48:01 2013 From: boris at codesynthesis.com (Boris Kolpackov) Date: Tue Mar 5 08:48:11 2013 Subject: [odb-users] Loading persistent object using custom joins In-Reply-To: <52BB2B3A-F26B-4026-A94B-8845B106533B@intoit.be> References: <6790257A-8DE9-44E0-BDDD-A0209E704F95@intoit.be> <5F9F49EA-815A-4641-82F2-D0919BBB2203@intoit.be> <52BB2B3A-F26B-4026-A94B-8845B106533B@intoit.be> Message-ID: Hi Patrick, Patrick Rotsaert writes: > This is exactly what I had in mind :) Ok, I've added this feature to the TODO list. If I were to implement it for the next release, will you be willing to start using it with your application in a pre-release/beta? We prefer to implement new features that someone is willing to test in the real world before the final release. Boris From boris at codesynthesis.com Tue Mar 5 09:13:51 2013 From: boris at codesynthesis.com (Boris Kolpackov) Date: Tue Mar 5 09:13:58 2013 Subject: [odb-users] odb-2.2.1 should install the odb.so plugin into $(gcc -print-file-name=plugin) In-Reply-To: <20130305125335.1209f5a03b8817eddc87d5af@zotac.lan> References: <20130304110153.5b753c2f4d25cceb0a2c7dc8@zotac.lan> <20130305125335.1209f5a03b8817eddc87d5af@zotac.lan> Message-ID: Hi Hugo, Hugo.Mildenberger@web.de writes: > $ gcc --print-file-name=plugin > /usr/lib/gcc/x86_64-pc-linux-gnu/4.5.1/plugin In GCC 4.5 this is the path where the plugin headers are installed (in the include/ subdirectory). The code to load plugins from this directory is just not there in GCC 4.5 (see gcc/plugin.c). > > On the other hand, if GCC is >=4.6 and ODB and GCC prefixes are the > > same, then I don't see any harm installing the plugin into GCC by > > default. The problem is there doesn't seem to be an easy way to > > figure out GCC's prefix. > > I'm not sure what you have in mind here. I mean if both ODB and GCC were built with the same --prefix, then it makes sense to install the ODB plugin into the GCC's plugin directory by default. > If it's not cross-compilation [...] Good point. If cross-compiling, we may not even be able to run host GCC to detect any paths, including the plugin path (i.e., -print-file-name=plugin). This complicates things significantly. Perhaps we should keep it simple and just provide an option that can be used to specify the alternative plugin installation directory. > It is my understanding that ODB acts more like a filter, in so far that ODB > generates source code later to be processed by a C++ compiler (which does > not need to be gcc, in principle at least.) That's correct. > So, with cross-compilation, I'd think the plugin needs to be installed > relative to the compiler determined by the '--host' configure option Yes, I agree. The thing is we may not be able to run this host GCC to determine the plugin installation directory. In fact, even with plugin headers, strictly speaking, things are broken right now because we use build GCC (which may not even be built with plugin support) instead of host GCC. Boris From lavik at codevalue.net Tue Mar 5 08:59:57 2013 From: lavik at codevalue.net (Lavi Kwiatkowsky) Date: Tue Mar 5 09:14:34 2013 Subject: [odb-users] Encrypting the Sqlite DB Message-ID: Hi Guys, What is the best way to integrate an encryption mechanism ? I know I can obviously encrypt the data myself and save it in the db as a string, but what If I want to have the whole database encrypted? Has anyone experimented with this? Is there a best practice? Thanks! Regards, Lavi Kwiatkowsky [Description: Description: CodeValue-Logo_03] Mobile: +972-54-6899203 E-Mail: lavik@codevalue.net Site: http://codevalue.net -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 6548 bytes Desc: image001.png Url : http://codesynthesis.com/pipermail/odb-users/attachments/20130305/cbff3e83/image001.png From boris at codesynthesis.com Tue Mar 5 09:39:58 2013 From: boris at codesynthesis.com (Boris Kolpackov) Date: Tue Mar 5 09:40:14 2013 Subject: [odb-users] Help, problem in mysql In-Reply-To: References: Message-ID: Hi, staywild writes: > Here I use the struct tm from in CI try to map this date type > to datetime in MySQL database, while encountered a gcc compiling failure. > > #pragma db type("datetime") null > struct tm finishedtime; You will need to provide a value_traits specialization for tm that maps it to/from the MySQL date-time representation (struct MYSQL_TIME). The following blog post has detailed instructions on how to do this (see the "Simple Value Types" section): http://www.codesynthesis.com/~boris/blog/2012/10/16/custom-cxx-to-database-type-mapping-in-odb/ Alternatively, you may want to consider using a higher level date-time representation, for example, the date-time library from Boost for which ODB provides built-in support (see Section 21.5, "Date Time Library" in the ODB manual). Boris From boris at codesynthesis.com Tue Mar 5 10:16:22 2013 From: boris at codesynthesis.com (Boris Kolpackov) Date: Tue Mar 5 10:16:37 2013 Subject: [odb-users] Encrypting the Sqlite DB In-Reply-To: References: Message-ID: Hi Lavi, Lavi Kwiatkowsky writes: > What is the best way to integrate an encryption mechanism ? While I don't have any direct experience, I did some Google searches and found these two pages that are quite informative: http://stackoverflow.com/questions/5669905/sqlite-with-encryption-password-protection http://stackoverflow.com/questions/8384789/encrypting-sqlite All of the approaches discussed work transparently at the SQLite level so they should work out of the box with ODB. Boris From Hugo.Mildenberger at web.de Tue Mar 5 10:22:40 2013 From: Hugo.Mildenberger at web.de (Hugo.Mildenberger@web.de) Date: Tue Mar 5 10:22:52 2013 Subject: [odb-users] odb-2.2.1 should install the odb.so plugin into $(gcc -print-file-name=plugin) In-Reply-To: References: <20130304110153.5b753c2f4d25cceb0a2c7dc8@zotac.lan> <20130305125335.1209f5a03b8817eddc87d5af@zotac.lan> Message-ID: <20130305162240.98a989c7b3c0870a49020c85@zotac.lan> Hi Boris, On Tue, 5 Mar 2013 16:13:51 +0200 Boris Kolpackov wrote: > In GCC 4.5 this is the path where the plugin headers are installed (in > the include/ subdirectory). The code to load plugins from this directory > is just not there in GCC 4.5 (see gcc/plugin.c). Which still does not prevent you from installing the plugin right there. ODB currently does not use GCC's internal knowledge concerning its own plugin path. So, if the first attempt fails for the reason of a non-existant plugin, one could issue a notice and run gcc without specifying the plugin path. The first attempt would always be the GCC plugin path of the GCC version ODB itself was compiled with. > Good point. If cross-compiling, we may not even be able to run host > GCC to detect any paths, including the plugin path (i.e., > -print-file-name=plugin). This complicates things significantly. > Perhaps we should keep it simple and just provide an option that > can be used to specify the alternative plugin installation directory. Yes, I see it now. > In fact, even with plugin headers, strictly speaking, things are broken > right now because we use build GCC (which may not even be built with > plugin support) instead of host GCC. If gcc was built without plugin support, does -print-file-name=plugin result in an error condition? If so, one could base a run-time test on it, finally covering all cases. Else it's a GCC bug. Hugo From newhite at rslfibersystems.com Tue Mar 5 14:38:20 2013 From: newhite at rslfibersystems.com (Nathan White) Date: Tue Mar 5 14:38:43 2013 Subject: [odb-users] Installing Odb Compiler Message-ID: Hello, I am trying to install the odb compiler so I can more easily interface with a SQLite3 database with C++. I can't seem to execute the odb file to create Person-odb.hxx Person-odb.ixx Person-odb.cxx Person.sql I used the install-unix.xhtml website to install everything. I had to manually download the archive and extract it into a file rather than using the command "sudo dpkg -i odb_x.y.z-n_.deb" I've spent two days trying to get this to work. Do you have any advice as to where I should be looking for my issue? Regards, Nathan From boris at codesynthesis.com Tue Mar 5 15:01:36 2013 From: boris at codesynthesis.com (Boris Kolpackov) Date: Tue Mar 5 15:01:43 2013 Subject: [odb-users] Installing Odb Compiler In-Reply-To: References: Message-ID: Hi Nathan, Nathan White writes: > I used the install-unix.xhtml website to install everything. I had to > manually download the archive and extract it into a file rather than > using the command "sudo dpkg -i odb_x.y.z-n_.deb" Why did you have to use an archive? Did installing via .deb file not work for some reason? It would also be helpful to know which OS you are using (is it even GNU/Linux)? Generally, if you are using Debian or Ubuntu, then you should use the .deb package. If you are using Fedora, RHEL, or CentOS, then you should use the .rpm package. For all other GNU/Linux distributions or other OS (e.g., Mac OS X, Solaris), use the .tar.bz2 archive. Specifically, after downloading the archive, you need to extract it into a directory of your choice. For example, to unpack it into /opt (on Solaris use gtar instead of tar): cd /opt sudo bzip -dc odb-x.y.z--.tar.bz2 | tar xf - Here x.y.z stands for the ODB version (currently 2.2.0), stands for the CPU architecture and stands for the OS you use. Once this is done, you should be able to run the ODB compiler like this: /opt/odb-x.y.z--/bin/odb -d sqlite person.hxx If one of the above steps doesn't work for you, please provide more information, such as the exact command line that you used and the error message that you get. Boris From newhite at rslfibersystems.com Tue Mar 5 15:13:12 2013 From: newhite at rslfibersystems.com (Nathan White) Date: Tue Mar 5 15:13:41 2013 Subject: [odb-users] Installing ODB Compiler In-Reply-To: References: Message-ID: Hello Boris I'm using Ubuntu 12.04LTS 32-Bit System. I'm making progress. Thank you for your assistance. I downloaded odb-2.2.0-i686-linux-gnu.tar.bz2. I extracted it to my opt folder. I ran /opt/odb-2.2.0-i686-linux-gnu/bin/odb -d sqlite person.hxx, but person.hxx was in read mode. Where does person.hxx need to be? Can it already be included in a C++ project? -----Original Message----- From: Boris Kolpackov [mailto:boris@codesynthesis.com] Sent: Tuesday, March 05, 2013 3:02 PM To: Nathan White Cc: odb-users@codesynthesis.com Subject: Re: [odb-users] Installing Odb Compiler Hi Nathan, Nathan White writes: > I used the install-unix.xhtml website to install everything. I had to > manually download the archive and extract it into a file rather than > using the command "sudo dpkg -i odb_x.y.z-n_.deb" Why did you have to use an archive? Did installing via .deb file not work for some reason? It would also be helpful to know which OS you are using (is it even GNU/Linux)? Generally, if you are using Debian or Ubuntu, then you should use the .deb package. If you are using Fedora, RHEL, or CentOS, then you should use the .rpm package. For all other GNU/Linux distributions or other OS (e.g., Mac OS X, Solaris), use the .tar.bz2 archive. Specifically, after downloading the archive, you need to extract it into a directory of your choice. For example, to unpack it into /opt (on Solaris use gtar instead of tar): cd /opt sudo bzip -dc odb-x.y.z--.tar.bz2 | tar xf - Here x.y.z stands for the ODB version (currently 2.2.0), stands for the CPU architecture and stands for the OS you use. Once this is done, you should be able to run the ODB compiler like this: /opt/odb-x.y.z--/bin/odb -d sqlite person.hxx If one of the above steps doesn't work for you, please provide more information, such as the exact command line that you used and the error message that you get. Boris From newhite at rslfibersystems.com Tue Mar 5 15:50:02 2013 From: newhite at rslfibersystems.com (Nathan White) Date: Tue Mar 5 15:50:28 2013 Subject: [odb-users] Installing Odb Compiler In-Reply-To: References: Message-ID: Here is the exact commands. I tried to different attempts newhite@newhite-GX-630:/opt$ sudo /opt/odb-2.2.0-i686-linux-gnu/bin/odb -d sqlite ~/workpace/Extralibraries/person.hxx /home/newhite/workpace/Extralibraries/person.hxx: error: unable to open in read mode newhite@newhite-GX-630:/opt$ newhite@newhite-GX-630:/opt$ sudo /opt/odb-2.2.0-i686-linux-gnu/bin/odb -d sqlite person.hxx person.hxx: error: unable to open in read mode newhite@newhite-GX-630:/opt$ Regards, Nathan -----Original Message----- From: Boris Kolpackov [mailto:boris@codesynthesis.com] Sent: Tuesday, March 05, 2013 3:02 PM To: Nathan White Cc: odb-users@codesynthesis.com Subject: Re: [odb-users] Installing Odb Compiler Hi Nathan, Nathan White writes: > I used the install-unix.xhtml website to install everything. I had to > manually download the archive and extract it into a file rather than > using the command "sudo dpkg -i odb_x.y.z-n_.deb" Why did you have to use an archive? Did installing via .deb file not work for some reason? It would also be helpful to know which OS you are using (is it even GNU/Linux)? Generally, if you are using Debian or Ubuntu, then you should use the .deb package. If you are using Fedora, RHEL, or CentOS, then you should use the .rpm package. For all other GNU/Linux distributions or other OS (e.g., Mac OS X, Solaris), use the .tar.bz2 archive. Specifically, after downloading the archive, you need to extract it into a directory of your choice. For example, to unpack it into /opt (on Solaris use gtar instead of tar): cd /opt sudo bzip -dc odb-x.y.z--.tar.bz2 | tar xf - Here x.y.z stands for the ODB version (currently 2.2.0), stands for the CPU architecture and stands for the OS you use. Once this is done, you should be able to run the ODB compiler like this: /opt/odb-x.y.z--/bin/odb -d sqlite person.hxx If one of the above steps doesn't work for you, please provide more information, such as the exact command line that you used and the error message that you get. Boris From Patrick.Rotsaert at intoit.be Wed Mar 6 02:55:28 2013 From: Patrick.Rotsaert at intoit.be (Patrick Rotsaert) Date: Wed Mar 6 02:55:39 2013 Subject: [odb-users] Loading persistent object using custom joins In-Reply-To: References: <6790257A-8DE9-44E0-BDDD-A0209E704F95@intoit.be> <5F9F49EA-815A-4641-82F2-D0919BBB2203@intoit.be> <52BB2B3A-F26B-4026-A94B-8845B106533B@intoit.be> Message-ID: <0255A6DF-11C9-4153-AB74-97A38C3A58BB@intoit.be> Hi Boris, On 5-mrt.-2013, at 14:48, Boris Kolpackov wrote: > Ok, I've added this feature to the TODO list. If I were to implement > it for the next release, will you be willing to start using it with > your application in a pre-release/beta? We prefer to implement new > features that someone is willing to test in the real world before > the final release. Sure. I have several cases to test it on. Pat From boris at codesynthesis.com Wed Mar 6 06:14:55 2013 From: boris at codesynthesis.com (Boris Kolpackov) Date: Wed Mar 6 06:15:04 2013 Subject: [odb-users] Installing ODB Compiler In-Reply-To: References: Message-ID: Hi Nathan, Nathan White writes: > I'm using Ubuntu 12.04LTS 32-Bit System. In this case you should be able to install directly from the package: sudo dpkg -i odb_2.2.0-1_i386.deb Have you tried this? If it didn't work, what was the error? The advantage of using the package instead of the archive is that the ODB compiler will be installed in the default location and you will be able to invoke it just as odb, for example: odb -d sqlite person.hxx > I ran /opt/odb-2.2.0-i686-linux-gnu/bin/odb -d sqlite person.hxx, but > person.hxx was in read mode. Where does person.hxx need to be? Can it > already be included in a C++ project? person.hxx is a C++ header from the hello example that used in the sample command lines. Normally, you would have your own header with your own persistent classes. If you want to use person.hxx (e.g., to test the ODB compiler), then you can find it in the hello/ subdirectory in the odb-examples package. > newhite@newhite-GX-630:/opt$ sudo /opt/odb-2.2.0-i686-linux-gnu/bin/odb ... You don't need to use sudo when invoking the ODB compiler. Boris From boris at codesynthesis.com Wed Mar 6 06:32:10 2013 From: boris at codesynthesis.com (Boris Kolpackov) Date: Wed Mar 6 06:32:18 2013 Subject: [odb-users] odb-2.2.1 should install the odb.so plugin into $(gcc -print-file-name=plugin) In-Reply-To: <20130305162240.98a989c7b3c0870a49020c85@zotac.lan> References: <20130304110153.5b753c2f4d25cceb0a2c7dc8@zotac.lan> <20130305125335.1209f5a03b8817eddc87d5af@zotac.lan> <20130305162240.98a989c7b3c0870a49020c85@zotac.lan> Message-ID: Hi Hugo, Hugo.Mildenberger@web.de writes: > Which still does not prevent you from installing the plugin right there. Yes, but GCC 4.5 won't be able to find it if ODB uses the short plugin name. The whole idea is to have a single /usr/bin/odb and multiple plugins, one for each GCC version. By using the short plugin name, /usr/bin/odb will cause GCC to load the correct plugin automatically. > ODB currently does not use GCC's internal knowledge concerning its own > plugin path. So, if the first attempt fails for the reason of a non-existant > plugin, one could issue a notice and run gcc without specifying the plugin > path. The first attempt would always be the GCC plugin path of the GCC > version ODB itself was compiled with. That's way too messy. It would also mean that in order to support GCC 4.5 one would need to install /usr/bin/odb that was built with GCC 4.5. Probably a better approach would be for /usr/bin/odb to first check if a GCC-specific version of the plugin was installed (i.e., run GCC with -print-file-name=plugin and stat() odb.so in that directory). If one exists, then pass that using absolute plugin path (so that it works with GCC 4.5). > If gcc was built without plugin support, does -print-file-name=plugin > result in an error condition? If so, one could base a run-time test > on it, finally covering all cases. Else it's a GCC bug. The point I am trying to make is that it is the host GCC (as opposed to target GCC) that needs to be built with plugin support. And we can't do any runtime checks with host GCC since we cannot run it. Boris From Hugo.Mildenberger at web.de Wed Mar 6 08:45:48 2013 From: Hugo.Mildenberger at web.de (Hugo.Mildenberger@web.de) Date: Wed Mar 6 08:45:58 2013 Subject: [odb-users] odb-2.2.1 should install the odb.so plugin into $(gcc -print-file-name=plugin) In-Reply-To: References: <20130304110153.5b753c2f4d25cceb0a2c7dc8@zotac.lan> <20130305125335.1209f5a03b8817eddc87d5af@zotac.lan> <20130305162240.98a989c7b3c0870a49020c85@zotac.lan> Message-ID: <20130306144548.42df5815309d3f982312c61c@zotac.lan> Hi Boris, On Wed, 6 Mar 2013 13:32:10 +0200 Boris Kolpackov wrote: > Probably a better approach would be for /usr/bin/odb to first check if > a GCC-specific version of the plugin was installed (i.e., run GCC with > -print-file-name=plugin and stat() odb.so in that directory). If one > exists, then pass that using absolute plugin path (so that it works > with GCC 4.5). Yes, this would be a clean solution! > > If gcc was built without plugin support, does -print-file-name=plugin > > result in an error condition? If so, one could base a run-time test > > on it, finally covering all cases. Else it's a GCC bug. > > The point I am trying to make is that it is the host GCC (as opposed > to target GCC) that needs to be built with plugin support. And we can't > do any runtime checks with host GCC since we cannot run it. And I was trying to say that one has to defer this test until ODB runs on the designated target machine ("run-time test"). The strategy you described above would cover this idea implicitly. Hugo From newhite at rslfibersystems.com Wed Mar 6 08:53:02 2013 From: newhite at rslfibersystems.com (Nathan White) Date: Wed Mar 6 08:53:25 2013 Subject: [odb-users] Installing ODB Compiler In-Reply-To: References: Message-ID: Hello Boris, I extracted the files into /opt/odb-2.2.0-i686. And I was able to verity odb worked correctly. I solved the initial problem of not being able to create peron-odb files. My issue with creating the person-odb files stemmed from me not being in the exact folder where person.hxx is stored. It was the last configuration I tried. Thank you for helping me through this issue. As I am a new Ubuntu, odb, and SQLite user there are many unknowns for me so I often have a lot of questions. Regards, Nathan -----Original Message----- From: Boris Kolpackov [mailto:boris@codesynthesis.com] Sent: Wednesday, March 06, 2013 6:15 AM To: Nathan White Cc: odb-users@codesynthesis.com Subject: Re: [odb-users] Installing ODB Compiler Hi Nathan, Nathan White writes: > I'm using Ubuntu 12.04LTS 32-Bit System. In this case you should be able to install directly from the package: sudo dpkg -i odb_2.2.0-1_i386.deb Have you tried this? If it didn't work, what was the error? The advantage of using the package instead of the archive is that the ODB compiler will be installed in the default location and you will be able to invoke it just as odb, for example: odb -d sqlite person.hxx > I ran /opt/odb-2.2.0-i686-linux-gnu/bin/odb -d sqlite person.hxx, but > person.hxx was in read mode. Where does person.hxx need to be? Can it > already be included in a C++ project? person.hxx is a C++ header from the hello example that used in the sample command lines. Normally, you would have your own header with your own persistent classes. If you want to use person.hxx (e.g., to test the ODB compiler), then you can find it in the hello/ subdirectory in the odb-examples package. > newhite@newhite-GX-630:/opt$ sudo /opt/odb-2.2.0-i686-linux-gnu/bin/odb ... You don't need to use sudo when invoking the ODB compiler. Boris From newhite at rslfibersystems.com Wed Mar 6 10:03:52 2013 From: newhite at rslfibersystems.com (Nathan White) Date: Wed Mar 6 10:04:14 2013 Subject: [odb-users] Installing ODB Compiler References: Message-ID: Boris I'm receiving this error "Error unknown database; did you forget to define the DATABASE_* macros?" What is DATABASE_* macros? I guessed at what the error is and changed #ifndef DATABASE_HXX #define DATABASE_HXX To #ifndef odbtest #define odbtest Regards, Nathan ------------------------------- I solved the initial problem of not being able to create peron-odb files. My issue with creating the person-odb files stemmed from me not being in the exact folder where person.hxx is stored. It was the last configuration I tried. Thank you for helping me through this issue. As I am a new Ubuntu, odb, and SQLite user there are many unknowns for me so I often have a lot of questions. Regards, Nathan -----Original Message----- From: Boris Kolpackov [mailto:boris@codesynthesis.com] Sent: Wednesday, March 06, 2013 6:15 AM To: Nathan White Cc: odb-users@codesynthesis.com Subject: Re: [odb-users] Installing ODB Compiler Hi Nathan, Nathan White writes: > I'm using Ubuntu 12.04LTS 32-Bit System. In this case you should be able to install directly from the package: sudo dpkg -i odb_2.2.0-1_i386.deb Have you tried this? If it didn't work, what was the error? The advantage of using the package instead of the archive is that the ODB compiler will be installed in the default location and you will be able to invoke it just as odb, for example: odb -d sqlite person.hxx > I ran /opt/odb-2.2.0-i686-linux-gnu/bin/odb -d sqlite person.hxx, but > person.hxx was in read mode. Where does person.hxx need to be? Can it > already be included in a C++ project? person.hxx is a C++ header from the hello example that used in the sample command lines. Normally, you would have your own header with your own persistent classes. If you want to use person.hxx (e.g., to test the ODB compiler), then you can find it in the hello/ subdirectory in the odb-examples package. > newhite@newhite-GX-630:/opt$ sudo /opt/odb-2.2.0-i686-linux-gnu/bin/odb ... You don't need to use sudo when invoking the ODB compiler. Boris From boris at codesynthesis.com Wed Mar 6 10:26:19 2013 From: boris at codesynthesis.com (Boris Kolpackov) Date: Wed Mar 6 10:26:28 2013 Subject: [odb-users] Installing ODB Compiler In-Reply-To: References: Message-ID: Hi Nathan, Nathan White writes: > I'm receiving this error "Error unknown database; did you forget to > define the DATABASE_* macros?" > > What is DATABASE_* macros? Please read the README file that comes with the hello example. It shows how to build the example manually and how to select the database with the DATABASE_* macro. In your case, you would want to replace -DDATABASE_MYSQL with -DDATABASE_SQLITE. Boris From newhite at rslfibersystems.com Wed Mar 6 12:48:07 2013 From: newhite at rslfibersystems.com (Nathan White) Date: Wed Mar 6 12:48:32 2013 Subject: [odb-users] Installing ODB Compiler In-Reply-To: References: Message-ID: Thank you Boris, I will manually build the database. I thought the example code build the database automatically. Regards, Nathan -----Original Message----- From: Boris Kolpackov [mailto:boris@codesynthesis.com] Sent: Wednesday, March 06, 2013 10:26 AM To: Nathan White Cc: odb-users@codesynthesis.com Subject: Re: [odb-users] Installing ODB Compiler Hi Nathan, Nathan White writes: > I'm receiving this error "Error unknown database; did you forget to > define the DATABASE_* macros?" > > What is DATABASE_* macros? Please read the README file that comes with the hello example. It shows how to build the example manually and how to select the database with the DATABASE_* macro. In your case, you would want to replace -DDATABASE_MYSQL with -DDATABASE_SQLITE. Boris From newhite at rslfibersystems.com Thu Mar 7 09:56:15 2013 From: newhite at rslfibersystems.com (Nathan White) Date: Thu Mar 7 09:56:35 2013 Subject: [odb-users] Installing ODB Compiler In-Reply-To: References: Message-ID: Boris, I attempted to re-install the compiler using the terminal command. With the commands you provided below and I received this error: /opt$ sudo dpkg -i odb_2.2.0-1_i386.deb dpkg: error processing odb_2.2.0-1_i386.deb (--install): cannot access archive: No such file or directory Errors were encountered while processing: odb_2.2.0-1_i386.deb I tried odb-2.2.0-i686-linux-gnu.tar.bz2 and received the same error. Nathan -----Original Message----- From: Boris Kolpackov [mailto:boris@codesynthesis.com] Sent: Wednesday, March 06, 2013 6:15 AM To: Nathan White Cc: odb-users@codesynthesis.com Subject: Re: [odb-users] Installing ODB Compiler Hi Nathan, Nathan White writes: > I'm using Ubuntu 12.04LTS 32-Bit System. In this case you should be able to install directly from the package: sudo dpkg -i odb_2.2.0-1_i386.deb Have you tried this? If it didn't work, what was the error? The advantage of using the package instead of the archive is that the ODB compiler will be installed in the default location and you will be able to invoke it just as odb, for example: odb -d sqlite person.hxx > I ran /opt/odb-2.2.0-i686-linux-gnu/bin/odb -d sqlite person.hxx, but > person.hxx was in read mode. Where does person.hxx need to be? Can it > already be included in a C++ project? person.hxx is a C++ header from the hello example that used in the sample command lines. Normally, you would have your own header with your own persistent classes. If you want to use person.hxx (e.g., to test the ODB compiler), then you can find it in the hello/ subdirectory in the odb-examples package. > newhite@newhite-GX-630:/opt$ sudo /opt/odb-2.2.0-i686-linux-gnu/bin/odb ... You don't need to use sudo when invoking the ODB compiler. Boris From lavik at codevalue.net Thu Mar 7 06:59:26 2013 From: lavik at codevalue.net (Lavi Kwiatkowsky) Date: Thu Mar 7 10:43:06 2013 Subject: [odb-users] Encrypting the Sqlite DB In-Reply-To: References: Message-ID: Hi, First of all, Boris - thanks for the prompt reply. Here are my conclusions from researching this subject. When discussing encryption, we have two basic options: 1. Application level Encryption: use any existing library and encrypt the information prior to being sent to the DB. Good: ? This option offers a lot of control over the information. ? Existing OpenSSL Library can be reused. Bad: ? A lot of programming would have to take place in order to support this throughout the DAL, entities, repositories etc. ? We won?t be able to query or sort the DB where there are encrypted columns. ? Bad performance for encrypting strings one at a time as opposed to encrypting the whole DB and decrypting it as we read pages. ? Finally, if any information is left unencrypted ? will be used by potential hackers to decrypt the rest. This is how you get your neighbors WIFI (even if its WPA2 PSK with 128bit AES). Possible solutions: ? http://www.openssl.org/ ? http://www.cryptopp.com/ ? http://libtom.org/?page=features ? free, lightweight library. 2. Infrastructure level Encryption: use a mechanism which wraps the sqlite3 db and provides the encryption automatically and on a File\Table space\column level. Good: ? Easiest solution to implement, just add a library and pass the encryption key. ? All DB information is encrypted, no flaws. ? Great performance - Since we encrypt whole blocks of data, the process is more efficient, especially with AES. A small overhead of 5-15% compared to unencrypted sqlite. ? Queries can be performed as usual. Bad: ? Most solutions cost money between 100 and 2000$. ? We need to make sure this plays along well with the ODB Framework. Possible solutions: ? http://www.hwaci.com/sw/sqlite/see.html? ? The official SQLITE3 developer?s solution. It?s the best solution but also expensive at 2000$ for our commercial needs. It can be seamlessly integrated along with ODB and no special handling is needed, I will describe later on how. ? http://sqlcipher.net/documentation/ - Has a community edition for free: https://github.com/sqlcipher/sqlcipher Has good reputation and recommendations. Uses pragma language to pass the key (more on this later). Based on OpenSSL. Since they encrypt the whole DB, they have weird workarounds such as changing the page size to add information. ? http://sqlite-crypt.com/index.htm - Offers 256 AES but not too many features, they offer a free windows trial edition (key kept as cleartext in this edition). ? https://github.com/OlivierJG/botansqlite3#readme Open source library based on Botan encryption lib, requires a lot of messing around to get it to work in my opinion. To work with the first option, we all know what to do ? introduce an encryption class, and wrap entities with encryption entities. To work with the second option was tricky to integrate with ODB but I made it happen: 1. All you have to do is go to the RepositoryFactory.cpp, in the method createDB where we hold the DB object, we can get the sqlite3 handle. >From ODB Documentation: The begin_immediate() and begin_exclusive() functions allow us to start an immediate and an exclusive SQLite transaction on the connection, respectively. Their semantics are equivalent to the corresponding functions defined in thesqlite::database class (Section 16.2, "SQLite Database Class"). The handle()accessor returns the SQLite handle corresponding to the connection. What to do in the code: o Change shared_ptr to shared_ptr o Once it?s an sqlite3, we can perform db->connection()->handle() which retrieves the actual pointer. 2. Using this handle we can use SEE (official sqlite solution) method to pass the encryption key, or run pragma commands for the DB which are just like insert or update, but have been added to handle encryption. ? Example for pragma command: If (sqlite3_prepare_v2(db, "PRAGMA user_version;", -1, &stmt_version, NULL) == SQLITE_OK) { while(sqlite3_step(stmt_version) == SQLITE_ROW) { databaseVersion = sqlite3_column_int(stmt_version, 0); For SEE we also have a method: int sqlite3_key( sqlite3 *db, /* The connection from sqlite3_open() */ const void *pKey, /* The key */ int nKey /* Number of bytes in the key */ ); int sqlite3_rekey( sqlite *db, /* Database to be rekeyed */ const void *pKey, int nKey /* The new key */ ); Best Regards, Lavi -----Original Message----- From: Boris Kolpackov [mailto:boris@codesynthesis.com] Sent: Tuesday, March 5, 2013 5:16 PM To: Lavi Kwiatkowsky Cc: odb-users@codesynthesis.com Subject: Re: [odb-users] Encrypting the Sqlite DB Hi Lavi, Lavi Kwiatkowsky writes: > What is the best way to integrate an encryption mechanism ? While I don't have any direct experience, I did some Google searches and found these two pages that are quite informative: http://stackoverflow.com/questions/5669905/sqlite-with-encryption-password-protection http://stackoverflow.com/questions/8384789/encrypting-sqlite All of the approaches discussed work transparently at the SQLite level so they should work out of the box with ODB. Boris From boris at codesynthesis.com Thu Mar 7 10:55:32 2013 From: boris at codesynthesis.com (Boris Kolpackov) Date: Thu Mar 7 10:55:40 2013 Subject: [odb-users] Encrypting the Sqlite DB In-Reply-To: References: Message-ID: Hi Lavi, Lavi Kwiatkowsky writes: > https://github.com/OlivierJG/botansqlite3#readme Open source library > based on Botan encryption lib, requires a lot of messing around to get > it to work in my opinion. I did a bit of digging around and this seemed like the most promising option to me. If not directly then at least as a base. It appears that the SQLite folks have all the hooks necessary to implement encryption in the vanilla SQLite, they are just disabled (see the SQLITE_HAS_CODEC macro). So what botansqlite3 does is essentially implement these hooks (just like the official "SEE") and using the Botan encryption library to do the actual work. So if I were to implement SQLite encryption, I would probably use the same approach but maybe using OpenSSL or some standalone implementation for encryption. > To work with the second option was tricky to integrate with ODB but > I made it happen: > > [...] I think a better approach would be to do it via the connection factory, transparently to the client code. This earlier post explains the idea (it talks about MySQL but exactly the same principle applies to all the other databases, including SQLite): http://www.codesynthesis.com/pipermail/odb-users/2012-January/000425.html Boris From boris at codesynthesis.com Thu Mar 7 10:59:51 2013 From: boris at codesynthesis.com (Boris Kolpackov) Date: Thu Mar 7 10:59:58 2013 Subject: [odb-users] Installing ODB Compiler In-Reply-To: References: Message-ID: Hi Nathan, Nathan White writes: > I attempted to re-install the compiler using the terminal command. With > the commands you provided below and I received this error: > /opt$ sudo dpkg -i odb_2.2.0-1_i386.deb > dpkg: error processing odb_2.2.0-1_i386.deb (--install): > cannot access archive: No such file or directory Did you actually download the file? I think you were correct in saying that you are very new to Ubuntu (and I assume to Linux/UNIX in general). The issues that you are having are very basic; we don't even cover them in the documentation since they are expected to be "obvious". My suggestion is that you find someone in your organization who has more experience with Ubuntu and who can help you through this. Boris From newhite at rslfibersystems.com Thu Mar 7 11:03:18 2013 From: newhite at rslfibersystems.com (Nathan White) Date: Thu Mar 7 11:03:41 2013 Subject: [odb-users] Installing ODB Compiler In-Reply-To: References: Message-ID: I have all the zipped files downloaded in my Downloads folder. -----Original Message----- From: Boris Kolpackov [mailto:boris@codesynthesis.com] Sent: Thursday, March 07, 2013 11:00 AM To: Nathan White Cc: odb-users@codesynthesis.com Subject: Re: [odb-users] Installing ODB Compiler Hi Nathan, Nathan White writes: > I attempted to re-install the compiler using the terminal command. > With the commands you provided below and I received this error: > /opt$ sudo dpkg -i odb_2.2.0-1_i386.deb > dpkg: error processing odb_2.2.0-1_i386.deb (--install): > cannot access archive: No such file or directory Did you actually download the file? I think you were correct in saying that you are very new to Ubuntu (and I assume to Linux/UNIX in general). The issues that you are having are very basic; we don't even cover them in the documentation since they are expected to be "obvious". My suggestion is that you find someone in your organization who has more experience with Ubuntu and who can help you through this. Boris From pstath at axxcelera.com Thu Mar 7 12:41:43 2013 From: pstath at axxcelera.com (Stath Paul) Date: Thu Mar 7 12:41:51 2013 Subject: [odb-users] Add --sysroot support to ODB compiler In-Reply-To: <201303071700.r27H03ng018262@codesynthesis.com> References: <201303071700.r27H03ng018262@codesynthesis.com> Message-ID: <3233D27CC5658E4598557F8521F6B07E217B2C65B7@RIC-MS01.abw.int> Boris-- I'm attempting to build my application in an a cross-compilation environment. (Yocto / Open-Embedded) When I invoke the ODB compiler in my cross-compile scenario, I get the error :4:4 error: #error incompatible ODB compiler and runtiume versions The command being run by make is: /home/pstath/yocto/poky/build/tmp/sysroots/i686-linux/usr/bin/odb --database sqlite --std c++11 --profile boost --generate-schema --schema-format sql -I.. -I../crypto/inc --hxx-suffix .hpp --ixx-suffix .ipp --cxx-suffix .cpp --generate-query --generate-session --show-sloc --sloc-limit 10000 row_status.hpp This occurs because the ODB command does call out the default '-I/usr/include' which is where version.hxx (from a different libodb) is being found. If I add '-I/home/pstath/yocto/poky/build/tmp/sysroots/i686-linux/usr/include' to prepend the '/usr/include' directory for my cross-compile environment, the correct version of '' is found and used. /home/pstath/yocto/poky/build/tmp/sysroots/i686-linux/usr/bin/odb --database sqlite --std c++11 --profile boost --generate-schema --schema-format sql -I/home/pstath/yocto/poky/build/tmp/sysroots/i686-linux/usr/include -I.. -I../crypto/inc --hxx-suffix .hpp --ixx-suffix .ipp --cxx-suffix .cpp --generate-query --generate-session --show-sloc --sloc-limit 10000 row_status.hpp While the above works, I believe it would be more elegant to have the ODB command accept the '--sysroot=' argument with the same logic that GCC applies to --sysroot. It would also be convenient if the '-I' argument would allow for a leading '=' character at the beginning of to replace the sysroot prefix. (per. The GCC man page.) Please let me know your thoughts, or if you have a better work-around than using the "-I/usr/include" argument. -- Paul From boris at codesynthesis.com Thu Mar 7 14:03:48 2013 From: boris at codesynthesis.com (Boris Kolpackov) Date: Thu Mar 7 14:03:57 2013 Subject: [odb-users] Add --sysroot support to ODB compiler In-Reply-To: <3233D27CC5658E4598557F8521F6B07E217B2C65B7@RIC-MS01.abw.int> References: <201303071700.r27H03ng018262@codesynthesis.com> <3233D27CC5658E4598557F8521F6B07E217B2C65B7@RIC-MS01.abw.int> Message-ID: Hi Paul, Stath Paul writes: > This occurs because the ODB command does call out the default > '-I/usr/include' which is where version.hxx (from a different libodb) > is being found. The ODB compiler doesn't add this directory so it must have come from GCC, which could mean GCC wasn't configured properly (i.e., the --with-sysroot option wasn't specified). > While the above works, I believe it would be more elegant to have the > ODB command accept the '--sysroot=' argument with the same logic > that GCC applies to --sysroot. You can instruct the ODB compiler to pass any option to GCC by prefixing it with -x: odb -x --sysroot=/path ... > It would also be convenient if the '-I' argument would allow for > a leading '=' character at the beginning of to replace the sysroot > prefix. (per. The GCC man page.) I believe that would work as well since ODB doesn't use the -I values itself, it just passes them as is to GCC. Also it would be a pain to specify --sysroot in every invocation so another thing that you may find useful is support for the default options file (see the --options-file option documentation for the format). When configuring ODB, you can use the --with-options-file option to specify the path to the default options file which the ODB compiler will read automatically. This path can be absolute (e.g., /etc/odb/default.options) or relative (e.g., ../etc/odb/default.options). If it is relative, then it is resolved based on the ODB compiler executable directory (e.g., /usr/bin). If you build ODB with support for the default options file, then it would seem natural to place the --sysroot option there. Boris From Hugo.Mildenberger at web.de Fri Mar 8 04:29:07 2013 From: Hugo.Mildenberger at web.de (Hugo.Mildenberger@web.de) Date: Fri Mar 8 04:29:18 2013 Subject: [odb-users] schemas and run-time search path Message-ID: <20130308102907.81def9b214a87e60026a88cd@zotac.lan> Boris, is it possible to assign a schema name to be used by an object instance at run time? I'm thinking about to map individual users to schemas, hence the question. On a second thought, it is probably cleaner to use "set search_path to ''" (on PostgreSQL), but I miss such an option within the database or connection classes. Hugo From benjamin.schudel at nexirius.com Fri Mar 8 04:04:17 2013 From: benjamin.schudel at nexirius.com (Benjamin Schudel) Date: Fri Mar 8 05:09:06 2013 Subject: [odb-users] ODB compiler - Problem with multiple input files (*.h) Message-ID: <16362b3d751632e29f1f0bc22d696a60@mail.gmail.com> Hello, I have a question: How can I specify multiple input files for the ODB-compiler (version 2.2.0)? With the compiler version 2.1.1 it was possible to specify multiple input files like this: ?*.h?. If I try it with the compiler 2.2.0, I get the following exception: ?*.h: error: unable to open in read mode?. The exact command I am trying: odb -d sqlite --generate-query --generate-schema *.h (exact compiler version: odb-2.2.0-i686-windows) Best regards, Benjamin Schudel From boris at codesynthesis.com Fri Mar 8 06:14:49 2013 From: boris at codesynthesis.com (Boris Kolpackov) Date: Fri Mar 8 06:14:57 2013 Subject: [odb-users] schemas and run-time search path In-Reply-To: <20130308102907.81def9b214a87e60026a88cd@zotac.lan> References: <20130308102907.81def9b214a87e60026a88cd@zotac.lan> Message-ID: Hi Hugo, Hugo.Mildenberger@web.de writes: > is it possible to assign a schema name to be used by an object instance > at run time? No, this is not supported. For reasons why, see this earlier post (scroll down to #3): http://www.codesynthesis.com/pipermail/odb-users/2011-October/000368.html > I'm thinking about to map individual users to schemas, hence the question. > On a second thought, it is probably cleaner to use "set search_path to > ''" (on PostgreSQL), Yes, I think this will work. > but I miss such an option within the database or connection classes. The way to do it is to override the create() virtual function on the connection factory class. There you can either call the original implementation and then configure the connection as needed (e.g., by executing some statements) or you can create a completely custom PostgreSQL connection and pass the handle to the connection's class constructor. See this post for details: http://www.codesynthesis.com/pipermail/odb-users/2012-January/000425.html Boris From boris at codesynthesis.com Fri Mar 8 06:51:48 2013 From: boris at codesynthesis.com (Boris Kolpackov) Date: Fri Mar 8 06:51:56 2013 Subject: [odb-users] ODB compiler - Problem with multiple input files (*.h) In-Reply-To: <16362b3d751632e29f1f0bc22d696a60@mail.gmail.com> References: <16362b3d751632e29f1f0bc22d696a60@mail.gmail.com> Message-ID: Hi Benjamin, Benjamin Schudel writes: > With the compiler version 2.1.1 it was possible to specify multiple input > files like this: ?*.h?. Yes, I could confirm this regression. In 2.2.0 we switched to mingw-w64 which apparently has shell globbing disabled by default. I've enabled it and re-built the ODB compiler, which now works as expected for me. Can you try the new package and let me know if it works for you: http://www.codesynthesis.com/~boris/tmp/odb/odb-2.2.1-i686-windows.zip Once you confirm that the issue is fixed, I will make the bugfix official. And thanks for reporting this! Boris From benjamin.schudel at nexirius.com Fri Mar 8 07:02:20 2013 From: benjamin.schudel at nexirius.com (Benjamin Schudel) Date: Fri Mar 8 07:04:48 2013 Subject: AW: [odb-users] ODB compiler - Problem with multiple input files (*.h) In-Reply-To: References: <16362b3d751632e29f1f0bc22d696a60@mail.gmail.com> Message-ID: Hi Boris, thanks for the fast answer. With the new compiler (odb-2.2.1-i686-windows) it works! Many thanks. Regards Benjamin -----Urspr?ngliche Nachricht----- Von: Boris Kolpackov [mailto:boris@codesynthesis.com] Gesendet: Freitag, 8. M?rz 2013 12:52 An: Benjamin Schudel Cc: odb-users@codesynthesis.com Betreff: Re: [odb-users] ODB compiler - Problem with multiple input files (*.h) Hi Benjamin, Benjamin Schudel writes: > With the compiler version 2.1.1 it was possible to specify multiple > input files like this: ?*.h?. Yes, I could confirm this regression. In 2.2.0 we switched to mingw-w64 which apparently has shell globbing disabled by default. I've enabled it and re-built the ODB compiler, which now works as expected for me. Can you try the new package and let me know if it works for you: http://www.codesynthesis.com/~boris/tmp/odb/odb-2.2.1-i686-windows.zip Once you confirm that the issue is fixed, I will make the bugfix official. And thanks for reporting this! Boris From pstath at axxcelera.com Fri Mar 8 14:11:21 2013 From: pstath at axxcelera.com (Stath Paul) Date: Fri Mar 8 14:11:30 2013 Subject: [odb-users] Add --sysroot support to ODB compiler In-Reply-To: References: <201303071700.r27H03ng018262@codesynthesis.com> <3233D27CC5658E4598557F8521F6B07E217B2C65B7@RIC-MS01.abw.int> Message-ID: <3233D27CC5658E4598557F8521F6B07E217B2C664B@RIC-MS01.abw.int> Boris -- > You can instruct the ODB compiler to pass any option to GCC by > prefixing > it with -x: > > odb -x --sysroot=/path ... I had missed the -x option on my initial read-through of the command line arguments for ODB. However, I'm now running into a different error. I'm getting: # error ODB and C++ compilers see different libodb-boost interface versions Adding back the "-I /usr/include" argument again allowed the ODB command to generate The database access classes. Looking onto the odb.cxx code, it appears that in the profile_paths() method, you determine the default search libraries by running the C preprocessor with the -v option. Then scan the output to obtain the search directories. ( Essentially: c++ -v -E -P - < /dev/null" | sed -n '/^#include <\.\.\.>/,/^End of search list/p' ) When invoking this command, you pass though any "-I" arguments, as well as "-isystem", "-iquote", "-idirafter" or "-framework". I believe that passing through the "--sysroot" argument is also required, since "--sysroot" effects the default search path. I'm also unsure if the compiler is always "c++", or might be modified by "-x /path/to/gcc/non-installed-g++". There seems to be some fragility with parsing the "c++ -v -E -P - < /dev/null" output. (NLS, possible change or message by GCC, etc.) Since you already have a plug-in, would it be possible to have it obtain the gcc search path from GCC and output it in a fixed, easy to parse format that is under your control? Something like: $ g++ -E P - -fplugin= -fplugin-arg-odb-print=searchpath ./include /usr/lib/gcc/i686-linux-gnu/4.6/include /usr/lib/gcc/i686-linux-gnu/4.6/include-fixed /usr/include -- Paul From boris at codesynthesis.com Fri Mar 8 15:02:26 2013 From: boris at codesynthesis.com (Boris Kolpackov) Date: Fri Mar 8 15:02:35 2013 Subject: [odb-users] Add --sysroot support to ODB compiler In-Reply-To: <3233D27CC5658E4598557F8521F6B07E217B2C664B@RIC-MS01.abw.int> References: <201303071700.r27H03ng018262@codesynthesis.com> <3233D27CC5658E4598557F8521F6B07E217B2C65B7@RIC-MS01.abw.int> <3233D27CC5658E4598557F8521F6B07E217B2C664B@RIC-MS01.abw.int> Message-ID: Hi Paul, Stath Paul writes: > I believe that passing through the "--sysroot" argument is also required, > since "--sysroot" effects the default search path. Yes, you are correct. Here is the patch: http://scm.codesynthesis.com/?p=odb/odb.git;a=patch;h=113a5dd44ebef3b358fe09015b03576cff583043 I tried it on my setup and it does the trick. Can you verify it also works for you? > I'm also unsure if the compiler is always "c++", or might be modified > by "-x /path/to/gcc/non-installed-g++". The "c++" you are seeing is the compilation mode (-x c++), not the compiler executable. The actual compiler is the same as what's used for normal compilation, and, yes, it can be overridden with -x. > There seems to be some fragility with parsing the "c++ -v -E -P - < > /dev/null" output. (NLS, possible change or message by GCC, etc.) The code actually tries to avoid relying on any natural language text (which can be translated). Are you seeing any specific issues? > Since you already have a plug-in, would it be possible to have it > obtain the gcc search path from GCC and output it in a fixed, easy > to parse format that is under your control? While doable that would be quite awkward. The plugin doesn't just get control of the compilation process. Rather, it can register to be called at certain points in the compilation process. For example, if all we are doing is preprocessing, then the plugin is not even get called. So we would actually have to compile something real in order to give the plugin a chance to run. And I would prefer not to go this way unless there is a really good reason to. Boris From boris at codesynthesis.com Mon Mar 11 08:06:44 2013 From: boris at codesynthesis.com (Boris Kolpackov) Date: Mon Mar 11 08:06:51 2013 Subject: [odb-users] odb-2.2.1 should install the odb.so plugin into $(gcc -print-file-name=plugin) In-Reply-To: <20130306144548.42df5815309d3f982312c61c@zotac.lan> References: <20130304110153.5b753c2f4d25cceb0a2c7dc8@zotac.lan> <20130305125335.1209f5a03b8817eddc87d5af@zotac.lan> <20130305162240.98a989c7b3c0870a49020c85@zotac.lan> <20130306144548.42df5815309d3f982312c61c@zotac.lan> Message-ID: Hi Hugo, Hugo.Mildenberger@web.de writes: > And I was trying to say that one has to defer this test until ODB runs > on the designated target machine ("run-time test"). But we need the plugin include directory during build time. Anyway, here is the plan that I think will address all the issues: 1. Add --{with,without}-gcc-plugin-dir option to ODB configure. This option can be used as follows: a) --with-gcc-plugin-dir: force installing into GCC's plugin dir with is obtainer by running $CXX -print-file-name=plugin b) --without-gcc-plugin-dir: force installing into $libexecdir/odb/ even if test #2.b below succeeds. c) --with-gcc-plugin-dir=/path/to/gcc/plugin/dir: install plugin into the specified directory. This method will have to be used for cross-compilation. 2. If we are not cross-compiling, then: b) If $libexecdir is a prefix of `$CXX -print-file-name=plugin`, then install into the gcc plugin dir. One can use --without-gcc-plugin-dir to override this. c) Use `$CXX -print-file-name=plugin`/include as the plugin include directory. 3. If we are cross-compiling then the user will have to specify the plugin include directory via the CPPFLAGS configure variable. 4. If the plugin is installed into the GCC plugin dir, then the ODB compiler driver will obtain the GCC's plugin dir at runtime, append the plugin name (odb.so) and pass this absolute path to -fplugin. This way things will work consistently with GCC 4.5 (which doesn't support short plugin name) and later. Do you see any problems with this plan? Boris From pstath at axxcelera.com Mon Mar 11 08:26:11 2013 From: pstath at axxcelera.com (Stath Paul) Date: Mon Mar 11 08:26:27 2013 Subject: [odb-users] Add --sysroot support to ODB compiler In-Reply-To: References: <201303071700.r27H03ng018262@codesynthesis.com> <3233D27CC5658E4598557F8521F6B07E217B2C65B7@RIC-MS01.abw.int> <3233D27CC5658E4598557F8521F6B07E217B2C664B@RIC-MS01.abw.int> Message-ID: <3233D27CC5658E4598557F8521F6B07E217B2C66AB@RIC-MS01.abw.int> Boris -- > > I believe that passing through the "--sysroot" argument is also > required, > > since "--sysroot" effects the default search path. > > Yes, you are correct. Here is the patch: > > http://scm.codesynthesis.com/?p=odb/odb.git;a=patch;h=113a5dd44ebef3b35 > 8fe09015b03576cff583043 > > I tried it on my setup and it does the trick. Can you verify it also > works for you? > The patch work great. Thanks so much. Now just specifying "-x --sysroot" does as I would expect, and I don't need to add the "-I/usr/include" argument. > > I'm also unsure if the compiler is always "c++", or might be modified > > by "-x /path/to/gcc/non-installed-g++". > > The "c++" you are seeing is the compilation mode (-x c++), not the > compiler executable. The actual compiler is the same as what's used > for normal compilation, and, yes, it can be overridden with -x. > Ah. Got it. > > There seems to be some fragility with parsing the "c++ -v -E -P - < > > /dev/null" output. (NLS, possible change or message by GCC, etc.) > > The code actually tries to avoid relying on any natural language > text (which can be translated). Are you seeing any specific issues? > I am not. Just noticed the comments in profile_paths() method. I'm always wary about parsing text which is not "machine readable". (XML, JSON, et. al.) I was not aware that the odb.so plugin was not even getting loaded during preprocessing. Given the lack of options for getting information out of the CPP (other than -v) I guess that parsing the -v output it the best of the rather limited options. ;) -- Paul From boris at codesynthesis.com Mon Mar 11 08:39:29 2013 From: boris at codesynthesis.com (Boris Kolpackov) Date: Mon Mar 11 08:39:36 2013 Subject: [odb-users] ODB compiler Windows binary 2.2.1 bugfix released Message-ID: Hi, A new bugfix release for the ODB compiler Windows binary is now available. It fixes an issue with shell globbing (that is, the expansion of * and ? in file names) when invoked from the Windows command prompt. You only need to upgrade if you are using shell wildcards to specify input files to the ODB compiler. For more information on this issue, refer to the following mailing list thread: http://www.codesynthesis.com/pipermail/odb-users/2013-March/001147.html You can download the new package from the ODB download page: http://www.codesynthesis.com/products/odb/download.xhtml The SHA1 checksum for the file in this release is as follows: e9badc36fa553d3e5291d218d4e90c064c46c36a odb-2.2.1-i686-windows.zip Boris From Hugo.Mildenberger at web.de Tue Mar 12 12:46:30 2013 From: Hugo.Mildenberger at web.de (Hugo.Mildenberger@web.de) Date: Tue Mar 12 12:46:39 2013 Subject: [odb-users] odb-2.2.1 should install the odb.so plugin into $(gcc -print-file-name=plugin) In-Reply-To: References: <20130304110153.5b753c2f4d25cceb0a2c7dc8@zotac.lan> <20130305125335.1209f5a03b8817eddc87d5af@zotac.lan> <20130305162240.98a989c7b3c0870a49020c85@zotac.lan> <20130306144548.42df5815309d3f982312c61c@zotac.lan> Message-ID: <20130312174630.c1cf75225e3170610ec4824f@zotac.lan> Hi Boris, > Anyway, here is the plan that I think will address all the issues: > > 1. Add --{with,without}-gcc-plugin-dir option to ODB configure. This > option can be used as follows: > > a) --with-gcc-plugin-dir: force installing into GCC's plugin dir > with is obtainer by running $CXX -print-file-name=plugin > > b) --without-gcc-plugin-dir: force installing into $libexecdir/odb/ > even if test #2.b below succeeds. > > c) --with-gcc-plugin-dir=/path/to/gcc/plugin/dir: install plugin > into the specified directory. This method will have to be used > for cross-compilation. > > 2. If we are not cross-compiling, then: > > b) If $libexecdir is a prefix of `$CXX -print-file-name=plugin`, > then install into the gcc plugin dir. One can use > --without-gcc-plugin-dir to override this. On my systems at least, condition 2.b) will likely never be met: $ gcc --print-file-name=plugin /usr/lib/gcc/x86_64-pc-linux-gnu/4.7.2/plugin $ ls /usr/libexec/gcc/x86_64-pc-linux-gnu/4.7.2/plugin/ gengtype Note that "gengtype" plugin. That is kinda interesting, because gcc -fplugin=gengtype does not find it, obviously because gcc searches only '/usr/lib/gcc/x86_64-pc-linux-gnu/4.7.2/plugin'. I've also looked into what dragonegg does, however they too install into their own directory, so not much to learn from them. > c) Use `$CXX -print-file-name=plugin`/include as the plugin include > directory. That would be in full accordance with the GCC documentation. > 3. If we are cross-compiling then the user will have to specify the > plugin include directory via the CPPFLAGS configure variable. Another way to express the same thing would be that the developer needs to specify the path to the plugin headers of exactly that GCC version he must have already built for 'host'. So why not use --with-gcc-plugin-dir within this context? Since ODB by itself is not a compiler, but a library to be used by gcc either on 'build' or 'host', there remain two scenarios: 1/ ODB programs need to be compilable on 'build' only, creating binaries on 'build' for use with 'host'. The plugin consequently installs into 'build': . GCC compiles a plugin for GCC using plugin headers from GCC . build build build 2/ ODB programs need to be compilable on 'host' only, creating binaries on 'host' for use with 'host'. The plugin consequently installs into 'host': . GCC compiles a plugin for GCC using plugin headers from GCC . build host host > 4. If the plugin is installed into the GCC plugin dir, then the ODB > compiler driver will obtain the GCC's plugin dir at runtime, > append the plugin name (odb.so) and pass this absolute path to > -fplugin. This way things will work consistently with GCC 4.5 > (which doesn't support short plugin name) and later. > Do you see any problems with this plan? Except for installing the plugin below /usr/libexec, which I feel would not really be needed anymore. Is there a remaining use case? Without an installed gcc or with an installed gcc without plugin support, installing odb.so anywhere does not make much sense. Hugo From eric.b.sum at lmco.com Wed Mar 13 01:20:15 2013 From: eric.b.sum at lmco.com (Sum, Eric B) Date: Wed Mar 13 01:20:23 2013 Subject: [odb-users] Representation of INTERSECT SQLite Query Message-ID: Hi, I am using odb version 2.0 and SQLite version 3.7.13. I am trying to represent a SQLite query in odb somehow, but I am not sure how to. Here is an example of the type of query I would like to write: Given the following object: #pragma db object struct Box { #pragma db id int id; int length; int width; int height; int weight; }; Raw SQL query given the parameters lengthIn, widthIn, and maxBoxes to bind to the query: SELECT id, height, weight from Box WHERE length = INTERSECT SELECT id, height, weight from Box WHERE width = ORDER BY height DESC LIMIT ; My guess was to use a native view along the lines of #pragma db view query ( "SELECT id, height, weight from Box WHERE length = ? INTERSECT " \ "SELECT id, height, weight from Box WHERE width = ? "\ "ORDER BY height DESC LIMIT ?") struct BoxView { #pragma type ("INTEGER") int id; #pragma type ("INTEGER") int height; #pragma type ("INTEGER") int weight; }; However, I am not sure how to provide the lengthIn, widthIn, and maxBoxes variables through the ? parameters. I did not see an example in the manual of how to handle more than one (?) parameter, but I may have missed it. Is this view correct? If so, how do I perform the actual query with the three variables needed. Any help/suggestions would be greatly appreciated. Also, the reason I want to do an INTERSECT rather than "WHERE length = AND width = " is for possible performance improvements (the AND query is too slow currently). Thanks so much, Eric From grignon.florian at gmail.com Wed Mar 13 04:05:29 2013 From: grignon.florian at gmail.com (grignon florian) Date: Wed Mar 13 04:05:46 2013 Subject: [odb-users] [Search of feature] LIKE in the ODB query language In-Reply-To: References: Message-ID: <51403349.2030502@gmail.com> Hi Boris, Sorry for the delay, I will let you know how it works. Thank you, Florian On 02/21/2013 12:46 PM, Boris Kolpackov wrote: > Hi Florian, > > florian grignon writes: > >> I would be very glad to have your patch when you're done with it. > Ok, I've added the SQL LIKE support for the next release (2.3.0). To > try it with 2.2.0, you will need to do the following: > > 1. Apply the following patch to libodb-2.2.2: > > http://scm.codesynthesis.com/?p=odb/libodb.git;a=patch;h=4962329eecb716bc2b99810ec1ac4214606fc1e8 > > 2. Apply the following patch to libodb-sqlite-2.2.0 (similar patches for > all the other database runtimes are available): > > http://scm.codesynthesis.com/?p=odb/libodb-sqlite.git;a=patch;h=b580f1548ff335a0e1fa004fc6626486535c94e1 > > Once, this is done, you can use the new like() function like this: > > query::name.like ("J%"); > > Or, with the escape character: > > query::name.like ("%!_Doe", "!"); > > Let us know how it works for you. > > Boris From boris at codesynthesis.com Wed Mar 13 09:08:38 2013 From: boris at codesynthesis.com (Boris Kolpackov) Date: Wed Mar 13 09:08:45 2013 Subject: [odb-users] Representation of INTERSECT SQLite Query In-Reply-To: References: Message-ID: Hi Eric, Sum, Eric B writes: > SELECT id, height, weight from Box WHERE length = INTERSECT > SELECT id, height, weight from Box WHERE width = > ORDER BY height DESC LIMIT ; > > [...] > > However, I am not sure how to provide the lengthIn, widthIn, and maxBoxes > variables through the ? parameters. ODB does not use placeholders for parameter binding. Instead, you bind variables directly. Because your query have two WHERE clauses, the only way to handle this case is by providing the complete query at runtime: #pragma db view struct BoxView { int id; int height; int weight; }; typedef odb::query query; int length = ...; int width = ...; int limit = ...; db.query ("SELECT id, height, weight from Box " "WHERE length =" + query::_val (length) + "INTERSECT SELECT id, height, weight from Box " "WHERE width =" + query::_val (width) + "ORDER BY height DESC LIMIT" + query::_val (limit)); If you upgrade to 2.2.0, then you could also use prepared queries to tidy this up. > Also, the reason I want to do an INTERSECT rather than "WHERE length = > AND width = " is for possible performance > improvements (the AND query is too slow currently). >From your use of the word "possible" I reckon you don't have any evidence that it is actually faster ;-). I also don't see a reason why it would. On the other hand, adding an index for length and width should definitely help (#pragma db index is available since 2.1.0): #pragma db object struct Box { #pragma db id int id; #pragma db index int length; #pragma db index int width; int height; int weight; }; Boris From boris at codesynthesis.com Wed Mar 13 09:29:23 2013 From: boris at codesynthesis.com (Boris Kolpackov) Date: Wed Mar 13 09:29:29 2013 Subject: [odb-users] odb-2.2.1 should install the odb.so plugin into $(gcc -print-file-name=plugin) In-Reply-To: <20130312174630.c1cf75225e3170610ec4824f@zotac.lan> References: <20130304110153.5b753c2f4d25cceb0a2c7dc8@zotac.lan> <20130305125335.1209f5a03b8817eddc87d5af@zotac.lan> <20130305162240.98a989c7b3c0870a49020c85@zotac.lan> <20130306144548.42df5815309d3f982312c61c@zotac.lan> <20130312174630.c1cf75225e3170610ec4824f@zotac.lan> Message-ID: Hi Hugo, Hugo.Mildenberger@web.de writes: > On my systems at least, condition 2.b) will likely never be met: > > $ gcc --print-file-name=plugin > /usr/lib/gcc/x86_64-pc-linux-gnu/4.7.2/plugin Good catch! It is the same story on Fedora (but not on Debian, where libexec is not used). I don't see any harm in checking if either $libdir or $libexecdir is a prefix of `gcc --print-file-name=plugin` in the 2.b test. > > 3. If we are cross-compiling then the user will have to specify the > > plugin include directory via the CPPFLAGS configure variable. > > Another way to express the same thing would be that the developer needs > to specify the path to the plugin headers of exactly that GCC version > he must have already built for 'host'. So why not use --with-gcc-plugin-dir > within this context? Yes, I suppose we can add the include/ sub-directory of this directory to the search paths automatically. > Except for installing the plugin below /usr/libexec, which I feel > would not really be needed anymore. Is there a remaining use case? > Without an installed gcc or with an installed gcc without plugin > support, installing odb.so anywhere does not make much sense. For example, someone may want to install multiple versions of ODB into some non-default location (e.g., /opt/odb-2.1 and /opt/odb-2.2) In this case, installing the plugin into the GCC's directory will override the previous installation. Generally, I don't think it is correct to install the plugin into the GCC's directory unless both GCC and ODB are installed into the same prefix or the user explicitly instructed us to do so. Think about installing ODB into /usr/local and installing plugin into /usr/lib/... -- does not feel right. Boris From Hugo.Mildenberger at web.de Wed Mar 13 11:31:55 2013 From: Hugo.Mildenberger at web.de (Hugo.Mildenberger@web.de) Date: Wed Mar 13 11:32:05 2013 Subject: [odb-users] odb-2.2.1 should install the odb.so plugin into $(gcc -print-file-name=plugin) In-Reply-To: References: <20130304110153.5b753c2f4d25cceb0a2c7dc8@zotac.lan> <20130305125335.1209f5a03b8817eddc87d5af@zotac.lan> <20130305162240.98a989c7b3c0870a49020c85@zotac.lan> <20130306144548.42df5815309d3f982312c61c@zotac.lan> <20130312174630.c1cf75225e3170610ec4824f@zotac.lan> Message-ID: <20130313163155.ff51b63eddebb2575a344f7d@zotac.lan> Hi Boris, Boris Kolpackov wrote: > H> Except for installing the plugin below /usr/libexec, which I feel > H> would not really be needed anymore. Is there a remaining use case? > H> Without an installed gcc or with an installed gcc without plugin > H> support, installing odb.so anywhere does not make much sense. > > For example, someone may want to install multiple versions of ODB > into some non-default location (e.g., /opt/odb-2.1 and /opt/odb-2.2) > In this case, installing the plugin into the GCC's directory will > override the previous installation. Doesn't your argument call for the conclusion that the ODB plugin filename needs a version tag? > Generally, I don't think it is correct to install the plugin into > the GCC's directory unless both GCC and ODB are installed into the > same prefix or the user explicitly instructed us to do so. Think > about installing ODB into /usr/local and installing plugin into > /usr/lib/... -- does not feel right. Yes, I like the "same-prefix" idea. Hugo From newhite at rslfibersystems.com Wed Mar 13 12:07:47 2013 From: newhite at rslfibersystems.com (Nathan White) Date: Thu Mar 14 03:35:41 2013 Subject: [odb-users] Error - Using ODB with Eclipse CDT Message-ID: Hello, I successfully compiled and ran examples Hello and Query with terminal. The next step is to compile Hello with eclipse because ultimately I'll be using eclipse for my IDE. I used the resource: http://wiki.codesynthesis.com/Using_ODB_with_Eclipse_CDT to build the hello example in eclipse. I configured the C++ Build ->settings for person.hxx, see Step-3 PersonhxxConfigure.png; and created the bootstrap, see Step-5 Bootstrap.png. When I click build for the Bootstrap, I believe the IDE would create the three -odb files. This is the same step as entering: odb -d sqlite --generate-query --generate-schema person.hxx into terminal. I receive the following error in the console when I click the bootstrap build. ------------------------------------------------- 10:20:58 **** Build of configuration Debug for project odb_hello **** make ../person-odb.hxx make: *** No rule to make target `../person-odb.hxx'. Stop. 10:20:58 Build Finished (took 77ms) --------------------------------------------------- After configuring the paths for the project, See step 4, I clicked Build All (Projects -> Build All) and received this error: --------------------------------------------------- Errors occurred during the build. Errors running builder 'CDT Builder' on project 'odb_hello'. java.lang.NullPointerException --------------------------------------------------- Is the person.hxx file incorrectly configured for the build? Regards, Nathan -------------- next part -------------- A non-text attachment was scrubbed... Name: Step-3 PersonhxxConfigure.png Type: image/png Size: 106446 bytes Desc: Step-3 PersonhxxConfigure.png Url : http://codesynthesis.com/pipermail/odb-users/attachments/20130313/51365340/Step-3PersonhxxConfigure-0001.png -------------- next part -------------- A non-text attachment was scrubbed... Name: Step-4a IncludePaths.png Type: image/png Size: 145701 bytes Desc: Step-4a IncludePaths.png Url : http://codesynthesis.com/pipermail/odb-users/attachments/20130313/51365340/Step-4aIncludePaths-0001.png -------------- next part -------------- A non-text attachment was scrubbed... Name: Step-4b LibraryPaths.png Type: image/png Size: 133388 bytes Desc: Step-4b LibraryPaths.png Url : http://codesynthesis.com/pipermail/odb-users/attachments/20130313/51365340/Step-4bLibraryPaths-0001.png -------------- next part -------------- A non-text attachment was scrubbed... Name: Step-4c Libraries.png Type: image/png Size: 135773 bytes Desc: Step-4c Libraries.png Url : http://codesynthesis.com/pipermail/odb-users/attachments/20130313/51365340/Step-4cLibraries-0001.png -------------- next part -------------- A non-text attachment was scrubbed... Name: Step-5 BootStrap.png Type: image/png Size: 37558 bytes Desc: Step-5 BootStrap.png Url : http://codesynthesis.com/pipermail/odb-users/attachments/20130313/51365340/Step-5BootStrap-0001.png From boris at codesynthesis.com Thu Mar 14 09:32:25 2013 From: boris at codesynthesis.com (Boris Kolpackov) Date: Thu Mar 14 09:32:35 2013 Subject: [odb-users] Error - Using ODB with Eclipse CDT In-Reply-To: References: Message-ID: Hi Nathan, Nathan White writes: > I receive the following error in the console when I click the bootstrap > build. Try to follow the steps on the Wiki page exactly. That is, don't change the directory structure, file content or their names, their locations, etc. If that works, then you can try to figure out what you've done differently that caused your problems. If it doesn't, then please let me know the version of Eclipse/CDT that you are using so that I can give it a try. Boris From boris at codesynthesis.com Thu Mar 14 09:43:33 2013 From: boris at codesynthesis.com (Boris Kolpackov) Date: Thu Mar 14 09:43:45 2013 Subject: [odb-users] odb-2.2.1 should install the odb.so plugin into $(gcc -print-file-name=plugin) In-Reply-To: <20130313163155.ff51b63eddebb2575a344f7d@zotac.lan> References: <20130305125335.1209f5a03b8817eddc87d5af@zotac.lan> <20130305162240.98a989c7b3c0870a49020c85@zotac.lan> <20130306144548.42df5815309d3f982312c61c@zotac.lan> <20130312174630.c1cf75225e3170610ec4824f@zotac.lan> <20130313163155.ff51b63eddebb2575a344f7d@zotac.lan> Message-ID: Hi Hugo, Hugo.Mildenberger@web.de writes: > Doesn't your argument call for the conclusion that the ODB plugin > filename needs a version tag? > > [...] > > Yes, I like the "same-prefix" idea. I also thought about this. But assuming the "same prefix" approach, there is no way to install multiple versions of the ODB compiler driver (i.e., there is no /usr/bin/odb-2.1.0 and /usr/bin/odb-2.2.0). So even if we add the version to the .so name, it will only be possible to load the version corresponding to the current /usr/bin/odb. I will try to implement the idea as discussed and let you know when it is ready to try. Boris From Hugo.Mildenberger at web.de Thu Mar 14 11:16:39 2013 From: Hugo.Mildenberger at web.de (Hugo.Mildenberger@web.de) Date: Thu Mar 14 11:16:48 2013 Subject: [odb-users] odb-2.2.1 should install the odb.so plugin into $(gcc -print-file-name=plugin) In-Reply-To: References: <20130305125335.1209f5a03b8817eddc87d5af@zotac.lan> <20130305162240.98a989c7b3c0870a49020c85@zotac.lan> <20130306144548.42df5815309d3f982312c61c@zotac.lan> <20130312174630.c1cf75225e3170610ec4824f@zotac.lan> <20130313163155.ff51b63eddebb2575a344f7d@zotac.lan> Message-ID: <20130314161639.da3ea9a040654341e5c7b098@zotac.lan> Hi Boris, Boris Kolpackov wrote: > I also thought about this. But assuming the "same prefix" approach, > there is no way to install multiple versions of the ODB compiler > driver (i.e., there is no /usr/bin/odb-2.1.0 and /usr/bin/odb-2.2.0). > So even if we add the version to the .so name, it will only be > possible to load the version corresponding to the current /usr/bin/odb. Such a situation can and should be handled by a package manager, externally from the ODB installer. Gentoo's "Portage" system provides so called 'slots' for this, making it easy to use several versions in parallel (and/or switch between any of them). I could implement this for the ODB compiler driver too if you think that switching back and forth between ODB versions is a common use case. Things get complicated only because the "odb.so" plugin must _also_ match the GCC version it was compiled with. I'd think that other distributions should support parallel installations as well. After all, it is very common that package A only relies on having B-3.2 installed whereas C only works with B-2.5. >I will try to implement the idea as discussed and let you know when >it is ready to try. Will do. I've reported this as a problem I've encountered only by chance. So give your ideas time to settle. Hugo From eric.b.sum at lmco.com Thu Mar 14 16:03:54 2013 From: eric.b.sum at lmco.com (Sum, Eric B) Date: Thu Mar 14 16:04:25 2013 Subject: [odb-users] Query Abort Error Message-ID: Hi, I am using odb version 2.2.0 with sqlite 3.7.13 in a multi-threaded application. The database uses a connection pool factory with minConnections and maxConnections of 0. Connections in the pool factory have a logging mechanism attached to them so that I can see the sql statements executed in text. I recently out of the blue ran into the error "4(517): aborted due to ROLLBACK" in the middle of doing a query when running the application. The query has run fine in previous runs and was executing fine in this exact run before this error arose. This is the first time that I have seen this. Because this problem has came up out of the blue with a query that has been running ok, I think that this is some sort of a race condition. Based on this link (http://osdir.com/ml/sqlite-users/2012-04/msg00696.html), my guess is that one of the connection's transactions in the factory got rolled back, and this caused the connection doing the query transaction to abort. This is the behavior described in shared_cache mode. I looked at the logs, and there were definitely lots of ROLLBACK statements around when the query aborted (could not isolate the exact statement). I believe that the rollback statements could be from failed attempts in the unlock_notify mechanism to perform sqlite3_step() calls, but I am not sure. I have been unable to duplicate this behavior. 1) Is this assessment correct? This is just my guess/interpretation of what's possibly happening. 2) If so, I am guessing that the odb exception thrown is recoverable (I am not sure which one). Therefore, could I simply catch the recoverable exception and retry the query(like in 3.7 of the manual) as a solution to this? Thanks so much. Any help is appreciated. -Eric From boris at codesynthesis.com Fri Mar 15 07:57:54 2013 From: boris at codesynthesis.com (Boris Kolpackov) Date: Fri Mar 15 07:58:02 2013 Subject: [odb-users] Query Abort Error In-Reply-To: References: Message-ID: Hi Eric, Sum, Eric B writes: > 1) Is this assessment correct? Yes, this seems like a new "feature" in SQLite 3.7.11. From the mailing list thread that you have referenced my understanding is that in the shared cache mode a rollback in one transaction can cause rollbacks in other (unrelated) transactions. Needless to say, this is quite a bizarre behavior. Specifically, I believe this change in the 3.7.11 changelog is to blame: "Pending statements no longer block ROLLBACK. Instead, the pending statement will return SQLITE_ABORT upon next access after the ROLLBACK." > 2) If so, I am guessing that the odb exception thrown is recoverable > (I am not sure which one). We don't handle this situation in ODB yet. We need to add a new SQLite- specific recoverable exception (e.g., 'forced_rollback') and throw it if we get the SQLITE_ABORT_ROLLBACK extended error code. I will let you know when there is a patch available for 2.2.0. > Therefore, could I simply catch the recoverable exception and retry > the query(like in 3.7 of the manual) as a solution to this? Yes, that will be the idea. Boris From boris at codesynthesis.com Mon Mar 18 08:31:38 2013 From: boris at codesynthesis.com (Boris Kolpackov) Date: Mon Mar 18 08:31:46 2013 Subject: [odb-users] Query Abort Error In-Reply-To: References: Message-ID: Hi Eric, Ok, I've added the odb::sqlite::forced_rollback recoverable exception. Here is the relevant part from the updated manual: "In SQLite 3.7.11 or later, if one of the connections participating in the shared cache rolls back a transaction, then ongoing transactions on other connections in the shared cache may also be forced to rollback. An example of such behavior would be a read-only transaction that is forced to rollback while iterating over the query result because another transaction on another connection was rolled back. If a transaction is being forced to rollback by SQLite, then ODB throws odb::sqlite::forced_rollback (Section 16.4, "SQLite Exceptions") which is a recoverable exception (3.7 Error Handling and Recovery). As a result, the recommended way to handle this exception is to re-execute the affected transaction." I also tried to reproduce this behavior using the 'threads' test in the ODB test suite but couldn't. While the 'threads' test doesn't abort any transactions explicitly, it can cause deadlocks which then will lead to transaction aborts. Is your application aborting transactions explicitly or does this also happen because of the deadlocks? I packaged the 2.2.1 bugfix. Can you give it a try and let me know if everything works for you: http://www.codesynthesis.com/~boris/tmp/odb/libodb-sqlite-2.2.1.tar.gz Once you confirm that everything is ok, I will make the bugfix release official. Boris From boris at codesynthesis.com Tue Mar 19 09:17:34 2013 From: boris at codesynthesis.com (Boris Kolpackov) Date: Tue Mar 19 09:17:43 2013 Subject: [odb-users] odb-2.2.1 should install the odb.so plugin into $(gcc -print-file-name=plugin) In-Reply-To: <20130314161639.da3ea9a040654341e5c7b098@zotac.lan> References: <20130305162240.98a989c7b3c0870a49020c85@zotac.lan> <20130306144548.42df5815309d3f982312c61c@zotac.lan> <20130312174630.c1cf75225e3170610ec4824f@zotac.lan> <20130313163155.ff51b63eddebb2575a344f7d@zotac.lan> <20130314161639.da3ea9a040654341e5c7b098@zotac.lan> Message-ID: Hi Hugo, Ok, I've implemented support for installing the ODB plugin into the default GCC plugin directory. Everything works pretty much exactly as discussed in our prior exchange. Here is the patch: http://scm.codesynthesis.com/?p=odb/odb.git;a=patch;h=a2dee162af41c80827ff60d87c08ea981b55b31b Please give it a try and let me know if there are any issues. On a related note, this got me thinking that if one wants to support multiple versions of GCC, then the ODB compiler will probably have to be split into two packages: the ODB compiler driver (/usr/bin/odb plus documentation) and ODB plugin (odb.so, one for each GCC version). Boris From boris at codesynthesis.com Tue Mar 19 09:37:27 2013 From: boris at codesynthesis.com (Boris Kolpackov) Date: Tue Mar 19 09:37:34 2013 Subject: [odb-users] libodb-sqlite 2.2.1 bugfix released Message-ID: Hi, New bugfix release for the SQLite ODB runtime library (libodb-sqlite) is now available. It adds the odb::sqlite::forced_rollback recoverable exception which is thrown if SQLite forces a transaction to roll back. This behavior is new to SQLite 3.7.11. For more details on this issue, see the following mailing list thread: http://www.codesynthesis.com/pipermail/odb-users/2013-March/001168.html You can download the new packages from the ODB download page: http://www.codesynthesis.com/products/odb/download.xhtml SHA1 checksums for the files in this release are as follows: fa4fdc5993901cf5483031939917a4db3e2f7e36 libodb-sqlite-2.2.1.tar.bz2 e322a5d8335657d6fb12092943c5dfc87e087e31 libodb-sqlite-2.2.1.tar.gz 1b542b9f64d4fece943939919356b36ab511fcfb libodb-sqlite-2.2.1.zip Boris From newhite at rslfibersystems.com Mon Mar 18 10:09:31 2013 From: newhite at rslfibersystems.com (Nathan White) Date: Tue Mar 19 09:49:24 2013 Subject: [odb-users] Error - Using ODB with Eclipse CDT In-Reply-To: References: Message-ID: Boris, In Step 4 Eclipse gave me an error because the library and include files don't exist in /opt/odb/. Below is the summary of where the files exist. The odb executable is found in /usr/bin/odb (executable (application/x-executable)) The includes are found in /usr/lib/odb/i686-linux-gnu/includes/ and /usr/local/include/odb In /usr/lib/odb/i686-linux-gnu/includes/ there are: c++ folder and odb folder. In /usr/local/include/odb/ there are: boost.options, boost folder, database.hxx, database.ixx, database.txx, etc The libraries are found in /usr/lib/odb/i686-linux-gnu/lib and /usr/local/lib. In /usr/lib/odb/i686-linux-gnu/lib/ there are: gcc folder, libgcc_s.so, libgcc_s.so.1, etc In /usr/local/lib/ there are: Libodb-2.2.so, libodb-sqlite-2.2.so, libodb.a, libodb-sqlite.a, etc Here are the versions I'm using for Eclipse CDT: Eclipse Java EE IDE for Web Developers. Version: Juno Service Release 1 Build id: 20120920-0800 Eclipse C/C++ Development Tools Version: 8.1.1.201209170703 Build id: @build@ (c) Copyright Eclipse contributors and others, 2000, 2010. All rights reserved. Visit http://www.eclipse.org/cdt Eclipse C/C++ Development Tools SDK Version: 8.1.1.201209170703 Build id: @build@ (c) Copyright Eclipse contributors and others, 2005, 2010. All rights reserved. Visit http://www.eclipse.org/cdt GDB Common Version: 7.0.0.201209170703 Build id: @build@ (c) Copyright Eclipse contributors and others, 2000, 2010. All rights reserved. Visit http://www.eclipse.org/cdt -----Original Message----- From: Boris Kolpackov [mailto:boris@codesynthesis.com] Sent: Thursday, March 14, 2013 9:32 AM To: Nathan White Cc: odb-users@codesynthesis.com Subject: Re: [odb-users] Error - Using ODB with Eclipse CDT Hi Nathan, Nathan White writes: > I receive the following error in the console when I click the > bootstrap build. Try to follow the steps on the Wiki page exactly. That is, don't change the directory structure, file content or their names, their locations, etc. If that works, then you can try to figure out what you've done differently that caused your problems. If it doesn't, then please let me know the version of Eclipse/CDT that you are using so that I can give it a try. Boris -------------- next part -------------- A non-text attachment was scrubbed... Name: Screenshot from 2013-03-18 095029.png Type: image/png Size: 199287 bytes Desc: Screenshot from 2013-03-18 095029.png Url : http://codesynthesis.com/pipermail/odb-users/attachments/20130318/f607e7f4/Screenshotfrom2013-03-18095029-0001.png From boris at codesynthesis.com Tue Mar 19 10:00:56 2013 From: boris at codesynthesis.com (Boris Kolpackov) Date: Tue Mar 19 10:01:04 2013 Subject: [odb-users] Error - Using ODB with Eclipse CDT In-Reply-To: References: Message-ID: Hi Nathan, Nathan White writes: > In Step 4 Eclipse gave me an error because the library and include files > don't exist in /opt/odb/. In the introduction the guide says: "Here we assume that the ODB compiler is installed in /opt/odb and that the ODB runtime libraries (libodb and libodb-, where stands for the database system that you are using) were built and installed in /opt/odb/include (header files) and /opt/odb/lib (library files)." If you installed things in a different location, then you will need to adjust the paths accordingly (and here I assume that you are proficient enough in GNU/Linux development to know what "accordingly" means). > The odb executable is found in /usr/bin/odb Then you should be able to use just odb instead of /opt/odb/bin/odb in step #3. > The includes are found in /usr/lib/odb/i686-linux-gnu/includes/ and > /usr/local/include/odb The /usr/lib/odb/i686-linux-gnu/includes/ is an internal ODB compiler directory and you should not specify it explicitly. > The libraries are found in /usr/lib/odb/i686-linux-gnu/lib and > /usr/local/lib. Again, /usr/lib/odb/i686-linux-gnu/lib is an internal ODB compiler directory that should not be used in your own builds. Since you installed the runtime libraries in /usr/local, you should be able to skip the first part of step #4 ("Includes" and "Library Paths" settings). The compiler will search in this directory by default. Boris From paul.harrison at manchester.ac.uk Tue Mar 19 18:02:42 2013 From: paul.harrison at manchester.ac.uk (Paul Harrison) Date: Wed Mar 20 03:35:44 2013 Subject: [odb-users] reuse inheritance with abstract base Message-ID: <14F202BC-850A-42B7-9EDE-4C045B32BEAE@manchester.ac.uk> Hi, I am trying to use reuse inheritance with an abstract base #pragma db object abstract class Local_Oscillator_P: public Persist { friend class odb::access; protected: //Data members #pragma db id uint32 _id; //!< added key // - other data members omitted for clarity... }; and #pragma db object table("BT_Local_Oscillator") class BT_Local_Oscillator_P: public Local_Oscillator_P { friend class odb::access; public: //Constructors & Destructors BT_Local_Oscillator_P(); BT_Local_Oscillator_P(sint32 id, sint32 id_number, std::string &id_name, IEEE_double lo_freq, IEEE_double delta_freq, IEEE_double power, uint32 multiplier, sint32 sense, uint32 options); ~BT_Local_Oscillator_P(); }; and on compilation I get band_table_entry_p.h:67:56: error: pointed-to class '::BT_Local_Oscillator_P' is abstract for a class that is trying to use a pointer to the concrete class thus std::list< lazy_shared_ptr > _los;//!< LO settings is this expected behaviour? - I note that the documentation says that the abstract class cannot be pointed to, but I am clearly pointing to the concrete class. Regards, Paul. Dr. Paul Harrison JBCA, Manchester University http://www.manchester.ac.uk/jodrellbank From paul.harrison at manchester.ac.uk Wed Mar 20 03:38:51 2013 From: paul.harrison at manchester.ac.uk (Paul Harrison) Date: Wed Mar 20 03:38:54 2013 Subject: [odb-users] reuse inheritance with abstract base Message-ID: Hi, I am trying to use reuse inheritance with an abstract base #pragma db object abstract class Local_Oscillator_P: public Persist { friend class odb::access; protected: //Data members #pragma db id uint32 _id; //!< added key // - other data members omitted for clarity... }; and #pragma db object table("BT_Local_Oscillator") class BT_Local_Oscillator_P: public Local_Oscillator_P { friend class odb::access; public: //Constructors & Destructors BT_Local_Oscillator_P(); BT_Local_Oscillator_P(sint32 id, sint32 id_number, std::string &id_name, IEEE_double lo_freq, IEEE_double delta_freq, IEEE_double power, uint32 multiplier, sint32 sense, uint32 options); ~BT_Local_Oscillator_P(); }; and on compilation I get band_table_entry_p.h:67:56: error: pointed-to class '::BT_Local_Oscillator_P' is abstract for a class that is trying to use a pointer to the concrete class thus std::list< lazy_shared_ptr > _los;//!< LO settings is this expected behaviour? - I note that the documentation says that the abstract class cannot be pointed to, but I am clearly pointing to the concrete class. Regards, Paul. Dr. Paul Harrison JBCA, Manchester University http://www.manchester.ac.uk/jodrellbank From paul.harrison at manchester.ac.uk Wed Mar 20 03:54:56 2013 From: paul.harrison at manchester.ac.uk (Paul Harrison) Date: Wed Mar 20 03:54:59 2013 Subject: [odb-users] reuse inheritance with abstract base In-Reply-To: References: Message-ID: <71D39A31-4267-4BAA-8845-0657352A4A57@manchester.ac.uk> On 2013-03 -20, at 07:38, Paul Harrison wrote: > Hi, > > I am trying to use reuse inheritance with an abstract base > > > and on compilation I get > > band_table_entry_p.h:67:56: error: pointed-to class '::BT_Local_Oscillator_P' is abstract > > > for a class that is trying to use a pointer to the concrete class thus > > std::list< lazy_shared_ptr > _los;//!< LO settings > > > is this expected behaviour? - I note that the documentation says that the abstract class cannot be pointed to, but I am clearly pointing to the concrete class. I have just realised that although my class was not "ODB abstract" it was still C++ abstract - correcting that allows the ODB compilation to complete successfully... Paul. From Hugo.Mildenberger at web.de Mon Mar 25 06:15:47 2013 From: Hugo.Mildenberger at web.de (Hugo.Mildenberger@web.de) Date: Mon Mar 25 06:16:01 2013 Subject: [odb-users] odb-2.2.1 should install the odb.so plugin into $(gcc -print-file-name=plugin) In-Reply-To: References: <20130305162240.98a989c7b3c0870a49020c85@zotac.lan> <20130306144548.42df5815309d3f982312c61c@zotac.lan> <20130312174630.c1cf75225e3170610ec4824f@zotac.lan> <20130313163155.ff51b63eddebb2575a344f7d@zotac.lan> <20130314161639.da3ea9a040654341e5c7b098@zotac.lan> Message-ID: <20130325111547.b9560626c3219bcbe35ac008@zotac.lan> Hi Boris, Boris Kolpackov wrote: > Ok, I've implemented support for installing the ODB plugin into the > default GCC plugin directory. Everything works pretty much exactly > as discussed in our prior exchange. Here is the patch: > > http://scm.codesynthesis.com/?p=odb/odb.git;a=patch;h=a2dee162af41c80827ff60d87c08ea981b55b31b > > Please give it a try and let me know if there are any issues. Looks good! I gather that the installer has to set "--with-gcc-plugin-dir" in order make use of this feature. Yet, in order to make this change fully functional, I also need to tie the ODB installer to a Gentoo slot (a major ODB version, for all practical means), because else Portage removes the "old" version while installing the recompiled package. However, when emulating slots manually, I can now switch back and forth between compilers. Good! > > On a related note, this got me thinking that if one wants to support > multiple versions of GCC, then the ODB compiler will probably have > to be split into two packages: the ODB compiler driver (/usr/bin/odb > plus documentation) and ODB plugin (odb.so, one for each GCC version). This is what I naively assumed to be given in the first place, that the GCC plugin actually was independent from the compiler driver. If you actually need to support different GCC versions by different code in the plugin itself, then factoring out GCC version specifics is certainly a reasonable approach, also with regard to maintainability. I found it often very hard to read and understand what #ifdef'ed code really does after all. Yet I still think that if you want to have different ODB (plugin/compiler) versions installed in parallel, you actually need to encode at least the plugin version into the plugin file name. Hugo From canismajorwuff at gmail.com Sun Mar 24 18:35:27 2013 From: canismajorwuff at gmail.com (CanisMajorWuff) Date: Mon Mar 25 07:09:18 2013 Subject: [odb-users] helloworld: undefined reference to `odb::result_impl Message-ID: <514F7FAF.1090503@gmail.com> Hello, I am trying to compile your 'Hello World' Example. And I am stuck with the following errror: Waf: Entering directory `e:\Documents\documents\C++Projects\odb\build\release' [1/3] cxx: src\driver.cxx -> build\release\src\driver.cxx.1.o [2/3] cxx: src\person-odb.cxx -> build\release\src\person-odb.cxx.1.o [3/3] cxxprogram: build\release\src\driver.cxx.1.o build\release\src\person-odb.cxx.1.o -> build\release\src\odb.e xe src\person-odb.cxx.1.o:person-odb.cxx:(.text+0x15e4): undefined reference to `odb::result_impl::result_impl(odb::c onnection&)' src\person-odb.cxx.1.o:person-odb.cxx:(.text+0x310e): undefined reference to `odb::result_impl::result_impl(odb::c onnection&)' d:/mingw/bin/../lib/gcc/x86_64-w64-mingw32/4.7.1/../../../../x86_64-w64-mingw32/bin/ld.exe: src\person-odb.cxx.1.o : bad reloc address 0x0 in section `.data' collect2.exe: error: ld returned 1 exit status Waf: Leaving directory `e:\Documents\documents\C++Projects\odb\build\release' Build failed -> task in 'odb' failed (exit status 1): {task 52254480L: cxxprogram driver.cxx.1.o,person-odb.cxx.1.o -> odb.exe} ['d:\\mingw\\bin\\g++.exe', '-Wl,--enable-auto-import', 'src\\driver.cxx.1.o', 'src\\person-odb.cxx.1.o', '-o', 'e :\\Documents\\documents\\C++Projects\\odb\\build\\release\\src\\odb.exe', '-Wl,-Bstatic', '-LD:/mingw/lib', '-LD:/ odb/lib/lib', '-LD:/odb/lib-sqlite/lib', '-lodb-sqlite', '-lodb', '-Wl,-Bdynamic'] Libraries were successfully compiled by this: ./configure --disable-shared --build=x86_64-w64-mingw32 --prefix=/d/odb/libodb && make&& make install ./configure --disable-shared CPPFLAGS="-I/d/odb/lib/include -I/d/sqlite3/sqlite3/include" LDFLAGS="-L/d/odb/l ib/lib -L/d/sqlite3/sqlite3/lib" --build=x86_64-w64-mingw32 --prefix=/d/odb/lib-sqlite && make && make install Thx. From boris at codesynthesis.com Mon Mar 25 07:47:43 2013 From: boris at codesynthesis.com (Boris Kolpackov) Date: Mon Mar 25 07:48:01 2013 Subject: [odb-users] helloworld: undefined reference to `odb::result_impl In-Reply-To: <514F7FAF.1090503@gmail.com> References: <514F7FAF.1090503@gmail.com> Message-ID: Hi, CanisMajorWuff writes: > ['d:\\mingw\\bin\\g++.exe', '-Wl,--enable-auto-import', > 'src\\driver.cxx.1.o', 'src\\person-odb.cxx.1.o', '-o', 'e > :\\Documents\\documents\\C++Projects\\odb\\build\\release\\src\\odb.exe', > '-Wl,-Bstatic', '-LD:/mingw/lib', '-LD:/ > odb/lib/lib', '-LD:/odb/lib-sqlite/lib', '-lodb-sqlite', '-lodb', > '-Wl,-Bdynamic'] Hm, I see you are trying to link the ODB runtimes statically but the error suggests that the symbols are still being resolves as DLL-imported. This would normally indicate that your compilation picks up libodb/libodb-sqlite headers that were configured as DLL. Do you have -I/d/odb/lib-odb/include -I/d/odb/lib-sqlite/include in your C++ compiler command line? Some things that you may want to try: 1. Remove the --enable-auto-import option and see what happens. 2. Try to compile and link the test executable manually by running g++ directly with appropriate options. Boris From boris at codesynthesis.com Mon Mar 25 08:00:37 2013 From: boris at codesynthesis.com (Boris Kolpackov) Date: Mon Mar 25 08:00:43 2013 Subject: [odb-users] odb-2.2.1 should install the odb.so plugin into $(gcc -print-file-name=plugin) In-Reply-To: <20130325111547.b9560626c3219bcbe35ac008@zotac.lan> References: <20130306144548.42df5815309d3f982312c61c@zotac.lan> <20130312174630.c1cf75225e3170610ec4824f@zotac.lan> <20130313163155.ff51b63eddebb2575a344f7d@zotac.lan> <20130314161639.da3ea9a040654341e5c7b098@zotac.lan> <20130325111547.b9560626c3219bcbe35ac008@zotac.lan> Message-ID: Hi Hugo, Hugo.Mildenberger@web.de writes: > I gather that the installer has to set "--with-gcc-plugin-dir" in order > make use of this feature. No, if GCC and ODB prefixes match (which will most definitely be the case in your situation), then ODB will install the plugin into the GCC directory automatically. If you specify --with-gcc-plugin-dir, then you force ODB to install the plugin into the GCC directory regardless of the prefix. > Yet, in order to make this change fully functional, I also need to tie > the ODB installer to a Gentoo slot (a major ODB version, for all practical > means), because else Portage removes the "old" version while installing > the recompiled package. However, when emulating slots manually, I can > now switch back and forth between compilers. I am not sure I 100% understand what you mean by this but I think I disagree. You don't need slots for the ODB compiler itself. You just need to install a separate ODB plugin for each supported version of GCC and single /usr/bin/odb will load the right one depending on the version of GCC that is currently in effect. > > On a related note, this got me thinking that if one wants to support > > multiple versions of GCC, then the ODB compiler will probably have > > to be split into two packages: the ODB compiler driver (/usr/bin/odb > > plus documentation) and ODB plugin (odb.so, one for each GCC version). > > This is what I naively assumed to be given in the first place, that the > GCC plugin actually was independent from the compiler driver. It is. More precisely, the ODB compiler driver does not depend on the GCC version. So you can have multiple plugins (one for each version of GCC installed) and a single driver (/usr/bin/odb) and it will all work automatically. I.e., you can do: odb -x g++-4.5 ... # Load plugin for GCC 4.5 odb -x g++-4.6 ... # Load plugin for GCC 4.6 odb -x g++-4.7 ... # Load plugin for GCC 4.7 > Yet I still think that if you want to have different ODB (plugin/compiler) > versions installed in parallel, you actually need to encode at least the > plugin version into the plugin file name. Yes, if one day we decide we want to support this, we can do that. Though it sounds to me like the same approach that you will use to save/restore /usr/bin/odb can also be used to save/restore odb.so. Boris From Hugo.Mildenberger at web.de Mon Mar 25 09:31:34 2013 From: Hugo.Mildenberger at web.de (Hugo.Mildenberger@web.de) Date: Mon Mar 25 09:31:43 2013 Subject: [odb-users] odb-2.2.1 should install the odb.so plugin into $(gcc -print-file-name=plugin) In-Reply-To: References: <20130306144548.42df5815309d3f982312c61c@zotac.lan> <20130312174630.c1cf75225e3170610ec4824f@zotac.lan> <20130313163155.ff51b63eddebb2575a344f7d@zotac.lan> <20130314161639.da3ea9a040654341e5c7b098@zotac.lan> <20130325111547.b9560626c3219bcbe35ac008@zotac.lan> Message-ID: <20130325143134.e422980051b30f267e1566aa@zotac.lan> Hi Boris, Boris Kolpackov wrote: >h> I gather that the installer has to set "--with-gcc-plugin-dir" in order >h> make use of this feature. > > No, if GCC and ODB prefixes match (which will most definitely be the case > in your situation), then ODB will install the plugin into the GCC directory > automatically. If you specify --with-gcc-plugin-dir, then you force ODB > to install the plugin into the GCC directory regardless of the prefix. It actually did not work that way. Without setting "--with-gcc-plugin-dir", the odb.so plugin was not installed in $(gcc --print-file-name=plugin) but somewhere below "/usr/libexec/odb" (if I remember the directory correctly). I've not yet looked further into the details, why that fails, because I assumed it to be intended behaviour. Can you point me where to look specifically? >h> Yet, in order to make this change fully functional, I also need to tie >h> the ODB installer to a Gentoo slot (a major ODB version, for all practical >h> means), because else Portage removes the "old" version while installing >h> the recompiled package. However, when emulating slots manually, I can >h> now switch back and forth between compilers. > > I am not sure I 100% understand what you mean by this but I think I > disagree. You don't need slots for the ODB compiler itself. You just > need to install a separate ODB plugin for each supported version of > GCC and single /usr/bin/odb will load the right one depending on the > version of GCC that is currently in effect. Well, the problem is that Portage holds a list of all files installed by any installed package. Before a package gets reinstalled, all files contained in this list are removed (except for directories and files modified by other packages). A package not defining a slot will get assigned to slot 0 by default, so any newly installed version will replace the previously installed one. This is why I think a separate package for the plugin would be a good idea. > > b> On a related note, this got me thinking that if one wants to support > > b> multiple versions of GCC, then the ODB compiler will probably have > > b> to be split into two packages: the ODB compiler driver (/usr/bin/odb > > b> plus documentation) and ODB plugin (odb.so, one for each GCC version). > > >h> This is what I naively assumed to be given in the first place, that the >h> GCC plugin actually was independent from the compiler driver. > > It is. More precisely, the ODB compiler driver does not depend on the GCC > version. So you can have multiple plugins (one for each version of GCC > installed) and a single driver (/usr/bin/odb) and it will all work > automatically. I.e., you can do: > > odb -x g++-4.5 ... # Load plugin for GCC 4.5 > odb -x g++-4.6 ... # Load plugin for GCC 4.6 > odb -x g++-4.7 ... # Load plugin for GCC 4.7 > Good news. >h> Yet I still think that if you want to have different ODB (plugin/compiler) >h> versions installed in parallel, you actually need to encode at least the >h> plugin version into the plugin file name. > > Yes, if one day we decide we want to support this, we can do that. I understood that the need to support several ODB versions in parallel was your main concern within the context of this thread. It was not my objective then, but I was able to see the potential benefit of being able to switch both between the ODB-versions and the GCC-version. > Though it sounds to me like the same approach that you will use to save/restore > /usr/bin/odb can also be used to save/restore odb.so. Alas, Portage will not do that on her own. I had to write an ODB module for the "eselect" utility, which would be tasked with stashing away files and changing symbolic links. Once implemented, it would be possible to switch between ODB-versions too, to wit: $ eselect odb list 2.2 * odb-2.2.1 2.3 odb-2.3.5_pre1 2.4 odb-2.4.1 $ eselect odb set 2.4 I'm a bit unsure which ODB related packages exactly would need to be managed. Can you, e.g., sensibly use any database back-end library with a more recent compiler driver? Hugo From boris at codesynthesis.com Mon Mar 25 13:03:34 2013 From: boris at codesynthesis.com (Boris Kolpackov) Date: Mon Mar 25 13:03:42 2013 Subject: [odb-users] odb-2.2.1 should install the odb.so plugin into $(gcc -print-file-name=plugin) In-Reply-To: <20130325143134.e422980051b30f267e1566aa@zotac.lan> References: <20130312174630.c1cf75225e3170610ec4824f@zotac.lan> <20130313163155.ff51b63eddebb2575a344f7d@zotac.lan> <20130314161639.da3ea9a040654341e5c7b098@zotac.lan> <20130325111547.b9560626c3219bcbe35ac008@zotac.lan> <20130325143134.e422980051b30f267e1566aa@zotac.lan> Message-ID: Hi Hugo, Hugo.Mildenberger@web.de writes: > It actually did not work that way. Without setting "--with-gcc-plugin-dir", > the odb.so plugin was not installed in $(gcc --print-file-name=plugin) but > somewhere below "/usr/libexec/odb" (if I remember the directory correctly). > I've not yet looked further into the details, why that fails, because I > assumed it to be intended behaviour. Can you point me where to look > specifically? If configure's libdir or libexecdir is a prefix of the GCC plugin directory (i.e., `gcc --print-file-name=plugin`), then ODB should install there automatically. If that's the case but this doesn't happen for you, then it is definitely a bug that I would like to track down. The test in question is in m4/gcc-plugin.m4, starts at line 63. > This is why I think a separate package for the plugin would be a good > idea. Yes, as I said before, you would need to split the ODB compiler into the driver package (/usr/bin/odb plus documentation) and plugin packages, one for each version of GCC. > I understood that the need to support several ODB versions in parallel > was your main concern within the context of this thread. Nop, at this stage I am only concerned with supporting multiple version of GCC (so that if the user switches the GCC version, ODB will still work). > I'm a bit unsure which ODB related packages exactly would need to be > managed. Can you, e.g., sensibly use any database back-end library > with a more recent compiler driver? Nop, we only guarantee things will work properly if the ODB compiler driver and all the runtime libraries have exactly the same major and minor version (i.e., X.Y in odb-X.Y.Z). Which means that to support multiple ODB versions one would need to supports "switching" a lot of libraries, headers, etc. I don't think this is worth the trouble at this stage. Let's first get a single ODB version working from the official repository. Boris From Hugo.Mildenberger at web.de Mon Mar 25 15:34:07 2013 From: Hugo.Mildenberger at web.de (Hugo.Mildenberger@web.de) Date: Mon Mar 25 15:34:16 2013 Subject: [odb-users] odb-2.2.1 should install the odb.so plugin into $(gcc -print-file-name=plugin) In-Reply-To: References: <20130312174630.c1cf75225e3170610ec4824f@zotac.lan> <20130313163155.ff51b63eddebb2575a344f7d@zotac.lan> <20130314161639.da3ea9a040654341e5c7b098@zotac.lan> <20130325111547.b9560626c3219bcbe35ac008@zotac.lan> <20130325143134.e422980051b30f267e1566aa@zotac.lan> Message-ID: <20130325203407.4ce9a1b55fc559395bf8b668@zotac.lan> Hi Boris, Boris Kolpackov wrote: > If configure's libdir or libexecdir is a prefix of the GCC plugin > directory (i.e., `gcc --print-file-name=plugin`), then ODB should > install there automatically. If that's the case but this doesn't > happen for you, then it is definitely a bug that I would like to > track down. > > The test in question is in m4/gcc-plugin.m4, starts at line 63. I've put some trace statements therein. This is the result: | checking whether to install ODB plugin into default GCC plugin directory... | prefix='/usr' | ac_default_prefix='/usr/local' | e_exec_prefix='/usr' | libdir='/usr/lib64' | e_libdir='/usr/lib64' | e_libexecdir='/usr/libexec' | ld_suffix='/usr/lib/gcc/x86_64-pc-linux-gnu/4.7.2/plugin' | led_suffix='/usr/lib/gcc/x86_64-pc-linux-gnu/4.7.2/plugin' | dir='/usr/lib/gcc/x86_64-pc-linux-gnu/4.7.2/plugin' | no > Yes, as I said before, you would need to split the ODB compiler into > the driver package (/usr/bin/odb plus documentation) and plugin packages, > one for each version of GCC. I hesitate to split up this package on the fly. I'd assumed that you thought about making the plugin a separate package? > Nop, at this stage I am only concerned with supporting multiple version > of GCC (so that if the user switches the GCC version, ODB will still work). Ok, but you said so, before. > Nop, we only guarantee things will work properly if the ODB compiler > driver and all the runtime libraries have exactly the same major and > minor version (i.e., X.Y in odb-X.Y.Z). Which means that to support > multiple ODB versions one would need to supports "switching" a lot > of libraries, headers, etc. I don't think this is worth the trouble > at this stage. Let's first get a single ODB version working from the > official repository. God willing... Hugo From canismajorwuff at gmail.com Mon Mar 25 14:21:00 2013 From: canismajorwuff at gmail.com (CanisMajorWuff) Date: Tue Mar 26 06:53:25 2013 Subject: [odb-users] odb compiler build error Message-ID: <5150958C.8060508@gmail.com> Hello, I am trying to build odb compiler. I successfully built libcutl. But during building of the compiler I got the following error: make[2]: Entering directory `/d/odb/odbbuild/odbsrc/odb' depbase=`echo cxx-lexer.lo | sed 's|[^/]*$|.deps/&|;s|\.lo$||'`;\ /bin/sh ../libtool --tag=CXX --mode=compile g++ -DHAVE_CONFIG_H -I'..' -I'..' -I/d/odb/libcutl/include -g -O2 -MT cxx-lexer.lo -MD -MP -MF $depbase.Tpo -c -o cxx-lexer.lo cxx-lexer.cxx &&\ mv -f $depbase.Tpo $depbase.Plo libtool: compile: g++ -DHAVE_CONFIG_H -I.. -I.. -I/d/odb/libcutl/include -g -O2 -MT cxx-lexer.lo -MD -MP -MF .dep s/cxx-lexer.Tpo -c cxx-lexer.cxx -o cxx-lexer.o In file included from ../odb/gcc.hxx:8:0, from cxx-lexer.cxx:5: ../odb/gcc-fwd.hxx:10:23: fatal error: coretypes.h: No such file or directory compilation terminated. make[2]: *** [cxx-lexer.lo] Error 1 make[2]: Leaving directory `/d/odb/odbbuild/odbsrc/odb' make[1]: *** [all] Error 2 make[1]: Leaving directory `/d/odb/odbbuild/odbsrc/odb' make: *** [all-recursive] Error 1 From boris at codesynthesis.com Tue Mar 26 07:00:23 2013 From: boris at codesynthesis.com (Boris Kolpackov) Date: Tue Mar 26 07:00:30 2013 Subject: [odb-users] odb compiler build error In-Reply-To: <5150958C.8060508@gmail.com> References: <5150958C.8060508@gmail.com> Message-ID: Hi, CanisMajorWuff writes: > I am trying to build odb compiler. Building ODB on Windows is tricky since GCC plugins are not (yet) supported on this platform due dynamic loading deficiencies. So the easiest way is to use the pre-built Windows binary of the ODB compiler that we distribute (if you still need to build ODB yourself, search the mailing list archives; there are a couple of older threads with further pointers). > ../odb/gcc-fwd.hxx:10:23: fatal error: coretypes.h: No such file or directory I am surprised you got past the configure stage since it checks for plugin support in GCC. Did you configure ODB with --disable-shared? If not, what does the following command print for you? g++ -print-file-name=plugin Boris From boris at codesynthesis.com Tue Mar 26 07:16:59 2013 From: boris at codesynthesis.com (Boris Kolpackov) Date: Tue Mar 26 07:17:06 2013 Subject: [odb-users] odb-2.2.1 should install the odb.so plugin into $(gcc -print-file-name=plugin) In-Reply-To: <20130325203407.4ce9a1b55fc559395bf8b668@zotac.lan> References: <20130313163155.ff51b63eddebb2575a344f7d@zotac.lan> <20130314161639.da3ea9a040654341e5c7b098@zotac.lan> <20130325111547.b9560626c3219bcbe35ac008@zotac.lan> <20130325143134.e422980051b30f267e1566aa@zotac.lan> <20130325203407.4ce9a1b55fc559395bf8b668@zotac.lan> Message-ID: Hi Hugo, Hugo.Mildenberger@web.de writes: > I've put some trace statements therein. This is the result: > > [...] > > | libdir='/usr/lib64' Ok, I see what happens here. Libraries are installed into /usr/lib64, private executables into /usr/libexec, and GCC into /usr/lib. I've added the $prefix/lib check as a special case: http://scm.codesynthesis.com/?p=odb/odb.git;a=patch;h=f148cec91a4c98c5f4ad7fe248f9f9fba70174b9 > I hesitate to split up this package on the fly. I'd assumed that you > thought about making the plugin a separate package? No, I have no plans to split the ODB compiler into multiple packages. ODB is already very fragmented. Boris From Hugo.Mildenberger at web.de Tue Mar 26 14:49:04 2013 From: Hugo.Mildenberger at web.de (Hugo.Mildenberger@web.de) Date: Tue Mar 26 14:49:12 2013 Subject: [odb-users] odb-2.2.1 should install the odb.so plugin into $(gcc -print-file-name=plugin) In-Reply-To: References: <20130313163155.ff51b63eddebb2575a344f7d@zotac.lan> <20130314161639.da3ea9a040654341e5c7b098@zotac.lan> <20130325111547.b9560626c3219bcbe35ac008@zotac.lan> <20130325143134.e422980051b30f267e1566aa@zotac.lan> <20130325203407.4ce9a1b55fc559395bf8b668@zotac.lan> Message-ID: <20130326194904.62f3bb38068ec6b710642244@zotac.lan> Hi Boris, On Tue, 26 Mar 2013 13:16:59 +0200 Boris Kolpackov wrote: > Ok, I see what happens here. Libraries are installed into /usr/lib64, > private executables into /usr/libexec, and GCC into /usr/lib. I've > added the $prefix/lib check as a special case: > > http://scm.codesynthesis.com/?p=odb/odb.git;a=patch;h=f148cec91a4c98c5f4ad7fe248f9f9fba70174b9 Ok, your patch applied cleanly and 'odb.so' now gets installed into $(gcc -print-file-name=plugin) per default. The problem is a consequence of the very popular /usr/lib{,32,64} mess, with /usr/lib actually being a symbolic link to '/usr/lib64' here. Hugo From boris at codesynthesis.com Fri Mar 29 13:12:59 2013 From: boris at codesynthesis.com (Boris Kolpackov) Date: Fri Mar 29 13:13:07 2013 Subject: [odb-users] Re: SQL Variant In-Reply-To: <249906D2DF7F3449BA7E2F4F6AA0046F01913D2E7C88@BURI.PacificCabinets.com> References: <249906D2DF7F3449BA7E2F4F6AA0046F01913D2E7C88@BURI.PacificCabinets.com> Message-ID: Hi Dean, I've CC'ed the odb-users mailing list to my reply since others may also be interested in this topic. Dean Throop writes: > On April 8, 2012 you indicated that ODB does not support the MS SQL > Variant type. Is this still the case? I have a database I am accessing > that utilizes this value type for something critical I need and I am > unable to modify the database. ODB now supports a feature called "extended database type mapping". Essentially, it allows you to map any "extra" database type (spatial types, user-defined types, arrays, XML, etc) to a C++ type using one of the natively-supported types (normally string or binary) as an interface type. This blog post has a nice overview of this feature: http://www.codesynthesis.com/~boris/blog/2012/07/18/custom-database-to-cxx-type-mapping-in-odb/ In the ODB manual, the relevant section is 12.7, "Database Type Mapping Pragmas". I went ahead and added a test case to the mssql/custom test that shows how to map SQL Server SQL_VARIANT type to a C++ variant class that can store integer or string value. You can view the code here: http://scm.codesynthesis.com/?p=odb/odb-tests.git;a=tree;f=mssql/custom;h=a1c1bd958f4e471a991b780d4092b09329e1f394;hb=HEAD The idea is to represent SQL_VARIANT values as a string that contains the base type name and value, separated by a space (e.g., 'bigint 123' or 'varchar abc'). We implement two SQL Server functions (custom.sql): variant_to_string() and string_to_variant() which convert between SQL_VARIANT and this string representation. With the help of these functions we tell ODB how to map SQL_VARIANT to VARCHAR(max) (test.hxx). We also implement the ODB value_traits specialization for our variant C++ class that decodes our string representation of SQL_VARIANT (traits.hxx, traits.cxx). Overall, everything works great, even queries. Boris From aakmail at mail.ru Sat Mar 30 15:48:02 2013 From: aakmail at mail.ru (=?UTF-8?B?QWxleGFuZGVyIEtvbmlu?=) Date: Sun Mar 31 11:38:47 2013 Subject: [odb-users] ODB polymorphic inheritence problem Message-ID: <1364672882.31976372@f343.mail.ru> Hi, I am upgrading from ODB 1.8 to ODB 2.2. And there is problem with polymorphic inheritance. Consider the following hierarchy: Item <- Parent <- Segment. Item contains pointer to Parent, and Parent has list of contained Items, but concreate Parent descendants declare this list (or lists). So, we have one-to-many relation, and I use inversion on "many" side: ==== File Item.h class Parent; // Root class of some subsystem, has reference (parent_) to parent class #pragma db object polymorphic table("Items") class Item { ? private: ? ? ?#pragma db id auto ? ? ?int id_; ? ? ?#pragma db null ? ? ?Parent* parent_; ... }; #ifdef ODB_COMPILER ? ? ?#include "Parent.h" #endif ==== File Parent.h // Class that designates parent node #pragma db object table("Parents") class Parent : public Item { ? ?// This class has no members, but descendants have lists of parented items ? ?... }; ==== File Segment.h // A class that is Parent. Segment contains other segments as its children. #pragma db object table("Segments") class Segment : public Parent, public Segmentable { ? private: ? ? ?#pragma db value_not_null inverse(parent_) ? ? ?QList segments_; ? ? ... }; The problem is that ODB generates incorrect SQL instructions for loading Segment::segments_: ==== File Segment-odb.cxx: const char access::object_traits_impl< ::Database::Segment, id_pgsql >::segments_traits:: select_statement[] = "SELECT " "\"Segments\".\"id\"" " FROM \"Segments\"" " WHERE \"Segments\".\"parent\"=$1"; "parent" field is contained in "Items" table (we have Item::parent_), not "Segments" table! How can I solve the problem, or there is not possible? Thanks in advance, Alexander Konin From DThroop at PacificCabinets.com Sun Mar 31 19:46:41 2013 From: DThroop at PacificCabinets.com (Dean Throop) Date: Sun Mar 31 19:46:53 2013 Subject: [odb-users] MS SQL Foreign Key Error Message-ID: <249906D2DF7F3449BA7E2F4F6AA0046F01913D31AEF6@BURI.PacificCabinets.com> I would greatly appreciate anyone's assistance in understanding how I am screwing up this implementation. I am new to ODB, and not a C++ expert. My primary objective is to change a to-one relationship to a pragmatically determined entity that already exists in the database. My schema is locked as this is an existing production database, for which I am working on a local, temp copy. I have a Products table with a to-one relationship to an ItemTypes table. The ItemTable's primary key is an int "ID" with two additional fields. The Products table holds the pertinent ItemTypes table ID in the ItemTypeID field and there is a FK constraint. I am providing basic stubs of what I think is pertinent, but I will be happy to zip anything anyone else would like to see. Please note that my classes are fully encapsulated. Thanks in advance, and please feel free to let me if I am doing something else stupid. main { ... transaction t(iesDB->begin ()); Product *aProduct(iesDB->load(pID)); std::vector productTypes; odb::result r(iesDB->query(query::isProduct==true)); for(odb::result::iterator i(r.begin ());i!=r.end ();++i) { productTypes.push_back (*i); } aProduct->ConfigureProduct (productTypes); //does a couple of things, then executes the SetProductType(productTypes) iesDB->update(*aProduct); t.commit (); } #pragma db object table("ItemTypes") class ItemType { public: ItemType(); ~ItemType(); const std::string& GetName() const; bool IsAProduct() const; private: friend class odb::access; #pragma db id auto int id; std::string name; bool isProduct; }; #pragma db object table ("Products") class Product { public: Product(); ~Product(); bool ConfigureProduct(const std::vector &productTypes); private: friend class odb::access; #pragma db not_null column("ItemTypeID") ItemType* productType; bool SetProductType(const std::vector &productTypes); }; bool Product::SetProductType(const std::vector &productTypes) { if(GetProductType ()!=currentProductType) { for(std::vector::const_iterator i(productTypes.begin ());i!=productTypes.end ();++i) { if(i->GetName()==currentProductType) { ItemType theValue=*i; productType=&theValue; break; } } } } Error message: terminate called after throwing an instance of 'odb::mssql::database_exception' what(): 547(23000)[Microsoft][SQL Server Native Client 11.0][SQL Server] The UPDATE statement conflicted with the FOREIGN KEY constraint "FK_Products_ItemTypes". The conflict occurred in database "PCI_IES_DB", table "dbo.ItemTypes", column 'ID'. Dean