From boris at codesynthesis.com Sat Feb 1 00:07:59 2014 From: boris at codesynthesis.com (Boris Kolpackov) Date: Sat Feb 1 00:06:15 2014 Subject: [odb-users] Problem compiling applications when Qt is built without STL compatibility In-Reply-To: References: Message-ID: Hi Shantanu Tushar, Shantanu Tushar Jha writes: > We are using ODB for Plasma Media Center[1] in the KDE project. That's pretty cool. Let us know if you find any other issues with using ODB in projects like this. > Follwing advice from a stackoverflow post[2], we have come up with a > patch[3] for libodb-qt which seems to work. > > Now, for packaging we can either request distros to manually apply this > patch to ODB packages, or is it possible for this to be applied upstream? Yes, the more portable ODB is the better. I've applied a slightly modified version of your patch (used toLatin1() instead of toUtf8() and added a comment explaining why we can't use toStdString()): http://scm.codesynthesis.com/?p=odb/libodb-qt.git;a=commitdiff;h=1039d51ecde835ef842a6596083e771f7f367fc7;hp=4d9bde105203653492573d6d52b307c3ce42419b I've also packaged libodb-qt with the fix: http://codesynthesis.com/~boris/tmp/odb/libodb-qt-2.3.0.tar.bz2 If you could try it and let me know if everything works on your side, then I can publish it as a 2.3.1 bug-fix release. Boris From shantanu at kde.org Sat Feb 1 01:53:55 2014 From: shantanu at kde.org (Shantanu Tushar Jha) Date: Sat Feb 1 22:51:30 2014 Subject: [odb-users] Problem compiling applications when Qt is built without STL compatibility In-Reply-To: References: Message-ID: Hi Boris, Thanks for the quick reply! I tested the tarball you linked to, seems to work fine :) Also, another appreciation I have for ODB is that the manual at http://codesynthesis.com/products/odb/doc/manual.xhtml is very good, we couldn't use other C++ ORMs because their docs were very confusing. Plus there is support for Qt/sqlite which just works (TM). Thanks, On Sat, Feb 1, 2014 at 10:37 AM, Boris Kolpackov wrote: > Hi Shantanu Tushar, > > Shantanu Tushar Jha writes: > > > We are using ODB for Plasma Media Center[1] in the KDE project. > > That's pretty cool. Let us know if you find any other issues with > using ODB in projects like this. > > > > Follwing advice from a stackoverflow post[2], we have come up with a > > patch[3] for libodb-qt which seems to work. > > > > Now, for packaging we can either request distros to manually apply this > > patch to ODB packages, or is it possible for this to be applied upstream? > > Yes, the more portable ODB is the better. I've applied a slightly > modified version of your patch (used toLatin1() instead of toUtf8() > and added a comment explaining why we can't use toStdString()): > > > http://scm.codesynthesis.com/?p=odb/libodb-qt.git;a=commitdiff;h=1039d51ecde835ef842a6596083e771f7f367fc7;hp=4d9bde105203653492573d6d52b307c3ce42419b > > I've also packaged libodb-qt with the fix: > > http://codesynthesis.com/~boris/tmp/odb/libodb-qt-2.3.0.tar.bz2 > > If you could try it and let me know if everything works on your side, > then I can publish it as a 2.3.1 bug-fix release. > > Boris > -- Shantanu Tushar (UTC +0530) http://www.shantanutushar.com From ksinny at gmail.com Sat Feb 1 02:09:13 2014 From: ksinny at gmail.com (Sinny Kumari) Date: Sat Feb 1 22:51:30 2014 Subject: [odb-users] Problem compiling applications when Qt is built without STL compatibility In-Reply-To: References: Message-ID: Hi, Thank you for your quick response and writing this application which made our work easier. I also tried libodb-qt with fixes made by you on fedora and it works fine. Cheers! On Sat, Feb 1, 2014 at 12:23 PM, Shantanu Tushar Jha wrote: > Hi Boris, > > Thanks for the quick reply! I tested the tarball you linked to, seems to > work fine :) > > Also, another appreciation I have for ODB is that the manual at > http://codesynthesis.com/products/odb/doc/manual.xhtml is very good, we > couldn't use other C++ ORMs because their docs were very confusing. Plus > there is support for Qt/sqlite which just works (TM). > > Thanks, > > > On Sat, Feb 1, 2014 at 10:37 AM, Boris Kolpackov wrote: > >> Hi Shantanu Tushar, >> >> Shantanu Tushar Jha writes: >> >> > We are using ODB for Plasma Media Center[1] in the KDE project. >> >> That's pretty cool. Let us know if you find any other issues with >> using ODB in projects like this. >> >> >> > Follwing advice from a stackoverflow post[2], we have come up with a >> > patch[3] for libodb-qt which seems to work. >> > >> > Now, for packaging we can either request distros to manually apply this >> > patch to ODB packages, or is it possible for this to be applied >> upstream? >> >> Yes, the more portable ODB is the better. I've applied a slightly >> modified version of your patch (used toLatin1() instead of toUtf8() >> and added a comment explaining why we can't use toStdString()): >> >> >> http://scm.codesynthesis.com/?p=odb/libodb-qt.git;a=commitdiff;h=1039d51ecde835ef842a6596083e771f7f367fc7;hp=4d9bde105203653492573d6d52b307c3ce42419b >> >> I've also packaged libodb-qt with the fix: >> >> http://codesynthesis.com/~boris/tmp/odb/libodb-qt-2.3.0.tar.bz2 >> >> If you could try it and let me know if everything works on your side, >> then I can publish it as a 2.3.1 bug-fix release. >> >> Boris >> > > > > -- > Shantanu Tushar (UTC +0530) > http://www.shantanutushar.com > -- http://www.sinny.in From info at peredin.com Sun Feb 2 12:05:30 2014 From: info at peredin.com (Per Edin) Date: Sun Feb 2 12:05:38 2014 Subject: [odb-users] Automatic generation of C++ classes from database schema In-Reply-To: References: Message-ID: Hi, Regarding the "rough draft" approach, this could be achieved by including a region in all generated files that will be preserved when updating the schema. A checksum could also be added to each file to detect changes that would be overwritten by an update. A --force option could be added to force re-generation of modified source files. --rough-draft Include a user-modifiable region in each file that will be preserved on subsequent runs of the dumper. Exclude any public accessors unless requested explicitly with --include-accessors. --data-access Generate simple data-access classes without any user-modifiable parts. Public accessors are implicitly included. There is no --exclude-accessors since excluding them would render data-access classes completely useless. A default constructor could be added to the user-modifiable region when running the command for the first time. Per On Fri, Jan 31, 2014 at 6:11 AM, Boris Kolpackov wrote: > > Hi All, > > There seems to be quite a bit of interest in being able to > automatically generate C++ classes from the database schema. > However, this is a fairly "hairy" feature in the sense that > there are a lot of unclear/complex aspects that need to be > better understood. This is especially so since we are trying > to design a general tool. > > The goal of this thread is to try and flesh-out an overall > design for this feature based on experience and use-cases. > So if you have some ideas or a need for this functionality, > feel free to chime in. > > I've been thinking about this on and off for a couple of > years now and here is an initial list of things that I > believe we need to consider/discuss. Note also that not > all of these features/ideas will be implemented in the > first version (or even ever). However, it is a good > idea to think through them to a certain level in order > to understand how everything fits (or will fit) together. > > * What is the input to this tool? It can be an .sql file > (dump from the database or manually created/maintained). > Or it could be programmatically retrieved from a running > database instance. > > The .sql approach feels cleanest to me but the complexity > of parsing SQL is probably too much (don't believe me? > check the Oracle SQL reference ;-)). > > The programmatic approach is probably the most practical > even though it has a number of serious drawbacks (like > the need to connect to a running database). Also, most > likely it will be a separate tool that connects to the > database and extracts the schema since we cannot link > the ODB compiler to every database API library. So we > need some kind of an intermediate format that the tool > can produce and the ODB compiler can read. The XML > format that we already have for the schema evolution > sounds like a good candidate. > > Other things to consider in this area: > > - A way to limit the list of tables considered. > > - Do we use the ODB runtimes to access databases or > should we just use the C APIs? Runtimes are > not that convenient for manual database access > though we could probably improve that. Also, for > cases where we need to run plain SQL queries (as > opposed to a special-purpose C API), we could even > use ODB (views, etc). > > - We could make the ODB compiler call the extraction > tool automatically and pipe the output to it. > > * What is the output of the tool? > > - File per class? File per schema? Something in-between. > For large schemas, the file-per-schema approach is not > going to scale, especially when the database support > code generated by ODB is concerned. The file per class > approach can also get unwieldy very quickly for a large > number of classes. We have the same problem in XSD > (may end up with a couple of thousand source files). > It is manageable but not pretty. > > The in-between solution is to somehow allow the user > to specify how to group classes into files (e.g., > all related classes in a single file). > > * Intended uses: "rough draft" or "data access". > > What happens if/when the schema changes? Does the user > re-generate the classes or update them manually? > > In other words, is this feature going to generate classes > that are the "rough draft" and the user can fill them in > with customizations (e.g., functions) or are they only for > "data access" (i.e., don't have anything other than > accessors and modifiers)? > > The problem with the "rough draft" approach is what > happens when the schema changes and re-generating > the classes will loose those customizations? > > The problem with the "data access" approach is that > no functionality/logic can be added to the generated > classes. > > We will probably have to support both use-cases. > > * Support for customization? > > There are some options for supporting the customization of > the generated classes though none of them are particularly > elegant. > > We could also consider doing the unspeakable and extract > user customizations from the C++ header files. The only > reason why I am even bringing this option up is because we > are C++-parsing this file anyway (during the database support > code generation). The user will still have to mark the > regions (e.g., with pragmas which ODB could pre-insert > for each class) so it could be brittle (if you make your > changes in the wrong place, they will be gone). Though > there doesn't seem to be anything better. > > * Basic types mapping (string, containers, smart pointers) > > Different users will want different basic types to be used > in their generated classes (std::string, QString, etc). > In a sense, this is a reverse mapping of what ODB currently > does: C++ type to database type. What we need is a database > type to C++ type mapping. The big question is how and where > it is specified. > > It would also be nice if this somehow tied up to profiles. > That is, if a user specified -p qt, then ODB will use > Qt types (QString, Qt smart pointers, Qt containers, etc) > in the generated C++ classes automatically. > > * Mapping for relationships, containers, (polymorphic) > inheritance. > > This one is hard. ODB would somehow need to recognize > certain patterns and map them to relationships, containers, > etc. It may also need user guidance (see mapping > customization/annotations). > > Generally, there are a lot more ways to structure > these things (relationships, containers, inheritance) > in relational databases than in C++ so for more esoteric > cases there might not even be a sensible mapping. What > would be nice is to come up with a general mechanism > that would allow the user to specify the mapping for such > cases. The big problem, of course, is that it can become > so complex (see Hibernate and their relationship mapping) > as to be completely unusable. > > An alternative could be to only support the straightforward > cases and map the rest to plain objects for the user to > deal with (i.e., one will be able to access the data but > working with it won't be very convenient). > > * Mapping customization/annotations. > > Where and how is it specified? > > Things that the user may want to specify: > > - which tables to map > - how to map tables (container, poly-inheritance, etc) > - column type mapping > > * Naming convention used in the generated classes. > > We have licked this problem nicely in XSD. The idea is > to use a set of regex patterns to transform names to > conform to a specific naming convention. XSD comes > with a set of predefined patterns (K&R, Camel Case, > and Java). The user can "adjust" one of these with > a few regex'es of their own or can create a completely > custom naming convention. We should most likely just > use the same mechanism since it seems to work great. > > Probably should also make spacing/indentation adjustable, > especially if the user is expected to add their code to > the generated files (see customization). > From boris at codesynthesis.com Sun Feb 2 23:02:28 2014 From: boris at codesynthesis.com (Boris Kolpackov) Date: Sun Feb 2 23:00:24 2014 Subject: [odb-users] libodb-qt 2.3.1 bugfix released Message-ID: Hi, A new bugfix release for the Qt ODB profile library (libodb-qt) is now available. It removes the dependency on the STL compatibility functions in Qt, which may not be available. In other words, this is a portability fix and if you are not experiencing any problems with libodb-qt 2.3.0, you don't need to upgrade. For more details on this issue, see the following mailing list thread: http://www.codesynthesis.com/pipermail/odb-users/2014-January/001771.html http://www.codesynthesis.com/pipermail/odb-users/2014-February/001772.html You can download the new packages from the ODB download page: http://www.codesynthesis.com/products/odb/download.xhtml SHA1 checksums for the files in this release are as follows: 4f32f9a810adbb2fac45008a408a564d49a86ce6 libodb-qt-2.3.1.tar.bz2 7931df04fc746101356e170297002d90a3e1fd21 libodb-qt-2.3.1.tar.gz 94e219ec25d55b846ceac018e751ab9d909bea2e libodb-qt-2.3.1.zip Boris From boris at codesynthesis.com Sun Feb 2 23:48:05 2014 From: boris at codesynthesis.com (Boris Kolpackov) Date: Sun Feb 2 23:46:03 2014 Subject: [odb-users] Automatic generation of C++ classes from database schema In-Reply-To: References: Message-ID: Hi Per, Per Edin writes: > Regarding the "rough draft" approach, this could be achieved by > including a region in all generated files that will be preserved when > updating the schema. Yes, that's one of the ideas I outlined in my original email except I am not as enthusiastic about it as you are ;-). IMO, any king of automatic extraction of user changes from generated code will be very brittle and generally is asking for trouble. The only reason I am considering this idea is because we can do proper C++ parsing of the generated header. Which means, for example, that we don't have to rely on some special comments to indicate the beginning and the end of the hand-written code (which is how it is normally done) but instead could use language (or, more precisely, preprocessor) constructs like pragmas: class foo { ... // Generated accessors/modifiers. #pragma db begin_custom #pragma db end_custom private: ... // Generated data members, etc. }; There are still a lot of issue with this approach, however. For example, what happens if you rename table foo to bar. Now ODB sees custom code for class foo but there is no class foo anymore. ODB also cannot be expected to know that these changes need to be moved to class bar. More generally, what do we do with user changes that cannot be added back to the new generated code? We cannot just drop them. Probably the most pragmatic way to handle this is to save the old file and issue warnings for each case where old code could not have been "transplanted". Thanks for your thoughts! Boris From yph20040107 at hotmail.com Sun Feb 16 22:28:52 2014 From: yph20040107 at hotmail.com (yinpeihua) Date: Mon Feb 17 00:24:46 2014 Subject: [odb-users] an internal compiler error Message-ID: Hello! My IDE is VS2005. When i compiled "odb-2.3.0-i686-windows" or "libodb-mssql-2.3.0" or my own codes dependent on odb library, i encountered an compiler error: "1>D:\odb2.3\libodb-2.3.0\odb/database.hxx(76) : fatal error C1001: An internal error has occurred in the compiler. 1>(compiler file 'msc1.cpp', line 1392)" Why this happend? How to solve this problem? Help me please, and thank you very much! From boris at codesynthesis.com Mon Feb 17 08:54:28 2014 From: boris at codesynthesis.com (Boris Kolpackov) Date: Mon Feb 17 08:52:21 2014 Subject: [odb-users] an internal compiler error In-Reply-To: References: Message-ID: Hi, yinpeihua writes: > My IDE is VS2005. > > "1>D:\odb2.3\libodb-2.3.0\odb/database.hxx(76) : fatal error C1001: An > internal error has occurred in the compiler. We built all the ODB tests and example with VS2005 for 2.3.0 and never got this error. Make sure you have the latest VS service pack installed. I am pretty sure this is the problem. Boris From cwlee.nexgeo at gmail.com Tue Feb 18 19:31:20 2014 From: cwlee.nexgeo at gmail.com (changwon lee) Date: Tue Feb 18 23:28:56 2014 Subject: [odb-users] check database connection Message-ID: Hello can I check if database connection is valid before use it? From boris at codesynthesis.com Tue Feb 18 23:51:32 2014 From: boris at codesynthesis.com (Boris Kolpackov) Date: Tue Feb 18 23:49:25 2014 Subject: [odb-users] check database connection In-Reply-To: References: Message-ID: Hi Changwon, changwon lee writes: > can I check if database connection is valid before use it? What database are you using? Some databases, such as MySQL, have the ping() function to validate the connection while for others you will need to execute some kind of a dummy statement (which makes the whole exercise moot since you might as well try to execute the actual thing). Yet for others, such as SQLite, there is no need since there is no "connection" as such. Boris From erezgb at walla.com Wed Feb 19 09:48:08 2014 From: erezgb at walla.com (=?UTF-8?Q?=45=72=65=7A=20=47=42?=) Date: Fri Feb 21 00:47:51 2014 Subject: [odb-users] ODB compiler ignore instruction Message-ID: <1392821286.660000-42323755-14228@walla.com>


Hi,


I am looking for a way to instruct the ODB compiler to ignore a section of the source code,

how can I achive that ?


Thank you,

Erez.

From boris at codesynthesis.com Fri Feb 21 00:58:08 2014 From: boris at codesynthesis.com (Boris Kolpackov) Date: Fri Feb 21 00:56:08 2014 Subject: [odb-users] ODB compiler ignore instruction In-Reply-To: <1392821286.660000-42323755-14228@walla.com> References: <1392821286.660000-42323755-14228@walla.com> Message-ID: Hi Erez, Erez GB writes: > I am looking for a way to instruct the ODB compiler to ignore a section > of the source code, how can I achive that? You can use the ODB_COMPILER macro which is defined when the code is compiled with the ODB compiler: #ifndef ODB_COMPILER // Code that the ODB compiler should not see. #endif You can search in the manual for 'ODB_COMPILER' to see some examples of this macro's usage. Boris From alan.meekins at gmail.com Mon Feb 24 23:37:53 2014 From: alan.meekins at gmail.com (Alan Meekins) Date: Mon Feb 24 23:38:00 2014 Subject: [odb-users] Using container members as predicates Message-ID: Hi there, I've been using ODB with much success though recently I've hit a snag. I would like to do a query similar to: result users_with_link = db.query( > query::url_list.contains("http://awesometastic.uri/blah") ); After some digging into the mailing list archives, I see that this question was asked back in 2011( http://www.codesynthesis.com/pipermail/odb-users/2011-July/000153.html). At the time there was no support for this type of query and so native queries was the answer. Is using container members as predicates still not a directly supported scenario? Native queries still the best way to do this? Thanks -Alan From lidia at lemur-soft.com Tue Feb 25 05:50:10 2014 From: lidia at lemur-soft.com (Lidia Kalinovsky) Date: Tue Feb 25 08:45:45 2014 Subject: [odb-users] Empty db file size difference between MAC and Windows Message-ID: Hello Attached are 2 db files, created with odb with the same code, but MAC.sqlite is created on Macintosh and Windows.sqlite is created on Windows. There is no data inside. There is big difference in size. I believe that this is because sqlite library. Could somebody advice ? Thanks. Lidia. -- Software integration and outsourcing services, Lemur-Soft, Giv'at Nili Israel, 37825 Phone : (+972) 545748325 Fax : (+972) 775345383 Email : lidia@lemur-soft.com Web: www.lemur-soft.com -------------- next part -------------- A non-text attachment was scrubbed... Name: MAC.sqlite Type: application/octet-stream Size: 389120 bytes Desc: not available Url : http://codesynthesis.com/pipermail/odb-users/attachments/20140225/5d27e931/MAC-0001.obj -------------- next part -------------- A non-text attachment was scrubbed... Name: Windows.sqlite Type: application/octet-stream Size: 140288 bytes Desc: not available Url : http://codesynthesis.com/pipermail/odb-users/attachments/20140225/5d27e931/Windows-0001.obj From boris at codesynthesis.com Tue Feb 25 08:50:38 2014 From: boris at codesynthesis.com (Boris Kolpackov) Date: Tue Feb 25 08:53:40 2014 Subject: [odb-users] Empty db file size difference between MAC and Windows In-Reply-To: References: Message-ID: Hi Lidia, Lidia Kalinovsky writes: > Attached are 2 db files, created with odb with the same code, but > MAC.sqlite is created on Macintosh and Windows.sqlite is created > on Windows. There is no data inside. > > There is big difference in size. > > I believe that this is because sqlite library. > Could somebody advice ? It took a quick look, and the list of tables in each database is different. For example, agent_brands_relation only exists in one of them. If you still get significantly different sizes for two identical databases and this is a problem for you for some reason, then I suggest that you ask for help on the SQLite mailing list. Boris From boris at codesynthesis.com Tue Feb 25 08:56:04 2014 From: boris at codesynthesis.com (Boris Kolpackov) Date: Tue Feb 25 08:59:07 2014 Subject: [odb-users] Using container members as predicates In-Reply-To: References: Message-ID: Hi Alan, Alan Meekins writes: > I would like to do a query similar to: > > result users_with_link = db.query( > query::url_list.contains("http://awesometastic.uri/blah") ); > > Is using container members as predicates still not a directly supported > scenario? Native queries still the best way to do this? Yes, I am afraid so. Here is the latest thread on this topic: http://www.codesynthesis.com/pipermail/odb-users/2014-January/001696.html We will most likely try to support this feature in some form in the next release of ODB. Boris From lidia at lemur-soft.com Tue Feb 25 10:37:28 2014 From: lidia at lemur-soft.com (Lidia Kalinovsky) Date: Tue Feb 25 10:37:35 2014 Subject: [odb-users] Empty db file size difference between MAC and Windows In-Reply-To: References: Message-ID: thanks On Tue, Feb 25, 2014 at 3:50 PM, Boris Kolpackov wrote: > Hi Lidia, > > Lidia Kalinovsky writes: > > > Attached are 2 db files, created with odb with the same code, but > > MAC.sqlite is created on Macintosh and Windows.sqlite is created > > on Windows. There is no data inside. > > > > There is big difference in size. > > > > I believe that this is because sqlite library. > > Could somebody advice ? > > It took a quick look, and the list of tables in each database > is different. For example, agent_brands_relation only exists in > one of them. > > If you still get significantly different sizes for two identical > databases and this is a problem for you for some reason, then > I suggest that you ask for help on the SQLite mailing list. > > Boris > -- Software integration and outsourcing services, Lemur-Soft, Giv'at Nili Israel, 37825 Phone : (+972) 545748325 Fax : (+972) 775345383 Email : lidia@lemur-soft.com Web: www.lemur-soft.com From boris at codesynthesis.com Wed Feb 26 01:52:34 2014 From: boris at codesynthesis.com (Boris Kolpackov) Date: Wed Feb 26 01:55:35 2014 Subject: [odb-users] ODB packages for RHEL 5, 6 and Fedora 19-21 available Message-ID: Hi, Thanks to a persistent effort by Dave Johansen, official ODB packages are now available for RedHat Enterprise Linux (EL) 5 and 6 (and derivatives such as CentOS, Scientific Linux, etc.), as well as Fedora 19-21. The EL packages are available in the EPEL (Extra Packages for Enterprise Linux) repository[1]. Note that the ODB compiler package depends on the devtools package which provides the newer version of GCC (you can still use the stock GCC version that comes with EL to build your ODB-based applications). The Fedora packages are available from the standard Fedora package repositories. You can install ODB from these repositories just like any other package, for example, by using 'yum': yum install odb yum install libodb yum install libodb-sqlite The following ODB components are packaged: odb ODB compiler libodb Common ODB runtime libodb-mysql MySQL ODB runtime libodb-sqlite SQLite ODB runtime libodb-pgsql PostgreSQL ODB runtime libodb-qt Qt ODB profile libodb-boost Boost ODB profile Enjoy and, again, many thanks to Dave Johansen for his effort. [1] https://fedoraproject.org/wiki/EPEL/FAQ Boris From sachnk at gmail.com Thu Feb 27 16:20:47 2014 From: sachnk at gmail.com (Sachin Kumar) Date: Fri Feb 28 01:28:46 2014 Subject: [odb-users] Simple Raw Pointer Container Message-ID: Greetings, I'm relatively new to ODB, so there likely is a simple solution to my problem. As outlined in the sample below, I have two classes: MyHolder and MyElement. MyHolder has a std::vector of MyElement. The code below works and I get the appropriate tables in my database, namely myholder and myholder_myelement. However, if I change the std::vector to be a vector of MyElement pointers, it doesn't work. I get a "error: unable to map C++ type" error from the ODB compiler. I've tried several things to fix this: 1. Use #pragma db object instead of #pragma db value for MyElement. This seems fix the ODB compile problem, except that the myholder_myelement table now contains the actual pointer value, which isn't at all useful. Is this expected? 2. I've also tried using boost::shared_ptr, thinking that perhaps using raw pointers causes problems, but to no avail. What's the right way to do this? class MyElement; #pragma db object #pragma db model version(1, 1, open) class MyHolder { ... private: friend class odb::access; // some members std::vector elements; }; #pragma db value class MyElement { ... private: friend class odb::acess; // some members }; From boris at codesynthesis.com Fri Feb 28 06:47:12 2014 From: boris at codesynthesis.com (Boris Kolpackov) Date: Fri Feb 28 06:50:23 2014 Subject: [odb-users] Simple Raw Pointer Container In-Reply-To: References: Message-ID: Hi Sachin, Sachin Kumar writes: > However, if I change the std::vector to be a vector of MyElement > pointers, it doesn't work. I get a "error: unable to map C++ type" > error from the ODB compiler. > > I've tried several things to fix this: > > 1. Use #pragma db object instead of #pragma db value for MyElement. This > seems fix the ODB compile problem, except that the myholder_myelement table > now contains the actual pointer value, which isn't at all useful. Is this > expected? Yes, if you make MyElement an object instead of a value, then it gets its own table and the table corresponding to the vector contains this object's ids instead of the data itself. In other words, what you get is a vector of pointers to objects (a relationship). > 2. I've also tried using boost::shared_ptr, thinking that perhaps using raw > pointers causes problems, but to no avail. That should work provided that you enable the Boost profile (libodb-boost, '-p boost' ODB compiler option). > What's the right way to do this? If you want to keep MyElement a value, then the correct way is to use something like boost::shared_ptr or std::unique_ptr (C++11). Just for the background, in ODB, a smart pointer is treated differently depending on whether it is a smart pointer to object or value. If it is a pointer to object, then you get an object pointer. If, however, it is a pointer to value, then it is treated as a wrapper. A wrapper in ODB is an entity that contains a value. For example, boost::optional is a wrapper. So is shared_ptr, auto_ptr, unique_ptr, etc. Wrappers normally provide additional functionality, such as NULL semantics. Note that a raw pointer to object is recognized as an object pointer but a raw pointer to value is not, at least by default (there is a way to make raw pointers work; see libodb/odb/wrapper-traits.hxx) You can read more about this in Section 7.3, "Pointers and NULL Value Semantics". Boris From Harald.Frostel at jku.at Thu Feb 27 09:13:08 2014 From: Harald.Frostel at jku.at (Harald Frostel) Date: Mon Mar 3 07:39:27 2014 Subject: [odb-users] Parsing error in options-file? Message-ID: <530F56040200004C000B1E4A@gwia.im.jku.at> Hi! I experienced problems when using an options-file with the ODB compiler. It seems that options in the file, that use only one dash (e.g. -v or -d) are simply ignored. The workaround is, to remove them from the file and put them in den command line directly. My configuration is Windows 7 x64 and ODB compiler 2.3.0 (x64). Regards Harald **************************************************** Dipl.-Ing. Harald Frostel Department of Computational Perception Johannes Kepler University Linz Altenberger Strasse 69 A-4040 Linz, Austria Tel: +43 732 2468 1521 Fax: +43 732 2468 1520 Mail: harald.frostel@jku.at http://www.cp.jku.at/people/frostel ****************************************************