From boris at codesynthesis.com Mon Oct 3 08:41:02 2011 From: boris at codesynthesis.com (Boris Kolpackov) Date: Mon Oct 3 08:42:09 2011 Subject: [odb-users] Recommended way of creating a verbose/debug/log mode with ODB and sqlite? In-Reply-To: <50FEB91CC4FBAB4881226E0EC04AC340975C2C5E@HVXMSP9.us.lmco.com> References: <50FEB91CC4FBAB4881226E0EC04AC340975C2C5E@HVXMSP9.us.lmco.com> Message-ID: Hi Thomas, Szumowski, Thomas writes: > For debugging purposes, I'd like to be able to acquire a log of all the > native SQL statements that ODB executes during a program run. In native > sqlite, I believe this is possible through the sqlite_trace API. Is there > something similar in ODB? While we are planning to add support for database-independent statement tracing to ODB, it is not ready yet. In the meantime, it is possible to use the sqlite_trace() function, provided you have 1.6.0.a2 or later (final 1.6.0 should be out in a few days). If your application is single-threaded (i.e., uses one database connection at any given time), then you can simply do: odb::sqlite::database& db = ... { odb::sqlite::connection_ptr c (db.connection ()); sqlite3* handle (c.handle ()); sqlite3_trace (handle, ...); } If the application is multi-threaded (or may use multiple connections simultaneously), then you can override the create() function in the connection_pool_factory class and enable tracing for every SQLite connection that the pool creates. For example: class trace_connection_pool_factory: public odb::sqlite::connection_pool_factory { public: trace_connection_pool_factory (std::size_t max_connections = 0, std::size_t min_connections = 0) : connection_pool_factory (max_connections, min_connections) { } virtual pooled_connection_ptr create () { pooled_connection_ptr c (connection_pool_factory::create ()); sqlite3* handle (c.handle ()); sqlite3_trace (handle, ...); return c; } }; Then, when creating the database instance, we need to pass our custom connection factory, for example: auto_ptr f ( new trace_connection_pool_factory); auto_ptr db ( new sqlite::database (argc, argv, false, SQLITE_OPEN_READWRITE, f)); Note that the second approach will also work for the first case (single- threaded applications). Boris From boris at codesynthesis.com Mon Oct 3 08:54:11 2011 From: boris at codesynthesis.com (Boris Kolpackov) Date: Mon Oct 3 08:55:18 2011 Subject: [odb-users] Re: Explain please the essence of the strange update_statement In-Reply-To: References: Message-ID: Hi Viacheslav, ???????? ?????????? writes: > Tests have not confirmed any delay when using surplus appropriation. > The database implementation is STILL REALLY smart enough to detect > this and not do anything expensive. Thanks for sharing your test results. Even though there doesn't seem to be any performance impact (at least in case of MySQL), we have decided to change the way we do it now and avoid sending object id in UNDATE statements. The added benefit of this change is that we will be able to implement proper const/read-only data members. Unfortunately, because these changes are quite significant, we could not make them in time for the upcoming release. So there won't be read- only support in 1.6.0. But, we will implement this support first thing after the release and I will build you a pre-release as soon as it is ready. I hope this will work for you. Boris From thomas.szumowski at lmco.com Mon Oct 3 14:50:06 2011 From: thomas.szumowski at lmco.com (Szumowski, Thomas) Date: Mon Oct 3 14:50:54 2011 Subject: [odb-users] Cascading Persists Message-ID: <50FEB91CC4FBAB4881226E0EC04AC34097617ED9@HVXMSP9.us.lmco.com> We noticed some other ORM solutions offer the option to enable cascading persists. For example, consider you have an employer class that has a one-to-many-relationship with employee. Assume several associated employees were updated in C++, or additional employees were added to the employer object. A cascading persist would mean if I persist/update the employer, all the subsequent employees are also persisted/updated. While I understand issues can arise in the ORM mapping from this, it adds a significant convenience in certain circumstances. Is this possible at all in ODB? -Tom From boris at codesynthesis.com Tue Oct 4 03:58:47 2011 From: boris at codesynthesis.com (Boris Kolpackov) Date: Tue Oct 4 03:59:49 2011 Subject: [odb-users] ODB 1.6.0 released Message-ID: Hi, We have released ODB 1.6.0. The NEWS file entries for this release are as follows: * New concept, view, is a C++ class that embodies a light-weight, read- only projection of one or more persistent objects or database tables or the result of a native SQL query execution. Some of the common applications of views include loading a subset of data members from objects or columns from database tables, executing and handling results of arbitrary SQL queries, including aggregate queries, as well as joining multiple objects and/or database tables using object relationships or custom join conditions. For more information refer to Chapter 9, "Views" in the ODB manual as well as the 'view' example in the odb-examples package. * New function, database::erase_query(), allows the deletion of the database state of multiple objects matching certain criteria. It uses the same query expression as the database::query() function. For more information, refer to Section 3.10, "Deleting Persistent Objects" in the ODB manual. * Support for value wrappers. An ODB value wrapper is a class template that wraps a value type or a container. Common examples of wrappers are smart pointers, holders, and "optional value" containers such as boost::optional. A wrapper can be transparent or it can handle the NULL semantics. To allow the easy conversion of value types that do not support the NULL semantics into the ones that do, the odb::nullable class template has been added. ODB now also includes built-in support for std::auto_ptr and std::tr1::shared_ptr smart pointers as value wrappers as well as for boost::shared_ptr and QSharedPointer via the Boost and Qt profiles. Currently, the NULL semantics is only supported for simple values but smart pointers can still be used with composite values and containers. For more information, refer to Section 7.3, "NULL Value Semantics" in the ODB manual. * Support for the boost::optional container in the Boost profile. A data member of the boost::optional type is mapped to a column that can have a NULL value. For more information, refer to Section 15.3 "Optional Library" in the ODB manual. * Support for mapping std::vector to the BLOB (or equivalent) types. For more information, refer to Chapters 11 (for MySQL), 12 (for SQLite) and 13 (for PostgreSQL) in the ODB manual. * New option, --table-prefix, allows the specification of a prefix that is added to table and index names. For more information, refer to the ODB compiler command line interface documentation (man pages). * New ODB runtime library interface, odb::connection, represents a connection to the database. The primary use case for a connection is to execute native statements outside of a transaction. For more information, refer to Section 3.5, "Connections" in the ODB manual. * Support for multiplexing several transactions on the same thread. For more information, refer to Section 3.4, "Transactions" in the ODB manual. * All the concrete connection classes now have a second constructor which allows the creation of a connection instance from an already established underlying connection handle. The connection_pool_factory and, in case of SQLite, single_connection_factory now have a virtual create() function that can be overridden to implement custom connection establishment and configuration. * The query expression syntax for object pointers and composite values has changed. Now, instead of using the scope resolution operator ('::'), the member access via a pointer operator (->) is used for object pointers and the member access operator (.) is used for composite values. Examples of old and new syntax for pointers, old: query::employer::name, new: query::employer->name. For composites values, old: query::name::first, new: query::name.first. * SQLite ODB runtime now enables foreign key constraints checking by default. While this should not affect correct applications, due to bugs in SQLite DDL foreign keys support, you may need to temporarily disable foreign key constraints checking when re-creating the database schema (the sign that you may need to do so is the "foreign key constraint failed" exception thrown by the commit() function after the call to schema_catalog::create_schema()). For more information, refer to Section 12.5.3, "Foreign Key Constraints" in the ODB manual. * Support for specifying the client character set for the MySQL database. For more information, refer to Section 11.2, "MySQL Database Class" in the ODB manual. * Object cache maintained by a session no longer distinguishes between const and non-const objects. Instead, const objects are treated as non-const by casting away constness. For more information on this new behavior, refer to Section 9.1, "Object Cache" in the ODB manual. This version has also been tested with the recently released PostgreSQL 9.1. We would like to thank everyone who reported bugs, shared test results, or helped test one of the alpha releases. Source code and pre-compiled binary packages for this release are available from the ODB download page: http://www.codesynthesis.com/products/odb/download.xhtml SHA1 checksums for the files in this release are as follows: b52a982fa02ea8f6d1f5aa08c6b3e14d6441fdda libodb-1.6.0.tar.bz2 46ac4f44d50f337163689686c7b50630a5d596ec libodb-1.6.0.tar.gz bf56e3ae9c2e2945eaf3b59ae389d9dfd677ba02 libodb-1.6.0.zip d54ab619de4b49ae051ea874c4448d20f6063fe1 libodb-boost-1.6.0.tar.bz2 f265040f1fd787e8ab16881f38fd494a28029e12 libodb-boost-1.6.0.tar.gz 9a41f5fceed1b96e182c51c85f5c5e6acbda82d4 libodb-boost-1.6.0.zip 7ff5b7f800ea0bf22db272d66d8ee0a3b801da45 libodb-mysql-1.6.0.tar.bz2 9c2c8a4373e01f2c4eb49985e21f4c0b46d2147e libodb-mysql-1.6.0.tar.gz 519f905797132bd4142d67b055ad89942e40871c libodb-mysql-1.6.0.zip 1ad31db0215a39865286647738c675f98d6ad9eb libodb-pgsql-1.6.0.tar.bz2 8a89a85dd5011de379806a7cea341f87d8ee7058 libodb-pgsql-1.6.0.tar.gz d7b9187579a9217e158ea064889779d3683d1725 libodb-pgsql-1.6.0.zip 061c3af6108bf471e9a7792ca730a1d37a64efd8 libodb-qt-1.6.0.tar.bz2 b5977e3b9c57c0a56651002b41283b140bc5c05c libodb-qt-1.6.0.tar.gz 09e41a858116b1d557903a57d3735dd722b02490 libodb-qt-1.6.0.zip b0b63cf469a521bd61fae32eca9467e02b62af0d libodb-sqlite-1.6.0.tar.bz2 cdf175bd3741bf8c5a8b218410211f3d1162bbae libodb-sqlite-1.6.0.tar.gz e1a2f18777bae40e06c49fb6768c7def13c6e5a0 libodb-sqlite-1.6.0.zip e66a3667731701ae9853d87444e9c8b1afa4f4ff libodb-tracer-1.6.0.tar.bz2 829b50907d20a05d8f541fb2e87ed5041db20cbb libodb-tracer-1.6.0.tar.gz 57816e143d02630a75be808300caddaebd2a0b90 libodb-tracer-1.6.0.zip 128e14bd6cb8730222fc3b382cdb2780882173ca odb-1.6.0-i686-linux-gnu.tar.bz2 6eb1b1397ca76fa327d2d8d9b83fdb03eca25d51 odb-1.6.0-i686-macosx.tar.bz2 28c21fefc973a97ee7508f81f065bbb48c0902a9 odb-1.6.0-i686-solaris.tar.bz2 171ccb99559a615e0945f38a5e6d769f5714afd6 odb-1.6.0-i686-windows.zip 7bf0c43f087f454af04f2ba3c465bda62ce434c4 odb-1.6.0-sparc-solaris.tar.bz2 b839907c1705c1a75222a0143be62f06db5a5e28 odb-1.6.0.tar.bz2 ae0c8fc402ba984c978e7cdcd0df33cb742fea3e odb-1.6.0.tar.gz 18c95007d83a9f93bf517337f08063f3f80d548a odb-1.6.0-x86_64-linux-gnu.tar.bz2 e0b244bc6174bf4563546935017c4f9c975a0646 odb-1.6.0.zip d15d9f71035d2c9edecfeb73b24c3a809ecffa37 odb-examples-1.6.0.tar.bz2 fda3c66dc755e9e9c52f0e48551b289b2104158c odb-examples-1.6.0.tar.gz 9eb6e19306bd6b736050b5b6a68f04970e48582d odb-examples-1.6.0.zip 62b89e9f60865f42ad3d6b7a8ee744e13aa032ea odb-tests-1.6.0.tar.bz2 35354c115a274508481c263c0180492d65f3629b odb-tests-1.6.0.tar.gz 4e26c332c01d9fb5e46e688cf93acab72730a276 odb-tests-1.6.0.zip Enjoy, Boris From boris at codesynthesis.com Tue Oct 4 09:33:06 2011 From: boris at codesynthesis.com (Boris Kolpackov) Date: Tue Oct 4 09:34:08 2011 Subject: [odb-users] Cascading Persists In-Reply-To: <50FEB91CC4FBAB4881226E0EC04AC34097617ED9@HVXMSP9.us.lmco.com> References: <50FEB91CC4FBAB4881226E0EC04AC34097617ED9@HVXMSP9.us.lmco.com> Message-ID: Hi Thomas, Szumowski, Thomas writes: > We noticed some other ORM solutions offer the option to enable cascading > persists. For example, consider you have an employer class that has a > one-to-many-relationship with employee. Assume several associated employees > were updated in C++, or additional employees were added to the employer > object. A cascading persist would mean if I persist/update the employer, all > the subsequent employees are also persisted/updated. While I understand > issues can arise in the ORM mapping from this, it adds a significant > convenience in certain circumstances. Is this possible at all in ODB? It is possible to achieve this behavior but not entirely automatically. The idea is to use database operation callbacks (see Section 11.1.4, "callback" in the ODB manual) to manually check if any of the related objects need to be updated or persisted. The post_persist and post_update events are probably the right points where this should be done. This also means that there will have to be some kind of a flag that indicates whether the object is transient (and therefore needs to be persisted) or is modified (and therefore needs to be updated). For the transient indicator you can probably reserve a special value in the object id (e.g., 0 for integer ids and empty string for string ids). For the modified indicator you will most likely need some additional (transient) data member in the object to store this information. These requirements to know whether the object is transient or modified is one of the reasons why ODB does not (yet) support this functionality automatically. There just does not seem to be a way to support this without the user's assistance or without incurring a significant overhead. The other reason why we are not sure about adding this functionality is the potentially large number of database operations that can be triggered by a seemingly simple call. We are already observing this with object relationship loading where high-level and easy to use interface hides, to the user's surprise, potentially very expensive operations. I think everyone would agree that such automatic cascading makes it much harder to reason about ODB-based applications and especially about the performance implications of each operation. Having said that, we may still support cascading as an option at some point. Boris From thomas.szumowski at lmco.com Tue Oct 4 12:06:07 2011 From: thomas.szumowski at lmco.com (Szumowski, Thomas) Date: Tue Oct 4 12:11:22 2011 Subject: [odb-users] Multiple pointer types in a single object Message-ID: <50FEB91CC4FBAB4881226E0EC04AC3409765A098@HVXMSP9.us.lmco.com> Suppose I have a class that requires relationships to two different objects. One relationship requires weak_ptr, and one requires shared_ptr. Is this possible? We noticed one can assign the pointer type at the object level, ("#pragma db object pointer"), but what if we want multiple pointer types in a single object? e.g (for example purpose only) class employee { ... shared_ptr e; weak_ptr p; } Is this possible? (Please reply-all to include those CC'd) Thank you. -Tom From boris at codesynthesis.com Tue Oct 4 13:24:03 2011 From: boris at codesynthesis.com (Boris Kolpackov) Date: Tue Oct 4 13:25:05 2011 Subject: [odb-users] Multiple pointer types in a single object In-Reply-To: <50FEB91CC4FBAB4881226E0EC04AC3409765A098@HVXMSP9.us.lmco.com> References: <50FEB91CC4FBAB4881226E0EC04AC3409765A098@HVXMSP9.us.lmco.com> Message-ID: Hi Thomas, Szumowski, Thomas writes: > Suppose I have a class that requires relationships to two different > objects. One relationship requires weak_ptr, and one requires shared_ptr. > Is this possible? Yes, this is not a problem. > We noticed one can assign the pointer type at the object level, > ("#pragma db object pointer"), but what if we want multiple pointer > types in a single object? e.g (for example purpose only) > > class employee { > ... > shared_ptr e; > weak_ptr p; > } > > Is this possible? Yes, the object pointer that is assigned via db pointer pragma or using the --default-pointer option is what is used to return such objects from load(), etc. It should normally be a shared_ptr. But in object relationships you can use any pointer type as long as it can be created from the object pointer. So weak_ptr should not cause any problem here. You can even have something like this: class employee { shared_ptr current_employer; weak_ptr previous_employer; } Boris From charles.jabbourgedeon at gmail.com Tue Oct 4 16:01:58 2011 From: charles.jabbourgedeon at gmail.com (=?ISO-8859-1?Q?Charles_Jabbour_G=E9d=E9on?=) Date: Tue Oct 4 16:02:05 2011 Subject: [odb-users] Compilation time issue: undefined reference to `odb::access::object_traits Message-ID: Hello, First of all, sorry for my english, i am a french student who try to make your very interesting persistent framework work ! It is for my final internship ! So, i got an error when i try to compile my project: undefined reference to `odb::access::object_traits::persist(odb::database& I can't manage to work around this problem so i ask for some help if you have any time. I have attached a copy of the class that i try to make persistant. I lcreate the odb specific file by running this command: odb -d mysql --generate-query --generate-schema coque.hxx and i have copied the minimal code for main(): { MyCoque coque("random"); auto_ptr db (create_database (argc, argv)); transaction t (db->begin ()); db->persist (coque); t.commit(); } Any hint will be very valuable for me, i am quite stuck, and i am sure it is due to my inexperience. Thx in advance, Best regards, Charles JABBOUR GEDEON. -------------- next part -------------- A non-text attachment was scrubbed... Name: coque.hxx Type: text/x-c++hdr Size: 3297 bytes Desc: not available Url : http://codesynthesis.com/pipermail/odb-users/attachments/20111004/f35bc25d/coque.hxx From boris at codesynthesis.com Tue Oct 4 16:23:07 2011 From: boris at codesynthesis.com (Boris Kolpackov) Date: Tue Oct 4 16:24:04 2011 Subject: [odb-users] Compilation time issue: undefined reference to `odb::access::object_traits In-Reply-To: References: Message-ID: Hi Charles, Charles Jabbour G?d?on writes: > So, i got an error when i try to compile my project: > > undefined reference to > `odb::access::object_traits::persist(odb::database& > > [...] > > I create the odb specific file by running this command: > > odb -d mysql --generate-query --generate-schema coque.hxx The above command will create coque-odb.hxx, coque-odb.ixx, and coque-odb.cxx. You need to compile coque-odb.cxx and link the resulting object file into your application. Boris From art at it-gen.net Wed Oct 5 11:57:09 2011 From: art at it-gen.net (=?KOI8-R?B?99HexdPMwdcg89DJ0snEz87P1w==?=) Date: Wed Oct 5 16:11:58 2011 Subject: [odb-users] Optional PRAGMA_DB (id) Message-ID: Dear, Boris and odb-users The next question I have already touched on some time ago. And then wriggled a despotic addition to the object PRIMARY KEY. But I think that for such a simple task, this is unnecessary. So formulation of the problem: we need logged all visits of players. We will record PlayerId and Date. Us in the future there is no need to carry out any action which would require PRIMARY KEY. Here is the table structure: CREATE TABLE IF NOT EXISTS `players_enter` ( `PlayerId` INT (10) NOT NULL, `Date` date NOT NULL ) ENGINE = MyISAM; Please to advise the correct version of the structure dbo. Best regards, Viacheslav and sba From boris at codesynthesis.com Thu Oct 6 07:02:39 2011 From: boris at codesynthesis.com (Boris Kolpackov) Date: Thu Oct 6 07:03:33 2011 Subject: [odb-users] Re: Optional PRAGMA_DB (id) In-Reply-To: References: Message-ID: Hi Viacheslav, ???????? ?????????? writes: > So formulation of the problem: we need logged all visits of players. > We will record PlayerId and Date. Us in the future there is no need to > carry out any action which would require PRIMARY KEY. > > CREATE TABLE IF NOT EXISTS `players_enter` ( > `PlayerId` INT (10) NOT NULL, > `Date` date NOT NULL > ) ENGINE = MyISAM; Yes, I remember you asked for support for objects without ids some time ago. I did more thinking on this feature and I believe we can probably support this. Such objects, however, will have a number of limitations, biggest of which is that you won't be able to update such objects using the database::update() function. This is probably not an issue in your case, but I just want to confirm. Essentially, one will be able to persist such objects using the persist() function, load them using query() (load()/find() will not be supported) and delete such objects using erase_query() (again, normal erase() will be unavailable). Let me know if you see any problems with these limitations. Boris From art at it-gen.net Fri Oct 7 08:29:07 2011 From: art at it-gen.net (=?KOI8-R?B?99HexdPMwdcg89DJ0snEz87P1w==?=) Date: Fri Oct 7 08:29:35 2011 Subject: [odb-users] Re: Optional PRAGMA_DB (id) In-Reply-To: References: Message-ID: Dear, Boris and odb-users With the above restrictions do not have any problems. I will say more than this is exactly what we need! Because it is a separate set of tasks - logging of certain events in the project. So we should regularly save a new data (the data are generated directly on the fly), and optionally delete on a given criterion of old data. Deleting not even required, so as to regulate size of logs and can be outside. Also it is normally to not allocate logs. Of course as a "repository" of logs do not necessarily use the database. But we want to keep logs in a structured form, so to them it was easy to access from outside (not from the main project). Thus it is important to dbo supported interfaces persist () and erase_query (). The fact that an additional interface will query () - only plus:) In the above example, it still sounds like - all entrances of players are necessary to log in a project of the last month. Best regards, Viacheslav and sba 6 ??????? 2011??. 14:02 ???????????? Boris Kolpackov ???????: > Hi Viacheslav, > > ???????? ?????????? writes: > >> So formulation of the problem: we need logged all visits of players. >> We will record PlayerId and Date. Us in the future there is no need to >> carry out any action which would require PRIMARY KEY. >> >> CREATE TABLE IF NOT EXISTS `players_enter` ( >> ? `PlayerId` INT (10) NOT NULL, >> ? `Date` date NOT NULL >> ) ENGINE = MyISAM; > > Yes, I remember you asked for support for objects without ids some time > ago. I did more thinking on this feature and I believe we can probably > support this. Such objects, however, will have a number of limitations, > biggest of which is that you won't be able to update such objects using > the database::update() function. This is probably not an issue in your > case, but I just want to confirm. > > Essentially, one will be able to persist such objects using the persist() > function, load them using query() (load()/find() will not be supported) > and delete such objects using erase_query() (again, normal erase() will > be unavailable). Let me know if you see any problems with these > limitations. > > Boris > From akrzemi1 at gmail.com Fri Oct 7 05:06:14 2011 From: akrzemi1 at gmail.com (Andrzej Krzemienski) Date: Fri Oct 7 08:37:43 2011 Subject: [odb-users] Will ODB support Oracle Database? Message-ID: Hi, Are there plans (say, this year) to provide the support for Oracle databasein ODB? Regards, &rzej From boris at codesynthesis.com Fri Oct 7 09:43:25 2011 From: boris at codesynthesis.com (Boris Kolpackov) Date: Fri Oct 7 09:44:10 2011 Subject: [odb-users] Will ODB support Oracle Database? In-Reply-To: References: Message-ID: Hi Andrzej, Andrzej Krzemienski writes: > Are there plans (say, this year) to provide the support for Oracle > databasein ODB? Yes, we are working on it right now and it should be available for beta-testing in a week or two. Let me know if you would like to give it a try before the official release. Boris From uwe.kindler at cetoni.de Tue Oct 11 06:02:59 2011 From: uwe.kindler at cetoni.de (cetoni GmbH - Uwe Kindler) Date: Tue Oct 11 07:23:15 2011 Subject: [odb-users] Handling pimpl idiom in ODB Message-ID: <4E941453.6030703@cetoni.de> Hi Boris, back in August we talked about handling of pimpl idiom in ODB: http://codesynthesis.com/pipermail/odb-users/2011-August/000250.html You proposed the concept of virtual data members. Is the concept of virtual data members already implemented in the 1.6.0 release or is it planned for future releases? Kind regards, Uwe From boris at codesynthesis.com Tue Oct 11 08:23:33 2011 From: boris at codesynthesis.com (Boris Kolpackov) Date: Tue Oct 11 08:23:57 2011 Subject: [odb-users] Handling pimpl idiom in ODB In-Reply-To: <4E941453.6030703@cetoni.de> References: <4E941453.6030703@cetoni.de> Message-ID: Hi Uwe, cetoni GmbH - Uwe Kindler writes: > You proposed the concept of virtual data members. Is the concept of > virtual data members already implemented in the 1.6.0 release or is > it planned for future releases? It is still planned for one of the future releases. My impression was that you preferred the composite value type approach[1]. Have you had a chance to try it and if so were there any problems? [1] http://codesynthesis.com/pipermail/odb-users/2011-August/000250.html Boris From uwe.kindler at cetoni.de Tue Oct 11 08:44:05 2011 From: uwe.kindler at cetoni.de (cetoni GmbH - Uwe Kindler) Date: Tue Oct 11 09:50:47 2011 Subject: [odb-users] Handling pimpl idiom in ODB In-Reply-To: References: <4E941453.6030703@cetoni.de> Message-ID: <4E943A15.4030408@cetoni.de> Hi Boris, no, I did not try the composite value type approach yet. But if it is fully implemented in ODB 1.6.0 then we would switch from 1.4.0 to 1.6.0 to give it a try. Uwe From boris at codesynthesis.com Tue Oct 11 09:51:36 2011 From: boris at codesynthesis.com (Boris Kolpackov) Date: Tue Oct 11 09:51:59 2011 Subject: [odb-users] Handling pimpl idiom in ODB In-Reply-To: <4E943A15.4030408@cetoni.de> References: <4E941453.6030703@cetoni.de> <4E943A15.4030408@cetoni.de> Message-ID: Hi Uwe, cetoni GmbH - Uwe Kindler writes: > no, I did not try the composite value type approach yet. But if it is > fully implemented in ODB 1.6.0 then we would switch from 1.4.0 to 1.6.0 > to give it a try. Yes, it is fully supported in 1.6.0. Boris From chris.richards at yellowfeather.co.uk Tue Oct 11 12:19:43 2011 From: chris.richards at yellowfeather.co.uk (Chris Richards) Date: Tue Oct 11 12:19:58 2011 Subject: [odb-users] Plans for implementing optimistic concurrency Message-ID: <-2793872452730461468@unknownmsgid> Hi, In the manual it states that optimistic concurrency will be available in a future version, are you able to give a rough indication of when this will be available? Say this year? Regards, Chris From boris at codesynthesis.com Wed Oct 12 07:44:45 2011 From: boris at codesynthesis.com (Boris Kolpackov) Date: Wed Oct 12 07:45:09 2011 Subject: [odb-users] Plans for implementing optimistic concurrency In-Reply-To: <-2793872452730461468@unknownmsgid> References: <-2793872452730461468@unknownmsgid> Message-ID: Hi Chris, Chris Richards writes: > In the manual it states that optimistic concurrency will be available > in a future version, are you able to give a rough indication of when > this will be available? Say this year? It is on our TODO list but we haven't scheduled it yet for any particular release. Having said that, it shouldn't be too difficult for us to implement this using a member of an object as a version. Something like this: #pragma db object optimistic(version_) class person { ... unsigned long version_; }; The ODB will then check/manage the version and throw an exception if we try to overwrite a commit with update(). Would something like this work for your case? If so, would you be willing to start using a pre-release if we implemented this (we like to release new features that someone is already using ;-))? Boris From an9bit at gmail.com Mon Oct 17 14:06:34 2011 From: an9bit at gmail.com (=?KOI8-R?B?4c7E0sXKIOTF19HUy8E=?=) Date: Tue Oct 18 01:04:37 2011 Subject: [odb-users] Can't run odb. Message-ID: Hi! Sory, i did not know English. I get and build source code odb. During start-up error: $ odb odb: error: unable to parse profile paths I try odb version 1.6.0 and 1.5.0. I try linux ubuntu 11.10 (kernel 3.0.0.12) x86 and amd64. I try gcc version 4.5.4 and 4.6.1. For 4.6 i modified odb/gcc.hxx line 36 and 37 repaced #include #include to #include #include libcutl, odb, libodb, libodb-boost, libodb-pgsql i configured with next options: ./configure --prefix=/usr/local I have boost-1.46 and postgresql 9.1 Before I used ubuntu 11.04 x86 with postgresql 9.1, boost 1.46, gcc 4.5, odb-1.5.0. It is also build from source code, and all working ok. -- ? ?????????, ?. ?. ???????. (Andrey P. Devyatka) From Brown223 at llnl.gov Mon Oct 17 17:32:46 2011 From: Brown223 at llnl.gov (Brown, Matt C) Date: Tue Oct 18 01:04:37 2011 Subject: [odb-users] install-git bootstrap libodb-qt-1.6.0 fails related to libtool Message-ID: <7F39E40506D65E49930E8330AFF8410401C912CFB166@NSPEXMBX-B.the-lab.llnl.gov> Hello, I've been trying to adapt basic support for google protocol buffers for odb (not relevant, but interesting!). I started with libodb-qt from git, but the basic installation per instructions don't seem to work. I've included a log. I have zero expertise in how the autoconf tools work, but it seems that a number of .m4 files are missing compared to the actual distribution. My guess is there is some implicit step involving configuring libtool (or a system requirement). I have installed 'build' from the codesynthesis site, as well as tofrodos. I'm running Fedora Core 13, which meets all the other requirements listed. I used all the default options during the 'make dist' step. Thanks, Matthew C Brown Lawrence Livermore National Lab []git clone http://scm.codesynthesis.com/odb/libodb-qt.git cd libodb-qt [libodb-qt]$ make dist dist_prefix=/tmp/libodb-qt-1.6.0 configuring 'libodb-qt' Please select the C++ compiler you would like to use: (1) GNU C++ (g++) (2) Intel C++ (icc) (3) Other C++ compiler [1]: Would you like the C++ compiler to optimize generated code? [y]: Would you like the C++ compiler to generate debug information? [y]: Embed dynamic library paths into executables (rpath)? [y]: Please enter any extra C++ preprocessor options. []: Please enter any extra C++ compiler options. []: Please enter any extra C++ linker options. []: Please enter any extra C++ libraries. []: configuring 'libodb-qt' Please select the default library type: (1) archive (2) shared object [2]: Configuring external dependency on 'Qt libraries' for 'libodb-qt'. Would you like to configure dependency on the installed version of 'Qt libraries' as opposed to the development build? [y]: Configuring external dependency on 'libodb' for 'libodb-qt'. Would you like to configure dependency on the installed version of 'libodb' as opposed to the development build? [y]: configuring 'libodb-qt' Please enter the g++ binary you would like to use, for example 'g++-3.4', '/usr/local/bin/g++' or 'distcc g++'. [g++]: Please select the optimization level you would like to use: (1) -O1 [Tries to reduce code size and execution time, without performing any optimizations that take a great deal of compilation time.] (2) -O2 [Performs nearly all supported optimizations that do not involve a space-speed tradeoff.] (3) -O3 [Optimize even more.] (4) -Os [Optimize for size.] [2]: dist /tmp/libodb-qt-1.6.0/odb/qt/date-time/exceptions.cxx dist /tmp/libodb-qt-1.6.0/odb/qt/version.hxx dist /tmp/libodb-qt-1.6.0/odb/qt/containers/qset-traits.hxx dist /tmp/libodb-qt-1.6.0/odb/qt/containers/qlinked-list-traits.hxx dist /tmp/libodb-qt-1.6.0/odb/qt/containers/qhash-traits.hxx dist /tmp/libodb-qt-1.6.0/odb/qt/containers/qmap-traits.hxx dist /tmp/libodb-qt-1.6.0/odb/qt/containers/qvector-traits.hxx dist /tmp/libodb-qt-1.6.0/odb/qt/containers/qlist-traits.hxx dist /tmp/libodb-qt-1.6.0/odb/qt/exception.hxx dist /tmp/libodb-qt-1.6.0/odb/qt/basic/pgsql/qstring-traits.hxx dist /tmp/libodb-qt-1.6.0/odb/qt/basic/pgsql/default-mapping.hxx dist /tmp/libodb-qt-1.6.0/odb/qt/basic/pgsql/qbyte-array-traits.hxx dist /tmp/libodb-qt-1.6.0/odb/qt/basic/sqlite/qstring-traits.hxx dist /tmp/libodb-qt-1.6.0/odb/qt/basic/sqlite/default-mapping.hxx dist /tmp/libodb-qt-1.6.0/odb/qt/basic/sqlite/qbyte-array-traits.hxx dist /tmp/libodb-qt-1.6.0/odb/qt/basic/mysql/qstring-traits.hxx dist /tmp/libodb-qt-1.6.0/odb/qt/basic/mysql/default-mapping.hxx dist /tmp/libodb-qt-1.6.0/odb/qt/basic/mysql/qbyte-array-traits.hxx dist /tmp/libodb-qt-1.6.0/odb/qt/smart-ptr/lazy-pointer-traits.hxx dist /tmp/libodb-qt-1.6.0/odb/qt/smart-ptr/wrapper-traits.hxx dist /tmp/libodb-qt-1.6.0/odb/qt/smart-ptr/lazy-ptr.ixx dist /tmp/libodb-qt-1.6.0/odb/qt/smart-ptr/lazy-ptr.txx dist /tmp/libodb-qt-1.6.0/odb/qt/smart-ptr/pointer-traits.hxx dist /tmp/libodb-qt-1.6.0/odb/qt/smart-ptr/lazy-ptr.hxx dist /tmp/libodb-qt-1.6.0/odb/qt/date-time/pgsql/qtime-traits.hxx dist /tmp/libodb-qt-1.6.0/odb/qt/date-time/pgsql/default-mapping.hxx dist /tmp/libodb-qt-1.6.0/odb/qt/date-time/pgsql/qdate-time-traits.hxx dist /tmp/libodb-qt-1.6.0/odb/qt/date-time/pgsql/qdate-traits.hxx dist /tmp/libodb-qt-1.6.0/odb/qt/date-time/sqlite/qtime-traits.hxx dist /tmp/libodb-qt-1.6.0/odb/qt/date-time/sqlite/default-mapping.hxx dist /tmp/libodb-qt-1.6.0/odb/qt/date-time/sqlite/qdate-time-traits.hxx dist /tmp/libodb-qt-1.6.0/odb/qt/date-time/sqlite/qdate-traits.hxx dist /tmp/libodb-qt-1.6.0/odb/qt/date-time/mysql/qtime-traits.hxx dist /tmp/libodb-qt-1.6.0/odb/qt/date-time/mysql/default-mapping.hxx dist /tmp/libodb-qt-1.6.0/odb/qt/date-time/mysql/qdate-time-traits.hxx dist /tmp/libodb-qt-1.6.0/odb/qt/date-time/mysql/qdate-traits.hxx dist /tmp/libodb-qt-1.6.0/odb/qt/date-time/exceptions.hxx dist /tmp/libodb-qt-1.6.0/odb/qt/lazy-ptr.hxx dist /tmp/libodb-qt-1.6.0/odb/qt/details/export.hxx dist /tmp/libodb-qt-1.6.0/odb/qt/details/config.hxx dist /tmp/libodb-qt-1.6.0/odb/qt/date-time-pgsql.options dist /tmp/libodb-qt-1.6.0/odb/qt/smart-ptr.options dist /tmp/libodb-qt-1.6.0/odb/qt/containers.options dist /tmp/libodb-qt-1.6.0/odb/qt/date-time-mysql.options dist /tmp/libodb-qt-1.6.0/odb/qt/basic-pgsql.options dist /tmp/libodb-qt-1.6.0/odb/qt/version.options dist /tmp/libodb-qt-1.6.0/odb/qt/date-time-sqlite.options dist /tmp/libodb-qt-1.6.0/odb/qt/basic-mysql.options dist /tmp/libodb-qt-1.6.0/odb/qt/basic-sqlite.options dist /tmp/libodb-qt-1.6.0/odb/qt/details/config.h.in meta /tmp/libodb-qt-1.6.0/odb/qt/libodb-qt-vc9.vcproj meta /tmp/libodb-qt-1.6.0/odb/qt/libodb-qt-vc10.vcxproj meta /tmp/libodb-qt-1.6.0/odb/qt/Makefile.am dist /tmp/libodb-qt-1.6.0/GPLv2 dist /tmp/libodb-qt-1.6.0/LICENSE dist /tmp/libodb-qt-1.6.0/README dist /tmp/libodb-qt-1.6.0/NEWS dist /tmp/libodb-qt-1.6.0/version dist /tmp/libodb-qt-1.6.0/odb/qt.options dist /tmp/libodb-qt-1.6.0/INSTALL dist /tmp/libodb-qt-1.6.0/libodb-qt-vc9.sln dist /tmp/libodb-qt-1.6.0/libodb-qt-vc10.sln dist /tmp/libodb-qt-1.6.0/libodb-qt.pc.in dist /tmp/libodb-qt-1.6.0/bootstrap dist /tmp/libodb-qt-1.6.0/m4 meta /tmp/libodb-qt-1.6.0/Makefile.am meta /tmp/libodb-qt-1.6.0/configure.ac [libodb-qt]$ cd /tmp/libodb-qt-1.6.0/ [libodb-qt-1.6.0]$ ./bootstrap configure.ac:16: installing `config/config.guess' configure.ac:16: installing `config/config.sub' configure.ac:12: installing `config/install-sh' configure.ac:12: installing `config/missing' odb/qt/Makefile.am:6: Libtool library used but `LIBTOOL' is undefined odb/qt/Makefile.am:6: The usual way to define `LIBTOOL' is to add `AC_PROG_LIBTOOL' odb/qt/Makefile.am:6: to `configure.ac' and run `aclocal' and `autoconf' again. odb/qt/Makefile.am:6: If `AC_PROG_LIBTOOL' is in `configure.ac', make sure odb/qt/Makefile.am:6: its definition is in aclocal's search path. odb/qt/Makefile.am: installing `config/depcomp' autoreconf: automake failed with exit status: 1 From boris at codesynthesis.com Tue Oct 18 01:37:02 2011 From: boris at codesynthesis.com (Boris Kolpackov) Date: Tue Oct 18 01:36:49 2011 Subject: [odb-users] Can't run odb. In-Reply-To: References: Message-ID: Hi Andrey, ?????? ??????? writes: > During start-up error: > $ odb > odb: error: unable to parse profile paths Hm, this is interesting. Can you show me the output of your GCC (for both 4.5 and 4.6) with the following command line: g++-4.X -v -x c++ -E -P - (Hit Ctrl-D to make g++ exit). > For 4.6 i modified odb/gcc.hxx > line 36 and 37 repaced > #include > #include > to > #include > #include That's a bug in GCC 4.6 that we reported and I believe it is now fixed: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48425 Boris From boris at codesynthesis.com Tue Oct 18 12:14:02 2011 From: boris at codesynthesis.com (Boris Kolpackov) Date: Tue Oct 18 12:13:47 2011 Subject: [odb-users] Can't run odb. In-Reply-To: <4E9D862E.40504@gmail.com> References: <4E9D862E.40504@gmail.com> Message-ID: Hi Andrey, In the future please keep your replies CC'ed to the odb-users mailing list as discussed in the posting guidelines: http://www.codesynthesis.com/support/posting-guidelines.xhtml Andrey Devyatka writes: > On 18.10.2011 11:37, Boris Kolpackov wrote: > >>> During start-up error: >>> > $ odb >>> > odb: error: unable to parse profile paths >> Hm, this is interesting. Can you show me the output of your GCC >> (for both 4.5 and 4.6) with the following command line: >> >> g++-4.X -v -x c++ -E -P - > $ LANG=C g++-4.6 -v -x c++ -E -P - > > Using built-in specs. > > COLLECT_GCC=g++-4.6 > > COLLECT_LTO_WRAPPER=/usr/lib/gcc/i686-linux-gnu/4.6.1/lto-wrapper > > Target: i686-linux-gnu > > Configured with: ../src/configure -v --with-pkgversion='Ubuntu/Linaro 4.6.1-9ubuntu3' --with-bugurl=file:///usr/share/doc/gcc-4.6/README.Bugs --enable-languages=c,c++,fortran,objc,obj-c++,go --prefix=/usr --program-suffix=-4.6 --enable-shared --enable-linker-build-id --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.6 --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-plugin --enable-objc-gc --enable-targets=all --disable-werror --with-arch-32=i686 --with-tune=generic --enable-checking=release --build=i686-linux-gnu --host=i686-linux-gnu --target=i686-linux-gnu > > Thread model: posix > > gcc version 4.6.1 (Ubuntu/Linaro 4.6.1-9ubuntu3) > > COLLECT_GCC_OPTIONS='-v' '-E' '-P' '-shared-libgcc' '-mtune=generic' '-march=i686' > > /usr/lib/gcc/i686-linux-gnu/4.6.1/cc1plus -E -quiet -v -P -imultilib . -imultiarch i386-linux-gnu -D_GNU_SOURCE - -mtune=generic -march=i686 -fstack-protector > > ignoring nonexistent directory "/usr/local/include/i386-linux-gnu" > > ignoring nonexistent directory "/usr/lib/gcc/i686-linux-gnu/4.6.1/../../../../i686-linux-gnu/include" > > #include "..." search starts here: > > #include<...> search starts here: Ok, this line is the problem. On my system I get: #include <...> search starts here: I tried to figure out what's going on here but it looks very bizarre. I checked the GCC source code, and there the string is "#include <...>". I then checked the cc1plus binary from the Ubuntu package that you are using, and there the string is also "#include <...>". One thing that I noticed in the GCC source code is that these strings are translated into various languages and the corresponding translation is loaded at runtime using gettext. Perhaps the string gets messed up at that point. In any case, seeing that this string can be translated, I re-implemented the profile path parsing in a more robust way that should also take care of your problem. I have patched ODB 1.6.0 source code with the fix and prepared a package: http://www.codesynthesis.com/~boris/tmp/odb/odb-1.6.1.tar.bz2 Can you give it a try and let me know if it works for you? If everything works fine then I will make this fix official as ODB 1.6.1. Boris [The rest of the original email follows for context.] > > /usr/include/c++/4.6 > > /usr/include/c++/4.6/i686-linux-gnu/. > > /usr/include/c++/4.6/backward > > /usr/lib/gcc/i686-linux-gnu/4.6.1/include > > /usr/local/include > > /usr/lib/gcc/i686-linux-gnu/4.6.1/include-fixed > > /usr/include/i386-linux-gnu > > /usr/include > > End of search list. > > COMPILER_PATH=/usr/lib/gcc/i686-linux-gnu/4.6.1/:/usr/lib/gcc/i686-linux-gnu/4.6.1/:/usr/lib/gcc/i686-linux-gnu/:/usr/lib/gcc/i686-linux-gnu/4.6.1/:/usr/lib/gcc/i686-linux-gnu/ > > LIBRARY_PATH=/usr/lib/gcc/i686-linux-gnu/4.6.1/:/usr/lib/gcc/i686-linux-gnu/4.6.1/../../../i386-linux-gnu/:/usr/lib/gcc/i686-linux-gnu/4.6.1/../../../../lib/:/lib/i386-linux-gnu/:/lib/../lib/:/usr/lib/i386-linux-gnu/:/usr/lib/../lib/:/usr/lib/gcc/i686-linux-gnu/4.6.1/../../../:/lib/:/usr/lib/ > > COLLECT_GCC_OPTIONS='-v' '-E' '-P' '-shared-libgcc' '-mtune=generic' '-march=i686' > > $ LANG=C g++-4.5 -v -x c++ -E -P - > > Using built-in specs. > > COLLECT_GCC=g++-4.5 > > COLLECT_LTO_WRAPPER=/usr/lib/gcc/i686-linux-gnu/4.5.4/lto-wrapper > > Target: i686-linux-gnu > > Configured with: ../src/configure -v --with-pkgversion='Ubuntu/Linaro 4.5.3-9ubuntu1' --with-bugurl=file:///usr/share/doc/gcc-4.5/README.Bugs --enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-4.5 --enable-shared --enable-linker-build-id --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.5 --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-plugin --enable-gold --enable-ld=default --with-plugin-ld=ld.gold --enable-objc-gc --enable-targets=all --disable-werror --with-arch-32=i686 --with-tune=generic --enable-checking=release --build=i686-linux-gnu --host=i686-linux-gnu --target=i686-linux-gnu > > Thread model: posix > > gcc version 4.5.4 (Ubuntu/Linaro 4.5.3-9ubuntu1) > > COLLECT_GCC_OPTIONS='-v' '-E' '-P' '-shared-libgcc' '-mtune=generic' '-march=i686' > > /usr/lib/gcc/i686-linux-gnu/4.5.4/cc1plus -E -quiet -v -P -imultilib . -imultiarch i386-linux-gnu -D_GNU_SOURCE - -D_FORTIFY_SOURCE=2 -mtune=generic -march=i686 -fstack-protector > > ignoring nonexistent directory "/usr/local/include/i386-linux-gnu" > > ignoring nonexistent directory "/usr/lib/gcc/i686-linux-gnu/4.5.4/../../../../i686-linux-gnu/include" > > #include "..." search starts here: > > #include<...> search starts here: > > /usr/include/c++/4.5 > > /usr/include/c++/4.5/i686-linux-gnu/. > > /usr/include/c++/4.5/backward > > /usr/local/include > > /usr/lib/gcc/i686-linux-gnu/4.5.4/include > > /usr/lib/gcc/i686-linux-gnu/4.5.4/include-fixed > > /usr/include/i386-linux-gnu > > /usr/include > > End of search list. > > COMPILER_PATH=/usr/lib/gcc/i686-linux-gnu/4.5.4/:/usr/lib/gcc/i686-linux-gnu/4.5.4/:/usr/lib/gcc/i686-linux-gnu/:/usr/lib/gcc/i686-linux-gnu/4.5.4/:/usr/lib/gcc/i686-linux-gnu/ > > LIBRARY_PATH=/usr/lib/gcc/i686-linux-gnu/4.5.4/:/usr/lib/gcc/i686-linux-gnu/4.5.4/../../../i386-linux-gnu/:/usr/lib/gcc/i686-linux-gnu/4.5.4/../../../../lib/:/lib/i386-linux-gnu/:/lib/../lib/:/usr/lib/i386-linux-gnu/:/usr/lib/../lib/:/usr/lib/gcc/i686-linux-gnu/4.5.4/../../../:/lib/:/usr/lib/ > > COLLECT_GCC_OPTIONS='-v' '-E' '-P' '-shared-libgcc' '-mtune=generic' '-march=i686' From boris at codesynthesis.com Tue Oct 18 12:22:37 2011 From: boris at codesynthesis.com (Boris Kolpackov) Date: Tue Oct 18 12:22:22 2011 Subject: [odb-users] install-git bootstrap libodb-qt-1.6.0 fails related to libtool In-Reply-To: <7F39E40506D65E49930E8330AFF8410401C912CFB166@NSPEXMBX-B.the-lab.llnl.gov> References: <7F39E40506D65E49930E8330AFF8410401C912CFB166@NSPEXMBX-B.the-lab.llnl.gov> Message-ID: Hi Matt, Brown, Matt C writes: > I've been trying to adapt basic support for google protocol buffers for odb > (not relevant, but interesting!). I started with libodb-qt from git, but > the basic installation per instructions don't seem to work. > > [...] > > odb/qt/Makefile.am:6: Libtool library used but `LIBTOOL' is undefined > odb/qt/Makefile.am:6: The usual way to define `LIBTOOL' is to add `AC_PROG_LIBTOOL' > odb/qt/Makefile.am:6: to `configure.ac' and run `aclocal' and `autoconf' again. > odb/qt/Makefile.am:6: If `AC_PROG_LIBTOOL' is in `configure.ac', make sure > odb/qt/Makefile.am:6: its definition is in aclocal's search path. Hm, looks like you either don't have libtool installed or you are using an incompatible autotools versions combination. I am using: libtool 2.2.6b (libtoolize --version) autoconf 2.67 (autoconf --version) automake 1.11.1 (automake --version) I suggest that you try to get something close to these versions. In particular, I've heard that libtool 2.4 is badly incompatible with 2.2. Boris From Brown223 at llnl.gov Tue Oct 18 12:32:13 2011 From: Brown223 at llnl.gov (Brown, Matt C) Date: Tue Oct 18 15:17:13 2011 Subject: [odb-users] install-git bootstrap libodb-qt-1.6.0 fails related to libtool In-Reply-To: References: <7F39E40506D65E49930E8330AFF8410401C912CFB166@NSPEXMBX-B.the-lab.llnl.gov> Message-ID: <7F39E40506D65E49930E8330AFF8410401C912CFB251@NSPEXMBX-B.the-lab.llnl.gov> Yup, that worked - I figured it was something easy. Maybe you could put in these requirements into the INSTALL-GIT documentation for us newbs? Thanks, -Matt -----Original Message----- From: Boris Kolpackov [mailto:boris@codesynthesis.com] Sent: Tuesday, October 18, 2011 9:23 AM To: Brown, Matt C Cc: odb-users@codesynthesis.com Subject: Re: [odb-users] install-git bootstrap libodb-qt-1.6.0 fails related to libtool Hi Matt, Brown, Matt C writes: > I've been trying to adapt basic support for google protocol buffers for odb > (not relevant, but interesting!). I started with libodb-qt from git, but > the basic installation per instructions don't seem to work. > > [...] > > odb/qt/Makefile.am:6: Libtool library used but `LIBTOOL' is undefined > odb/qt/Makefile.am:6: The usual way to define `LIBTOOL' is to add `AC_PROG_LIBTOOL' > odb/qt/Makefile.am:6: to `configure.ac' and run `aclocal' and `autoconf' again. > odb/qt/Makefile.am:6: If `AC_PROG_LIBTOOL' is in `configure.ac', make sure > odb/qt/Makefile.am:6: its definition is in aclocal's search path. Hm, looks like you either don't have libtool installed or you are using an incompatible autotools versions combination. I am using: libtool 2.2.6b (libtoolize --version) autoconf 2.67 (autoconf --version) automake 1.11.1 (automake --version) I suggest that you try to get something close to these versions. In particular, I've heard that libtool 2.4 is badly incompatible with 2.2. Boris From an9bit at gmail.com Tue Oct 18 13:57:40 2011 From: an9bit at gmail.com (Andrey Devyatka) Date: Tue Oct 18 15:17:13 2011 Subject: [odb-users] Can't run odb. In-Reply-To: References: <4E9D862E.40504@gmail.com> Message-ID: <4E9DBE14.7050109@gmail.com> > Andrey Devyatka writes: > >> On 18.10.2011 11:37, Boris Kolpackov wrote: >> >>>> During start-up error: >>>>> $ odb >>>>> odb: error: unable to parse profile paths >>> Hm, this is interesting. Can you show me the output of your GCC >>> (for both 4.5 and 4.6) with the following command line: >>> >>> g++-4.X -v -x c++ -E -P - >> $ LANG=C g++-4.6 -v -x c++ -E -P - >> >> Using built-in specs. >> >> COLLECT_GCC=g++-4.6 >> >> COLLECT_LTO_WRAPPER=/usr/lib/gcc/i686-linux-gnu/4.6.1/lto-wrapper >> >> Target: i686-linux-gnu >> >> Configured with: ../src/configure -v --with-pkgversion='Ubuntu/Linaro 4.6.1-9ubuntu3' --with-bugurl=file:///usr/share/doc/gcc-4.6/README.Bugs --enable-languages=c,c++,fortran,objc,obj-c++,go --prefix=/usr --program-suffix=-4.6 --enable-shared --enable-linker-build-id --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.6 --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-plugin --enable-objc-gc --enable-targets=all --disable-werror --with-arch-32=i686 --with-tune=generic --enable-checking=release --build=i686-linux-gnu --host=i686-linux-gnu --target=i686-linux-gnu >> >> Thread model: posix >> >> gcc version 4.6.1 (Ubuntu/Linaro 4.6.1-9ubuntu3) >> >> COLLECT_GCC_OPTIONS='-v' '-E' '-P' '-shared-libgcc' '-mtune=generic' '-march=i686' >> >> /usr/lib/gcc/i686-linux-gnu/4.6.1/cc1plus -E -quiet -v -P -imultilib . -imultiarch i386-linux-gnu -D_GNU_SOURCE - -mtune=generic -march=i686 -fstack-protector >> >> ignoring nonexistent directory "/usr/local/include/i386-linux-gnu" >> >> ignoring nonexistent directory "/usr/lib/gcc/i686-linux-gnu/4.6.1/../../../../i686-linux-gnu/include" >> >> #include "..." search starts here: >> >> #include<...> search starts here: > Ok, this line is the problem. On my system I get: > > #include<...> search starts here: > > I tried to figure out what's going on here but it looks very bizarre. > I checked the GCC source code, and there the string is "#include<...>". > I then checked the cc1plus binary from the Ubuntu package that you are > using, and there the string is also "#include<...>". One thing that > I noticed in the GCC source code is that these strings are translated > into various languages and the corresponding translation is loaded at > runtime using gettext. Perhaps the string gets messed up at that point. > > In any case, seeing that this string can be translated, I re-implemented > the profile path parsing in a more robust way that should also take care > of your problem. I have patched ODB 1.6.0 source code with the fix and > prepared a package: > > http://www.codesynthesis.com/~boris/tmp/odb/odb-1.6.1.tar.bz2 > > Can you give it a try and let me know if it works for you? If everything > works fine then I will make this fix official as ODB 1.6.1. > > Boris Hi Boris, I tried it. Everything works fine with g++-4.5 (i386, amd64) and g++-4.6 (i386, amd64). Thank you very much! From boris at codesynthesis.com Wed Oct 19 06:38:07 2011 From: boris at codesynthesis.com (Boris Kolpackov) Date: Wed Oct 19 06:37:47 2011 Subject: [odb-users] ODB compiler source 1.6.1 bugfix released Message-ID: Hi, A bugfix release for the ODB compiler source package version 1.6.0 is now available. It fixes an issue with profile path parsing in some GCC builds. You only need to upgrade if (1) you have built the ODB compiler from source code yourself (as opposed to using a binary package) and (2) you are experiencing the profile path parsing problem ("unable to parse profile paths" error when running the ODB compiler). For more information on this issue, refer to the following mailing list thread: http://www.codesynthesis.com/pipermail/odb-users/2011-October/000342.html You can download the package from the ODB download page: http://www.codesynthesis.com/products/odb/download.xhtml SHA1 checksums for the files in this release are as follows: a47bd04dea968a852700310f8a6e560efb1eb244 odb-1.6.1.tar.bz2 1ccc57246c9410bced0f4ea6e64b50cf05a2cf52 odb-1.6.1.tar.gz 267a901723956f600102ac5738ef7ad76187da15 odb-1.6.1.zip Boris From boris at codesynthesis.com Wed Oct 19 08:21:25 2011 From: boris at codesynthesis.com (Boris Kolpackov) Date: Wed Oct 19 08:21:16 2011 Subject: [odb-users] install-git bootstrap libodb-qt-1.6.0 fails related to libtool In-Reply-To: <7F39E40506D65E49930E8330AFF8410401C912CFB251@NSPEXMBX-B.the-lab.llnl.gov> References: <7F39E40506D65E49930E8330AFF8410401C912CFB166@NSPEXMBX-B.the-lab.llnl.gov> <7F39E40506D65E49930E8330AFF8410401C912CFB251@NSPEXMBX-B.the-lab.llnl.gov> Message-ID: Hi Matt, Brown, Matt C writes: > Maybe you could put in these requirements into the INSTALL-GIT > documentation for us newbs? Done, thanks for the suggestion. Boris From boris at codesynthesis.com Thu Oct 20 09:05:00 2011 From: boris at codesynthesis.com (Boris Kolpackov) Date: Thu Oct 20 09:04:34 2011 Subject: [odb-users] Re: Accessing ODB database from other languages In-Reply-To: References: <9B7CB52192C7EA4C931088F28A51177C011DB49E9C80@hermelin.estos.de> <9B7CB52192C7EA4C931088F28A51177C011DB5495646@hermelin.estos.de> Message-ID: Hi Raphael, Raphael Bossek writes: > In the meantime the question came up, if it will be big effort to > access the database created by ODB using LINQ in C#. We do not know > how ODB manage the DB and we would like to CRUD access the database > from other programming environments too. Is there any guidelines we > should read and apply for our design? I don't see any problem with this. ODB supports two modes of operation when it comes to the relational database management. You can either ask ODB to generate the database schema automatically from persistent classes or you can create the database schema manually and then map your persistent classes to corresponding tables, data members to columns, and C++ types to SQL types. In the first mode, ODB will generated what we call a "canonical" schema for your C++ model. This schema will be pretty close to what an experienced database model designer would write by hand. In the second mode you create the schema yourself so you have full control over how the database will look. So in both cases there shouldn't be any problem in accessing the data from another programming environment since most ORM frameworks/libraries are designed to work with custom schemas. Boris From Brown223 at llnl.gov Thu Oct 20 14:04:27 2011 From: Brown223 at llnl.gov (Brown, Matt C) Date: Fri Oct 21 04:24:23 2011 Subject: [odb-users] possible solution to 'friend' declaration, pragma setters and getters Message-ID: <7F39E40506D65E49930E8330AFF8410401C91675CA7F@NSPEXMBX-B.the-lab.llnl.gov> As I understand it, you can full odb-ilize any object fully from outside of it using pragmas with one giant horrible exception, the requirement that it be made a friend of odb::access, and one slightly smaller requirement that it have a default constructor (which, due to friendship, can remain private). One solution (it's very much a Boris does more work type solution), would be to all specification of setter and getter functions (and construction) in the pragma language. So, for instance take the following example coded up in the standard odb manner: //Foo.h #include //**** #pragma db object //**** class Foo { explicit Foo(int id); void set_val(int v) {val_ = v;} int val() const {return val_;} void set_id(int v) {id_ = v;} int id() const {return id_;} private: friend class odb::access;//**** Foo(){}//**** #pragma db id auto//**** int id_; int val_; }; And again with as odb-less as we can get at the moment: //Foo.h #include //**** class Foo { explicit Foo(int id); void set_val(int v) {val_ = v;} int val() const {return val_;} void set_id(int v) {id_ = v;} int id() const {return id_;} private: friend class odb::access;//**** Foo(){}//**** int id_; int val_; }; //Foo.oxx #pragma db object(Foo) #pragma db member(Foo::id_) id auto #pragma db member(Foo::val_) What I'm proposing would be something like the following: //Foo.h class Foo { explicit Foo(int id); void set_val(int v) {val_ = v;} int val() const {return val_;} void set_id(int v) {id_ = v;} int id() const {return id_;} private: Foo(){}// don't allow default constructor int id_; int val_; }; //Foo.oxx #pragma db object(Foo) construct(Foo(id))... ) #pragma db member(Foo::id_) set(set_id) get(id) id auto #pragma db member(Foo::val_) set(set_val) get(val) Looking at the way code is generated, it should be possible to do something like this. There are of course lots and lots and lots of details in adding this feature. I obviously left the 'construct' case ambiguous. And there are plenty of more complicated cases (for instance, what if there is a set_all(int id, int val) function, and you want to somehow use that). But, I think providing basic support would be a great leap forward in flexibility. From the ODB documentation: "It does not dictate how you should write your application. Rather, it is designed to fit into your style and architecture by only handling object persistence and not interfering with any other functionality". Currently it restricts what object you're allow make persistent, a major source of sadness. In case you're curious, I'm trying to mash-up google protocol buffers and odb. Protobuf also uses code generation. While it is probably possible to modify its code generator to include the necessary odb hooks (i.e. friend declaration, pragmas, etc). I'd rather not go mucking about in their code. However, they DO have a plug-in interface that makes it easy to create an separate #pragma file, and all the hard-core low level template meta stuff to hook it into odb (i.e. template specializations for odb::sqlite::default_value_traits {...}). But it required me to learn a lot about how the template underpinnings of odb work, and so far I'm just treating them as opaque blobs. I don't want to think about what would be required to actually break out the individual members from the protobufs. But, with the addition of the setter/getting pragma thing, it would be pretty trivial to do the full-blown mash-up. In general, I think adding this feature would make it MUCH simpler to add 'native' support for new 3rd-party types. For instance, if I wanted to add support for something like QRect (a simple rectangle class from qt), right now I'd have to go write a specialization for each database type, and teach odb how to find it (i.e. options files). With this feature, you can just include the QRect-odb.hxx file, which would just be about 5 pragmas, and would work regardless of db. I get that this is a pretty involved feature, but right now it's out of reach for many programmers to add support for 3rd-party types. -Matt b.t.w. I've only been playing with odb for about 2 weeks, and I didn't do a rigorous search of the mailing lists to see if this has been discussed. So I greatly apologize if there is already a solution to this problem. From boris at codesynthesis.com Fri Oct 21 06:08:28 2011 From: boris at codesynthesis.com (Boris Kolpackov) Date: Fri Oct 21 06:07:58 2011 Subject: [odb-users] possible solution to 'friend' declaration, pragma setters and getters In-Reply-To: <7F39E40506D65E49930E8330AFF8410401C91675CA7F@NSPEXMBX-B.the-lab.llnl.gov> References: <7F39E40506D65E49930E8330AFF8410401C91675CA7F@NSPEXMBX-B.the-lab.llnl.gov> Message-ID: Hi Matt, Brown, Matt C writes: > #pragma db object(Foo) construct(Foo(id))... ) > #pragma db member(Foo::id_) set(set_id) get(id) id auto > #pragma db member(Foo::val_) set(set_val) get(val) Yes, we have plans to support something like this. The current name for this feature is "virtual member": I have described the basic idea behind virtual members in this post: http://www.codesynthesis.com/pipermail/odb-users/2011-August/000243.html Though the default-construction idea is new. > I obviously left the 'construct' case ambiguous. The construct pragma would most likely provide an expression that would be equivalent to default-construction. So, in your case, it would be: #pragma db object(Foo) construct(Foo (0)) Though it may be useful to allow passing the object id, e.g.: #pragma db object(Foo) construct(Foo (?)) > And there are plenty of more complicated cases (for instance, what if > there is a set_all(int id, int val) function, and you want to somehow > use that). Supporting something like this would be difficult since we would first need to extract all the data members and then pass them in one go to the initialization function. What we could do instead is to allow the user to extract the data into a temporary that can then be used to initialize the object. For example: struct FooData { int id; int val; }; // If a temporary is used, then in the 'construct' and 'set' pragmas, // 'this' refers to the temporary, not the object. // #pragma db object(Foo) temporary(FooData) construct(Foo (this->id, this->val)) #pragma db member(Foo::id_) set(this->id) get(this->id ()) id auto #pragma db member(Foo::val_) set(this->val) get(this->val ()) Though, as you can see, this complicates things significantly, so I am not sure we should support this. > In case you're curious, I'm trying to mash-up google protocol buffers and > odb. Protobuf also uses code generation. While it is probably possible to > modify its code generator to include the necessary odb hooks (i.e. friend > declaration, pragmas, etc). If I remember correctly, last time I checked, generated protobuffer objects all had default c-tors and public data members. I believe some folks are successfully using ODB with protobuffers by simply adding pragmas out-of- class manually. > In general, I think adding this feature would make it MUCH simpler to add > 'native' support for new 3rd-party types. Yes, I agree. > For instance, if I wanted to add support for something like QRect (a simple > rectangle class from qt), right now I'd have to go write a specialization > for each database type, and teach odb how to find it (i.e. options > files). You can only use this approach if you can squeeze QRect into a single database column (the value_traits templates are there to add support for new simple (i.e., single-column) values). I think QRect will be more naturally mapped to a composite value, for which you would need the virtual member feature. Boris From past0004 at stud.fh-kl.de Mon Oct 24 13:43:20 2011 From: past0004 at stud.fh-kl.de (Pascal Stoll) Date: Mon Oct 24 13:43:39 2011 Subject: [odb-users] Qt BLOB Support Message-ID: Hello, i have a problem with the BLOB support of QByteArray. I've created a Pixmap, convert it to an a QbByteArray and add it to my database. Everything works fine until this point. The BLOB is not empty. But when i try to get the information out of the database (via the getter) the QByteArray is always empty. All other informations from this table works fine. I hope you can help me. Best regards. From boris at codesynthesis.com Mon Oct 24 15:57:27 2011 From: boris at codesynthesis.com (Boris Kolpackov) Date: Mon Oct 24 15:57:06 2011 Subject: [odb-users] Qt BLOB Support In-Reply-To: References: Message-ID: Hi Pascal, Pascal Stoll writes: > i have a problem with the BLOB support of QByteArray. I've created a > Pixmap, convert it to an a QbByteArray and add it to my database. Everything > works fine until this point. The BLOB is not empty. But when i try to get > the information out of the database (via the getter) the QByteArray is > always empty. I am not sure what it could be. We have a test in odb-tests which checks QByteArray and everything works fine for all the supported databases, as far as we can see. There is also the qt example in the odb-examples package which also uses QByteArray to store binary information. You may want to check it to see whether it works for you or if you are doing something different. Finally, if none of the above help, I can take a look at this if you can send me a small test case that reproduces the problem. Boris From past0004 at stud.fh-kl.de Tue Oct 25 06:36:06 2011 From: past0004 at stud.fh-kl.de (Pascal Stoll) Date: Tue Oct 25 06:36:24 2011 Subject: [odb-users] Qt BLOB Support Message-ID: Oh i saw one main difference. Do i have to use all the QSharedPointers/qt lazy pointer? I was using the boost ones. Could that be the problem? Best regards ________________________________________ Von: Boris Kolpackov [boris@codesynthesis.com] Gesendet: Montag, 24. Oktober 2011 21:57 Bis: Pascal Stoll Cc: odb-users@codesynthesis.com Betreff: Re: [odb-users] Qt BLOB Support Hi Pascal, Pascal Stoll writes: > i have a problem with the BLOB support of QByteArray. I've created a > Pixmap, convert it to an a QbByteArray and add it to my database. Everything > works fine until this point. The BLOB is not empty. But when i try to get > the information out of the database (via the getter) the QByteArray is > always empty. I am not sure what it could be. We have a test in odb-tests which checks QByteArray and everything works fine for all the supported databases, as far as we can see. There is also the qt example in the odb-examples package which also uses QByteArray to store binary information. You may want to check it to see whether it works for you or if you are doing something different. Finally, if none of the above help, I can take a look at this if you can send me a small test case that reproduces the problem. Boris From boris at codesynthesis.com Tue Oct 25 08:00:58 2011 From: boris at codesynthesis.com (Boris Kolpackov) Date: Tue Oct 25 08:00:40 2011 Subject: [odb-users] Qt BLOB Support In-Reply-To: References: Message-ID: Hi Pascal, Pascal Stoll writes: > Oh i saw one main difference. Do i have to use all the QSharedPointers/qt > lazy pointer? I was using the boost ones. Could that be the problem? No, the kind of pointers you use should be irrelevant. I suggest that you try this with a very simple, stand-alone test. For example, define a persistent class like this: #include #pragma db object struct test { #pragma db id unsigned long id; QByteArray data; }; And try to store it in the database and then load it back: test o1; o1.id = 1; o1.data = QByteArray ("\0xF1\0x00\0x34\0x45\0x00\0xDE", 6); { transaction t (db->begin ()); db->persist (o1); t.commit (); } test o2; { transaction t (db->begin ()); db->load (1, o2); t.commit (); } assert (o1.data == o2.data); If this test works for you, then you need to see what is different about your code. If the test doesn't work, then I will need more information about your setup (OS, C++ compiler, database you are using, ODB version, Qt version) so that I can try and reproduce this. Boris From past0004 at stud.fh-kl.de Wed Oct 26 09:41:22 2011 From: past0004 at stud.fh-kl.de (Pascal Stoll) Date: Wed Oct 26 09:41:46 2011 Subject: AW: [odb-users] Qt BLOB Support In-Reply-To: References: , Message-ID: Sry for the late response, but there where some other stuff to do first. I made your test. The assert does nothing, but ich checked the size of both values. o1.data.size() was 6 and o2.data.size 0. So same problem. It writes the blob correct into the database, but when i try to read it out, it is always null. ________________________________________ Von: Boris Kolpackov [boris@codesynthesis.com] Gesendet: Dienstag, 25. Oktober 2011 14:00 Bis: Pascal Stoll Cc: odb-users@codesynthesis.com Betreff: Re: [odb-users] Qt BLOB Support Hi Pascal, Pascal Stoll writes: > Oh i saw one main difference. Do i have to use all the QSharedPointers/qt > lazy pointer? I was using the boost ones. Could that be the problem? No, the kind of pointers you use should be irrelevant. I suggest that you try this with a very simple, stand-alone test. For example, define a persistent class like this: #include #pragma db object struct test { #pragma db id unsigned long id; QByteArray data; }; And try to store it in the database and then load it back: test o1; o1.id = 1; o1.data = QByteArray ("\0xF1\0x00\0x34\0x45\0x00\0xDE", 6); { transaction t (db->begin ()); db->persist (o1); t.commit (); } test o2; { transaction t (db->begin ()); db->load (1, o2); t.commit (); } assert (o1.data == o2.data); If this test works for you, then you need to see what is different about your code. If the test doesn't work, then I will need more information about your setup (OS, C++ compiler, database you are using, ODB version, Qt version) so that I can try and reproduce this. Boris From boris at codesynthesis.com Wed Oct 26 10:16:58 2011 From: boris at codesynthesis.com (Boris Kolpackov) Date: Wed Oct 26 10:16:32 2011 Subject: [odb-users] Qt BLOB Support In-Reply-To: References: Message-ID: Hi Pascal, Pascal Stoll writes: > The assert does nothing, but ich checked the size of both values. > o1.data.size() was 6 and o2.data.size 0. So same problem. It writes > the blob correct into the database, but when i try to read it out, > it is always null. I will need more information about your setup in order to try to reproduce this problem. In particular: * Operating system * C++ compiler/version * Database/version * ODB version * Qt version (if using) * Boost version (if using) Boris From kontakt at msnoch.pl Wed Oct 26 14:39:29 2011 From: kontakt at msnoch.pl (=?UTF-8?B?TWljaGHFgiBTbm9jaA==?=) Date: Wed Oct 26 14:39:38 2011 Subject: [odb-users] Cannot create schema Message-ID: <4EA853E1.8000201@msnoch.pl> Hi I have weird issue. Everything worked fine until now. I have 3 model structs, departure.h: #include #include namespace Core { namespace Model { enum DepartureType{ Normal, Saturday, FreeDay }; #pragma db object struct Departure { friend class odb::access; #pragma db id auto unsigned int id; QTime arrival; DepartureType type; }; } // namespace Model } // namespace Core connection.h #include #include "node.h" #include "departure.h" #include #include #include namespace Core { namespace Model { typedef int Weight; #pragma db object struct Connection { friend class odb::access; #pragma db id auto unsigned int id; boost::shared_ptr start; boost::shared_ptr stop; Weight weight; QString name; short variation; QVector > departures; }; } // namespace Model } // namespace Core and node.h: #include #include namespace Core { namespace Model { typedef unsigned int NodeId; #pragma db object struct Node { friend class odb::access; Node() : lat(0.0f), lon(0.0f), id(0) {} #pragma db id auto NodeId id; QString m_street, m_name; float lat; float lon; }; } // namespace Model } // namespace Core and when I'm trying to create schema via transaction t1(db->begin()); odb::schema_catalog::create_schema (*db); t1.commit(); I'm getting error that Node already exists 42P07: ERROR: relation "Node" already exists When I'm generating sql files and executing them by myself everything is ok. Of course there is no Node table in db when I'm doing that. What should I do? Thanks Michal From boris at codesynthesis.com Thu Oct 27 06:22:18 2011 From: boris at codesynthesis.com (Boris Kolpackov) Date: Thu Oct 27 06:22:03 2011 Subject: [odb-users] Cannot create schema In-Reply-To: <4EA853E1.8000201@msnoch.pl> References: <4EA853E1.8000201@msnoch.pl> Message-ID: Hi Micha?, Micha? Snoch writes: > and when I'm trying to create schema via > > transaction t1(db->begin()); > odb::schema_catalog::create_schema (*db); > t1.commit(); > > I'm getting error that Node already exists > > 42P07: ERROR: relation "Node" already exists > > > When I'm generating sql files and executing them > by myself everything is ok. Of course there is no > Node table in db when I'm doing that. It seems that for some reason the code that creates the table is called more than once. With embedded (into C++) schema, ODB uses static initialization to register functions that must be called during the schema creation. So the first step in understanding what's going on is to set a breakpoint in such a function for the Node class and see how many times it is called and by whom. Search for CREATE TABLE \"Node in node-odb.cxx to find the place. Note that this function is supposed to be called multiple times. First to drop tables, and then to create them. It is also possible that it will be called multiple times for each of these two steps as part of a multi-pass process. However, it should never be called more than once with the same pass number (second argument) and the drop flag (third argument). Let us know what you find. Boris From nara at bvinetworks.com Thu Oct 27 20:08:56 2011 From: nara at bvinetworks.com (SS Narayanan) Date: Thu Oct 27 20:09:07 2011 Subject: [odb-users] Is there a way to persist an object to a specific table? Message-ID: <006e01cc9505$c97cdbc0$5c769340$@bvinetworks.com> Hi All, I wanted to learn if there is a way to persist and object to a specific table instead of the name of the table as the name of the object. For example, if I have a class named person, I will do something similar to the following: person john("John", "Doe", 33); transaction t (db->begin()); db->persist(john); t.commit(); The record is added to the table "person" in the DB. What is the way to add the person record to another table, say "MyPerson"? And how do I create the new table programmatically. Thanks - Nara From ekimka at gmail.com Fri Oct 28 00:58:39 2011 From: ekimka at gmail.com (Konstantin Mikhailov) Date: Fri Oct 28 00:59:07 2011 Subject: [odb-users] lastval as primary key of the newly inserted entity returns wrong value Message-ID: It looks like the odb trying to use lastval posgresql function call (odb\pgsql\statement.cxx, l. 485) to obtain the primary key value of the newly inserted entity when using id with auto pragma. In case of any triggers involved into entity insertion (for example audit triggers which can insert an audit record in different table(s)) and accessing another (or even the same sequence used to generate primary key) the odb behaviour can lead to very big problem. It returns and assign to the persistent object wrong id. The only workaround in the current version (1.6.0) - do not use the auto pragma with id column if you have the triggers. From boris at codesynthesis.com Fri Oct 28 02:42:28 2011 From: boris at codesynthesis.com (Boris Kolpackov) Date: Fri Oct 28 02:42:26 2011 Subject: [odb-users] Qt BLOB Support In-Reply-To: References: Message-ID: Hi Pascal, In the future please keep your replies CC'ed to the odb-users mailing list as discussed in the posting guidelines: http://www.codesynthesis.com/support/posting-guidelines.xhtml Pascal Stoll writes: > Windows 7 Professional > Visual Studio Professional 2008 > XAMPP 1.7.7 { > Apache 2.2.21 > MySQL 5.5.16 > PHP 5.3.8 > phpMyAdmin 3.4.5 > FileZilla FTP Server 0.9.39 > Tomcat 7.0.21 (with mod_proxy_ajp as connector) > } > Qt 4.5.3 (i used the libs which where included with Maya2008) > Boost 1.43.0 I assume you are using ODB 1.6.0, correct? I also assume you ran ODB with the -p qt (or --profile qt) option. > One thing is, i had to bind odb_mysql against a normal mysql server > installation, because the libs from xampp weren't working. It was > MySQL Community Server 5.5.17 Can you be more specific? What exactly didn't work? In any case I tried to reproduce this without any luck. I tried all of these combinations: 5.1 client libs -> 5.1 server 5.1 client libs -> 5.5 server 5.5 client libs -> 5.1 server 5.5 client libs -> 5.5 server Everything works without any issues. All the tests in the test suite pass, including the one that checks the QByteArray to BLOB mapping. At this point I would need your help to try and figure out what's going on. Can you run the test we talked about earlier under the VC++ debugger and set a breakpoint in libodb-qt/odb/qt/basic/mysql/qbyte-array-traits.hxx inside the set_value() function. In particular, can you check the values of the 'is_null' and 'n' arguments? The first one should be false and the second should be the number of bytes in the BLOB. Boris From ekimka at gmail.com Fri Oct 28 02:50:24 2011 From: ekimka at gmail.com (Konstantin Mikhailov) Date: Fri Oct 28 02:50:50 2011 Subject: [odb-users] Re: lastval as primary key of the newly inserted entity returns wrong value In-Reply-To: References: Message-ID: Unfortunatelly we must use audit triggers and have no chance to switch to the different orm. So, after digging a sources we invent a quick workaround (please note -- we're using the 'id' of type bigint in all our tables as primary key - so the returning clause is hardcoded). --- statement.cxx.orig 2011-10-28 11:23:44.626672918 +0600 +++ statement.cxx 2011-10-28 11:41:54.622687716 +0600 @@ -443,7 +443,7 @@ size_t types_count, binding& data, native_binding& native_data) - : statement (conn, name, stmt, types, types_count), + : statement (conn, name, stmt + " returning id", types, types_count), data_ (data), native_data_ (native_data), id_cached_ (false) @@ -481,6 +481,10 @@ translate_error (conn_, h); } + id_ = endian_traits::ntoh (*reinterpret_cast ( + PQgetvalue (h, 0, 0))); + id_cached_ = true; + return true; } On Fri, Oct 28, 2011 at 10:58 AM, Konstantin Mikhailov wrote: > It looks like the odb trying to use lastval posgresql function call > (odb\pgsql\statement.cxx, l. 485) to obtain the primary key value > of the newly inserted entity when using id with auto pragma. > > In case of any triggers involved into entity insertion (for example audit > triggers which can insert an audit record in different table(s)) and > accessing another (or even the same sequence used to generate > primary key) the odb behaviour can lead to very big problem. It > returns and assign to the persistent object wrong id. > > The only workaround in the current version (1.6.0) - do not use the > auto pragma with id column if you have the triggers. > > From boris at codesynthesis.com Fri Oct 28 04:08:13 2011 From: boris at codesynthesis.com (Boris Kolpackov) Date: Fri Oct 28 04:08:09 2011 Subject: [odb-users] Qt BLOB Support In-Reply-To: References: Message-ID: Hi Pascal, Ok, I am pretty sure I found the problem. In the init_value() function I mentioned earlier we use QByteArray::replace() function which has many overloads. The one that we want apparently was only added in Qt 4.7. Unfortunately, in earlier Qt versions, this didn't result in a compile error but rather in another overload being used silently. Predictably, that overload didn't do what we needed. I have fixed this and prepared the libodb-qt-1.6.1 and odb-1.6.1-i686- windows packages for you to try: http://codesynthesis.com/~boris/tmp/odb/libodb-qt-1.6.1.zip http://codesynthesis.com/~boris/tmp/odb/odb-1.6.1-i686-windows.zip You don't need to rebuild libodb or libodb-mysql packages. Just get the above two, build libodb-qt, and recompile your headers with the new ODB compiler. Let me know if this works for you and I will make this bug fix official. Boris From boris at codesynthesis.com Fri Oct 28 05:24:31 2011 From: boris at codesynthesis.com (Boris Kolpackov) Date: Fri Oct 28 05:24:26 2011 Subject: [odb-users] Re: lastval as primary key of the newly inserted entity returns wrong value In-Reply-To: References: Message-ID: Hi Konstantin, Konstantin Mikhailov writes: > So, after digging a sources we invent a quick workaround (please note -- > we're using the 'id' of type bigint in all our tables as primary key - > so the returning clause is hardcoded). Yes, the RETURNING clause is probably the best way to solve this. We are already using this technique for the upcoming Oracle support which doesn't have anything like lastval. So I went ahead and implemented it for PostgreSQL as well. If you are interested, the changes are here: http://scm.codesynthesis.com/?p=odb/libodb-pgsql.git;a=commit;h=f3e83073310e5fbafb142bb8d3cd1b03ed6088e9 http://scm.codesynthesis.com/?p=odb/odb.git;a=commit;h=1e5d1211d09c1f50921aa45d8c776be3758a6d89 This fix will appear in the upcoming 1.7.0. We are also planning to make a pre-release in the next week or two, so you can test it there if you would like. Thanks for reporting this and suggesting the fix! Boris From boris at codesynthesis.com Fri Oct 28 09:28:14 2011 From: boris at codesynthesis.com (Boris Kolpackov) Date: Fri Oct 28 09:28:15 2011 Subject: [odb-users] Is there a way to persist an object to a specific table? In-Reply-To: <006e01cc9505$c97cdbc0$5c769340$@bvinetworks.com> References: <006e01cc9505$c97cdbc0$5c769340$@bvinetworks.com> Message-ID: Hi Narayanan, SS Narayanan writes: > I wanted to learn if there is a way to persist and object to a specific > table instead of the name of the table as the name of the object. For > example, if I have a class named person, I will do something similar to the > following: > > person john("John", "Doe", 33); > > transaction t (db->begin()); > > db->persist(john); > > t.commit(); > > The record is added to the table "person" in the DB. What is the way to add > the person record to another table, say "MyPerson"? And how do I create the > new table programmatically. I see three ways to interpret your question: 1. If you need to change the name of the table in which the person objects are stored, then this one is easy. You simply use the table pragma, for example: #pragma db object table("MyPerson") class person { ... }; The MyPerson table will be created automatically. 2. If you have a few tables where you may need to store the person objects and the names of these tables are known at compile time, then this is a bit more complex. You can do it by creating a persistent class for each table. To avoid duplicating the code, you can factor all the data members to out to the abstract base class. For example: #pragma db object abstract class person { ... }; #pragma db object table("MyPerson") class my_person: public person { }; #pragma db object table("YourPerson") class your_person: public person { }; The MyPerson and YourPerson tables will be created automatically. 3. Finally, if you only know the names of the tables where you need to store the person objects at run-time, then there is currently no way to handle this case in ODB. The names of the tables are embedded in the statements generated for each persistent class and the statements themselves are prepared and cached. Providing a table name at run- time would make it a lot less efficient. The only workaround for this case that I can think of would be to dynamically create a table alias using a native SQL statement. As far as I know, only DB/2 provides something like this (see CREATE ALIAS). Boris From kontakt at msnoch.pl Sat Oct 29 07:20:49 2011 From: kontakt at msnoch.pl (=?UTF-8?B?TWljaGHFgiBTbm9jaA==?=) Date: Sat Oct 29 07:20:59 2011 Subject: [odb-users] Cannot create schema In-Reply-To: References: <4EA853E1.8000201@msnoch.pl> Message-ID: <4EABE191.50704@msnoch.pl> Hi Boris, I checked if my method is called more than once, but unfortunately it is called once only. I'm now using 1.6 version of ODB. In earlier versions everything was ok. Michal W dniu 27.10.2011 12:22, Boris Kolpackov pisze: > Hi Micha?, > > Micha? Snoch writes: > >> and when I'm trying to create schema via >> >> transaction t1(db->begin()); >> odb::schema_catalog::create_schema (*db); >> t1.commit(); >> >> I'm getting error that Node already exists >> >> 42P07: ERROR: relation "Node" already exists >> >> >> When I'm generating sql files and executing them >> by myself everything is ok. Of course there is no >> Node table in db when I'm doing that. > It seems that for some reason the code that creates the table is > called more than once. With embedded (into C++) schema, ODB uses > static initialization to register functions that must be called > during the schema creation. So the first step in understanding > what's going on is to set a breakpoint in such a function for the > Node class and see how many times it is called and by whom. Search > for CREATE TABLE \"Node in node-odb.cxx to find the place. > > Note that this function is supposed to be called multiple times. > First to drop tables, and then to create them. It is also possible > that it will be called multiple times for each of these two steps > as part of a multi-pass process. However, it should never be called > more than once with the same pass number (second argument) and the > drop flag (third argument). > > Let us know what you find. > > Boris -- Micha? Snoch From amr.ali.cc at gmail.com Sat Oct 29 17:11:53 2011 From: amr.ali.cc at gmail.com (Amr Ali) Date: Sat Oct 29 17:12:14 2011 Subject: [odb-users] odb/gcc.hxx incorrect file includes Message-ID: <4EAC6C19.3090105@gmail.com> Boris; Under your ODB compiler v1.6.1 source package there's mis-included file under odb/gcc.hxx ... 36 #include 37 #include ... These include statements should be like (below) at least to work properly for GCC v4.6.1 x86_64 ... 36 #include 37 #include ... Thanks. -- Amr Ali -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: OpenPGP digital signature Url : http://codesynthesis.com/pipermail/odb-users/attachments/20111029/d083c994/signature.pgp From boris at codesynthesis.com Mon Oct 31 07:43:31 2011 From: boris at codesynthesis.com (Boris Kolpackov) Date: Mon Oct 31 07:44:13 2011 Subject: [odb-users] Is there a way to persist an object to a specific table? In-Reply-To: <011301cc95a2$9a117e20$ce347a60$@bvinetworks.com> References: <006e01cc9505$c97cdbc0$5c769340$@bvinetworks.com> <011301cc95a2$9a117e20$ce347a60$@bvinetworks.com> Message-ID: Hi Narayanan, In the future please keep your replies CC'ed to the odb-users mailing list as discussed in the posting guidelines: http://www.codesynthesis.com/support/posting-guidelines.xhtml SS Narayanan writes: > Thanks for your prompt response. We are indeed looking for option 3 in your > reply. We would like to create tables at runtime and then add/delete objects > into the newly created tables. We know the object details at compile time. > We want to be able to add these objects to dynamically created tables at > runtime for easily dropping the table at a later time, instead of running a > query on millions of records and deleting only those records that are needed > at runtime. > > Do you have any plans of adding this support? It is unlikely we will add support for this in foreseeable future. It will complicate ODB significantly and make the mapping much less efficient while being a fairly unusual requirement. > Or is there an alternate way to do the same? I think your best bet is to look for database-specific features that would allow you to implement this (like the CREATE ALIAS in DB2) or overcome the need for it (e.g., find a way to use a single table to store all objects). For example, instead of storing objects in different tables, you could store them in the same tables but in different databases. Boris From boris at codesynthesis.com Mon Oct 31 09:24:45 2011 From: boris at codesynthesis.com (Boris Kolpackov) Date: Mon Oct 31 09:25:28 2011 Subject: [odb-users] Cannot create schema In-Reply-To: <4EABE191.50704@msnoch.pl> References: <4EA853E1.8000201@msnoch.pl> <4EABE191.50704@msnoch.pl> Message-ID: Hi Micha?, Micha? Snoch writes: > I checked if my method is called more than once, but > unfortunately it is called once only. I'm now using 1.6 > version of ODB. In earlier versions everything was ok. I created a test based on the header declarations you sent in your previous email. The test can be found here: http://codesynthesis.com/~boris/tmp/odb/test.tar.gz To build the test I used the following command lines: odb -d pgsql -p qt -p boost -s --schema-format embedded node.h odb -d pgsql -p qt -p boost -s --schema-format embedded departure.h odb -d pgsql -p qt -p boost -s --schema-format embedded connection.h g++ node-odb.cxx departure-odb.cxx connection-odb.cxx driver.cxx \ -o driver -lodb-pgsql -lodb-qt -lodb-boost -lodb -lQtCore I then ran the driver like this (I use the odb_test user and database for ODB testing): ./driver --user odb_test --database odb_test The test runs without any problems. I then ran psql to verify that the Node table was created: psql --username=odb_test --dbname=odb_test > SELECT * FROM "Node"; id | street | name | lat | lon ----+--------+------+-----+----- (0 rows) I ran this test multiple times on both PostgreSQL 9.0 and 9.1 and never got the error that you are observing. Can you try this test in your setup and see if it works for you? Boris From boris at codesynthesis.com Mon Oct 31 10:40:16 2011 From: boris at codesynthesis.com (Boris Kolpackov) Date: Mon Oct 31 10:40:58 2011 Subject: [odb-users] ODB compiler source 1.6.2 bugfix released Message-ID: Hi, A new bugfix release for the ODB compiler source package is now available. It fixes an issue with plugin include paths in GCC 4.6. You only need to upgrade if (1) you are trying to build the ODB compiler from source code yourself (as opposed to using a binary package) and (2) you are using GCC 4.6 and experiencing build problems. For more information on this issue, refer to the following mailing list thread: http://www.codesynthesis.com/pipermail/odb-users/2011-October/000370.html You can download the package from the ODB download page: http://www.codesynthesis.com/products/odb/download.xhtml SHA1 checksums for the files in this release are as follows: c51343e310f838bc5e2780650cb1a2562099bdec odb-1.6.2.tar.bz2 428d5a9161e4fc33c95fb6329786f27b016b5485 odb-1.6.2.tar.gz 4b2adb85ddc835f8237cf822bd487e248491ad8c odb-1.6.2.zip Boris From boris at codesynthesis.com Mon Oct 31 10:51:26 2011 From: boris at codesynthesis.com (Boris Kolpackov) Date: Mon Oct 31 10:52:07 2011 Subject: [odb-users] odb/gcc.hxx incorrect file includes In-Reply-To: <4EAC6C19.3090105@gmail.com> References: <4EAC6C19.3090105@gmail.com> Message-ID: Hi Amr, Amr Ali writes: > 36 #include > 37 #include > ... > > These include statements should be like (below) at least to work > properly for GCC v4.6.1 x86_64 > > 36 #include > 37 #include > ... Fixed, thanks for reporting this! Note also that the patch to make it work with both 4.5 and 4.6 is a bit more involved. I have also release a bugfix package for this: http://www.codesynthesis.com/pipermail/odb-announcements/2011/000009.html Boris From past0004 at stud.fh-kl.de Mon Oct 31 12:26:15 2011 From: past0004 at stud.fh-kl.de (Pascal Stoll) Date: Mon Oct 31 12:26:35 2011 Subject: AW: [odb-users] Qt BLOB Support In-Reply-To: References: , Message-ID: Hello, sry for the late response, couldn't test it earlier. Everything seems to work fine now. I'll do some more testing but i'm pretty sure that they'll be no further problems. Thank you very much for you effort :-) Best regards ________________________________________ Von: Boris Kolpackov [boris@codesynthesis.com] Gesendet: Mittwoch, 26. Oktober 2011 16:16 Bis: Pascal Stoll Cc: odb-users@codesynthesis.com Betreff: Re: [odb-users] Qt BLOB Support Hi Pascal, Pascal Stoll writes: > The assert does nothing, but ich checked the size of both values. > o1.data.size() was 6 and o2.data.size 0. So same problem. It writes > the blob correct into the database, but when i try to read it out, > it is always null. I will need more information about your setup in order to try to reproduce this problem. In particular: * Operating system * C++ compiler/version * Database/version * ODB version * Qt version (if using) * Boost version (if using) Boris From kontakt at msnoch.pl Mon Oct 31 14:13:22 2011 From: kontakt at msnoch.pl (=?UTF-8?B?TWljaGHFgiBTbm9jaA==?=) Date: Mon Oct 31 14:13:32 2011 Subject: [odb-users] Cannot create schema In-Reply-To: References: <4EA853E1.8000201@msnoch.pl> <4EABE191.50704@msnoch.pl> Message-ID: <4EAEE542.7000906@msnoch.pl> Hi Boris, When I try to run your test I'm getting FATAL: role "myky" does not exist I don't remember if I told you before, I'm using ubuntu 11.10 whith g++ 4.6.1 On 31.10.2011 14:24, Boris Kolpackov wrote: > Hi Micha?, > > Micha? Snoch writes: > >> I checked if my method is called more than once, but >> unfortunately it is called once only. I'm now using 1.6 >> version of ODB. In earlier versions everything was ok. > I created a test based on the header declarations you sent in your > previous email. The test can be found here: > > http://codesynthesis.com/~boris/tmp/odb/test.tar.gz > > To build the test I used the following command lines: > > odb -d pgsql -p qt -p boost -s --schema-format embedded node.h > odb -d pgsql -p qt -p boost -s --schema-format embedded departure.h > odb -d pgsql -p qt -p boost -s --schema-format embedded connection.h > > g++ node-odb.cxx departure-odb.cxx connection-odb.cxx driver.cxx \ > -o driver -lodb-pgsql -lodb-qt -lodb-boost -lodb -lQtCore > > I then ran the driver like this (I use the odb_test user and database > for ODB testing): > > ./driver --user odb_test --database odb_test > > The test runs without any problems. I then ran psql to verify that > the Node table was created: > > psql --username=odb_test --dbname=odb_test >> SELECT * FROM "Node"; > id | street | name | lat | lon > ----+--------+------+-----+----- > (0 rows) > > I ran this test multiple times on both PostgreSQL 9.0 and 9.1 and > never got the error that you are observing. > > Can you try this test in your setup and see if it works for you? > > Boris From boris at codesynthesis.com Mon Oct 31 15:02:37 2011 From: boris at codesynthesis.com (Boris Kolpackov) Date: Mon Oct 31 15:03:26 2011 Subject: [odb-users] Cannot create schema In-Reply-To: <4EAEE542.7000906@msnoch.pl> References: <4EA853E1.8000201@msnoch.pl> <4EABE191.50704@msnoch.pl> <4EAEE542.7000906@msnoch.pl> Message-ID: Hi Micha?, Micha? Snoch writes: > When I try to run your test I'm getting > > FATAL: role "myky" does not exist This simply means that you are using myky as a login (role in PostgreSQL speak) and it doesn't exist. Make sure that the login and database name you are using to run the test are set up correctly (try to login using psql and make sure you can create tables, etc). If you need help with this please ask on the PostgreSQL mailing lists/forums. Boris