From voicelessvoid at gmail.com Thu Feb 2 11:20:44 2012 From: voicelessvoid at gmail.com (Ivanov Sergey) Date: Thu Feb 2 15:25:44 2012 Subject: [odb-users] mass update statement Message-ID: Consider the following SQL query: "UPDATE table SET attr1 = 'abc' WHERE attr2 = 123". Is there a way to perform this kind of mass updates without the use of database::execute method with plain-text sql? Something similar to a database::erase_query could be nice. From boris at codesynthesis.com Fri Feb 3 08:49:34 2012 From: boris at codesynthesis.com (Boris Kolpackov) Date: Fri Feb 3 08:43:47 2012 Subject: [odb-users] mass update statement In-Reply-To: References: Message-ID: Hi Sergey, Ivanov Sergey writes: > Consider the following SQL query: "UPDATE table SET attr1 = 'abc' WHERE > attr2 = 123". > > Is there a way to perform this kind of mass updates without the use > of database::execute method with plain-text sql? Not at the moment. > Something similar to a database::erase_query could be nice. When we were working on views we thought about extending the query mechanism to also support DML statements. This will allow the kind of things that you are looking for. The syntax could be along these lines: typedef odb::members members; db.update (set (members::first = "John", members::last = "Doe"), where (members::age < 18)); We could even support some more interesting cases: db.update (set (members::age = members::age + 1), where (members::born == date::day_clock::local_day ())); We have this feature on our TODO list. Hopefully we will get to it soon. Thanks for the suggestion. Boris From gerasch at informatik.uni-tuebingen.de Thu Feb 9 07:56:08 2012 From: gerasch at informatik.uni-tuebingen.de (Andreas Gerasch) Date: Thu Feb 9 07:56:20 2012 Subject: [odb-users] Polymorphism and lazy/weak pointers In-Reply-To: References: <4F265C31.8090006@informatik.uni-tuebingen.de> Message-ID: <4F33C268.4010003@informatik.uni-tuebingen.de> Hi Boris, thanks for your fast reply, we have still not decided what we will do, so I will come back later to this problem. But, in the meantime we got a problem with loading of long strings (> 265 characters) which are mapped to TEXT in MySQL. We figured out, that it is caused by the definition of basic_buffer from buffer.hxx: template class basic_buffer: public basic_buffer_base { public: basic_buffer (std::size_t capacity = 256) : basic_buffer_base (capacity) { } T* data () { return static_cast (data_); } const T* data () const { return static_cast (data_); } }; where you set the capacity to 256. So, if I increase the capacity (as shown below in my *-odb.hxx by introducing a default constructor) it works again. Is there a problem with the odb-compiler or do we miss some configuration (pragma?) options? It would be nice to set the default "max-length" of std::strings. struct data_image_type { data_image_type() : value_value(512) { } // index // unsigned long long index_value; my_bool index_null; // value // details::buffer value_value; unsigned long value_size; my_bool value_null; std::size_t version; }; Thanks a lot, Andreas On 01/30/2012 04:15 PM, Boris Kolpackov wrote: > Hi Andreas, > > Andreas Gerasch writes: > >> Do you know if polymorphism works together with lazy loading? > > Not out of the box. An "unloaded" lazy pointer stores the object > id and uses the standard database::load() function to load it when > requested. At the moment the way to handle polymorphism in lazy > pointers would be to create your own version of a lazy pointer > which uses your getObjectByID() function instead of standard > load(). There is a bit of work but you can use the boost > implementation as a guide. > > Also, we are planning to add support for polymorphic inheritance > in the next release of ODB (not 1.8.0 that is coming our tomorrow; > the version after that). So if you can wait for a few months, then > that could be another option. I can also let you know as soon as we > have something to try, if your are interested. > > >> Second, is there a possibility to change the caching of objects in a >> session from shared to weak without changing the pointer types of the >> objects? > > No, the session uses the object pointer. Plus you cannot use a weak > pointer as an object pointer. Though I kind of see why someone would > want to use a weak pointer in the session. On the other hand, in the > future, session may become more than just an object cache (e.g., we > may use it to track dirty objects if we decide to support auto-flushing) > in which case weak pointers won't really work. Perhaps a better approach > would be to allow custom eviction decisions. For example, you could > provide a callback that checks the reference count and if it is 1, > then you could remove the object from the session. This would be > pretty much equivalent to the lazy pointer semantics. What do you > think? > > Boris -------------- next part -------------- A non-text attachment was scrubbed... Name: gerasch.vcf Type: text/x-vcard Size: 435 bytes Desc: not available Url : http://codesynthesis.com/pipermail/odb-users/attachments/20120209/0c1e04a7/gerasch.vcf From boris at codesynthesis.com Thu Feb 9 09:22:03 2012 From: boris at codesynthesis.com (Boris Kolpackov) Date: Thu Feb 9 09:16:14 2012 Subject: [odb-users] Re: Problem loading long TEXT strings with MySQL In-Reply-To: <4F33C268.4010003@informatik.uni-tuebingen.de> References: <4F265C31.8090006@informatik.uni-tuebingen.de> <4F33C268.4010003@informatik.uni-tuebingen.de> Message-ID: Hi Andreas, Andreas Gerasch writes: > But, in the meantime... In the future, for a new question please start a new thread with a descriptive subject instead of replying to an unrelated one, as discussed in the posting guidelines: http://www.codesynthesis.com/support/posting-guidelines.xhtml > .. we got a problem with loading of long strings (> 265 characters) > which are mapped to TEXT in MySQL. > > We figured out, that it is caused by the definition of basic_buffer from > buffer.hxx: > > [...] > > where you set the capacity to 256. So, if I increase the capacity (as > shown below in my *-odb.hxx by introducing a default constructor) it > works again. Is there a problem with the odb-compiler or do we miss some > configuration (pragma?) options? It would be nice to set the default > "max-length" of std::strings. No, this is the default initial buffer size and the buffer is automatically expanded as needed. Which version of ODB are you using? We fixed a bug that affected this mechanism in version 1.6.0 so if you are using something earlier, you will need to upgrade. If you are already using 1.6.0 or later then I will need more information on how to reproduce this. Does it happen when you call load() or some other database function? Ideally I would need a small test case that reproduces this problem (you can use one of the examples as a base, if you want). Boris From boris at codesynthesis.com Thu Feb 9 10:17:56 2012 From: boris at codesynthesis.com (Boris Kolpackov) Date: Thu Feb 9 10:11:56 2012 Subject: [odb-users] Re: Problem loading long TEXT strings with MySQL In-Reply-To: <4F33DB26.3020107@informatik.uni-tuebingen.de> References: <4F265C31.8090006@informatik.uni-tuebingen.de> <4F33C268.4010003@informatik.uni-tuebingen.de> <4F33DB26.3020107@informatik.uni-tuebingen.de> Message-ID: Hi Andreas, In the future please keep your replies CC'ed to the odb-users mailing list, again, as discussed in the posting guidelines: http://www.codesynthesis.com/support/posting-guidelines.xhtml Andreas Gerasch writes: > I tried to compile your examples, but the bootstrap and the configure > aborts with errors: > > ./bootstrap > > [...] > > configure.ac:11: installing `config/missing' > automake: no `Makefile.am' found for any configure output > automake: Did you forget AC_CONFIG_FILES([Makefile]) in configure.ac? > autoreconf: automake failed with exit status: 1 > > > ./configure --with-database=mysql > > [...] > > configure: creating ./config.status > ./config.status: eval: line 1178: syntax error near unexpected token `(' > ./config.status: eval: line 1178: `set X :F __path__(config_files) :H > config.h :C depfiles libtool mysql.options' > ./config.status: line 1178: warning: syntax errors in . or eval will > cause future versions of the shell to abort as Posix requires > > Any ideas? I use ubuntu lucid and used the head from your examples git. You cannot just get a project from git and bootstrap it. You first need to prepare the distribution (see the INSTALL-GIT file for details). It is much easier, however, to get the official odb-examples-1.7.0.tar.bz2 package which is already bootstrapped. Older releases are available here: http://www.codesynthesis.com/download/odb/ I just tried to change the line 31 in hello/driver.cxx: person jane ("Jane", "Doe", 32); To read: person jane ("Jan" + string (512, 'n') + 'e', "Doe", 32); I then ran the test (make check) and I see the correct, full string being printed. Can you try this and see if it works for you? Boris From gerasch at informatik.uni-tuebingen.de Fri Feb 10 03:19:37 2012 From: gerasch at informatik.uni-tuebingen.de (Andreas Gerasch) Date: Fri Feb 10 03:19:50 2012 Subject: [odb-users] Re: Problem loading long TEXT strings with MySQL In-Reply-To: References: <4F265C31.8090006@informatik.uni-tuebingen.de> <4F33C268.4010003@informatik.uni-tuebingen.de> <4F33DB26.3020107@informatik.uni-tuebingen.de> Message-ID: <4F34D319.4050804@informatik.uni-tuebingen.de> Hi Boris, > In the future please keep your replies CC'ed to the odb-users mailing > list, again, as discussed in the posting guidelines: sorry, for that - I just missed the reply all button. > I just tried to change the line 31 in hello/driver.cxx: > > person jane ("Jane", "Doe", 32); > > To read: > > person jane ("Jan" + string (512, 'n') + 'e', "Doe", 32); > > I then ran the test (make check) and I see the correct, full string > being printed. Can you try this and see if it works for you? After using the odb-examples.tar.gz, I was able to reproduce the problem using your hello example by introducing a vector of middle names. In person.hxx, I added a private field std::vector middle_; and two public methods void add_middle(std::string m) { middle_.push_back(m); } std::vector get_middle() { return middle_; } In driver.cxx I added the lines john.add_middle(string(512, 'n')); jane.add_middle("Janette"); joe.add_middle("Dalton"); and changed the output to cout << "Hello, " << i->first () << " " << i->get_middle()[0] << " " << i->last () << "!" << endl; After persisting the objects, I changed the code and loaded the data only by querying all persons. Then I got this result: Hello, John nnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnn1 primary compiled primary compiled Hi Andreas, > > Andreas Gerasch writes: > >> After using the odb-examples.tar.gz, I was able to reproduce the problem >> using your hello example by introducing a vector of middle names. > > I tried the code you have attached with ODB 1.8.0 and it works without > any problems. I don't have the 1.7.0 build around, so could you try > this test with 1.8.0 on your setup? While I don't believe we fixed this > specific issue in 1.8.0, we might have made some changes that fixed it > indirectly. > > If it still fails for you with 1.8.0, I will need more information about > your setup. Specifically, which version of the MySQL client library you > are using (dpkg -s libmysqlclient-dev) as well as the version of the > MySQL server you are connecting to. > > Boris -------------- next part -------------- A non-text attachment was scrubbed... Name: gerasch.vcf Type: text/x-vcard Size: 435 bytes Desc: not available Url : http://codesynthesis.com/pipermail/odb-users/attachments/20120210/4626c1b7/gerasch.vcf From gerasch at informatik.uni-tuebingen.de Fri Feb 10 04:46:07 2012 From: gerasch at informatik.uni-tuebingen.de (Andreas Gerasch) Date: Sat Feb 11 10:13:10 2012 Subject: [odb-users] Re: Problem loading long TEXT strings with MySQL In-Reply-To: References: <4F265C31.8090006@informatik.uni-tuebingen.de> <4F33C268.4010003@informatik.uni-tuebingen.de> <4F33DB26.3020107@informatik.uni-tuebingen.de> <4F34D319.4050804@informatik.uni-tuebingen.de> Message-ID: <4F34E75F.30907@informatik.uni-tuebingen.de> Hi Boris, I just tried the 1.8.0 version (including libodb libodb-mysql libodb-boost odb) but I have the same Problem. Below are the version infos about libmysqlclient-dev and the dependencies of driver. The mysql server has version 5.1.41-3ubuntu12.10 (Ubuntu) and it is running on the same machine. What is your version of the libmysqlclient-dev? Andreas > dpkg -s libmysqlclient-dev Package: libmysqlclient-dev Status: install ok installed Priority: optional Section: libdevel Installed-Size: 9580 Maintainer: Ubuntu Developers Architecture: amd64 Source: mysql-dfsg-5.1 Version: 5.1.41-3ubuntu12.10 Replaces: libmysqlclient15-dev Provides: libmysqlclient15-dev Depends: libmysqlclient16 (= 5.1.41-3ubuntu12.10), zlib1g-dev, libc6 (>= 2.2.5), libgcc1 (>= 1:4.1.1), libstdc++6 (>= 4.1.1) Conflicts: libmysqlclient10-dev, libmysqlclient12-dev, libmysqlclient14-dev, libmysqlclient15-dev Description: MySQL database development files MySQL is a fast, stable and true multi-user, multi-threaded SQL database server. SQL (Structured Query Language) is the most popular database query language in the world. The main goals of MySQL are speed, robustness and ease of use. . This package includes development libraries and header files. Homepage: http://dev.mysql.com/ Original-Maintainer: Debian MySQL Maintainers > ldd driver linux-vdso.so.1 => (0x00007fffc3dff000) libodb-mysql-1.8.so => /usr/local/lib/libodb-mysql-1.8.so (0x00007f4e35710000) libQtCore.so.4 => /usr/lib/libQtCore.so.4 (0x00007f4e35266000) libodb-boost-1.8.so => /usr/local/lib/libodb-boost-1.8.so (0x00007f4e35062000) libboost_date_time.so.1.40.0 => /usr/lib/libboost_date_time.so.1.40.0 (0x00007f4e34e4f000) libboost_system.so.1.40.0 => /usr/lib/libboost_system.so.1.40.0 (0x00007f4e34c4b000) libodb-1.8.so => /usr/local/lib/libodb-1.8.so (0x00007f4e34a3b000) libpthread.so.0 => /lib/libpthread.so.0 (0x00007f4e3481e000) libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x00007f4e3450a000) libm.so.6 => /lib/libm.so.6 (0x00007f4e34286000) libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x00007f4e3406f000) libc.so.6 => /lib/libc.so.6 (0x00007f4e33cec000) libmysqlclient_r.so.16 => /usr/lib/libmysqlclient_r.so.16 (0x00007f4e338d6000) libz.so.1 => /lib/libz.so.1 (0x00007f4e336bf000) libdl.so.2 => /lib/libdl.so.2 (0x00007f4e334bb000) libgthread-2.0.so.0 => /usr/lib/libgthread-2.0.so.0 (0x00007f4e332b5000) librt.so.1 => /lib/librt.so.1 (0x00007f4e330ad000) libglib-2.0.so.0 => /lib/libglib-2.0.so.0 (0x00007f4e32dcf000) /lib64/ld-linux-x86-64.so.2 (0x00007f4e3593e000) libcrypt.so.1 => /lib/libcrypt.so.1 (0x00007f4e32b95000) libnsl.so.1 => /lib/libnsl.so.1 (0x00007f4e3297b000) libpcre.so.3 => /lib/libpcre.so.3 (0x00007f4e3274c000) On 02/10/2012 10:07 AM, Boris Kolpackov wrote: > Hi Andreas, > > Andreas Gerasch writes: > >> After using the odb-examples.tar.gz, I was able to reproduce the problem >> using your hello example by introducing a vector of middle names. > > I tried the code you have attached with ODB 1.8.0 and it works without > any problems. I don't have the 1.7.0 build around, so could you try > this test with 1.8.0 on your setup? While I don't believe we fixed this > specific issue in 1.8.0, we might have made some changes that fixed it > indirectly. > > If it still fails for you with 1.8.0, I will need more information about > your setup. Specifically, which version of the MySQL client library you > are using (dpkg -s libmysqlclient-dev) as well as the version of the > MySQL server you are connecting to. > > Boris -------------- next part -------------- A non-text attachment was scrubbed... Name: gerasch.vcf Type: text/x-vcard Size: 435 bytes Desc: not available Url : http://codesynthesis.com/pipermail/odb-users/attachments/20120210/51c5404f/gerasch.vcf From boris at codesynthesis.com Mon Feb 13 09:30:36 2012 From: boris at codesynthesis.com (Boris Kolpackov) Date: Mon Feb 13 09:24:59 2012 Subject: [odb-users] Re: Problem loading long TEXT strings with MySQL In-Reply-To: <4F34EAAE.2020505@informatik.uni-tuebingen.de> References: <4F265C31.8090006@informatik.uni-tuebingen.de> <4F33C268.4010003@informatik.uni-tuebingen.de> <4F33DB26.3020107@informatik.uni-tuebingen.de> <4F34D319.4050804@informatik.uni-tuebingen.de> <4F34EAAE.2020505@informatik.uni-tuebingen.de> Message-ID: Hi Andreas, Andreas Gerasch writes: > The first call of driver contains the code for creating the objects. > The second call of driver does not contain this code, it only loads > the objects from the database. Ok, that's the part that I was missing. Now I could reproduce the problem and come up with the fix: http://scm.codesynthesis.com/?p=odb/odb.git;a=commit;h=99a42b94dcb9de7f36190b1eb79e03cca777beb0 I also built two ODB compiler binaries (for Linux and Windows) with the fix: http://www.codesynthesis.com/~boris/tmp/odb/odb-1.8.1-x86_64-linux-gnu.tar.bz2 http://www.codesynthesis.com/~boris/tmp/odb/odb-1.8.1-i686-windows.zip Can you give it a try and confirm that it works in your application? And thanks for reporting this! Boris From gerasch at informatik.uni-tuebingen.de Mon Feb 13 09:54:30 2012 From: gerasch at informatik.uni-tuebingen.de (Andreas Gerasch) Date: Mon Feb 13 09:54:43 2012 Subject: [odb-users] Re: Problem loading long TEXT strings with MySQL In-Reply-To: References: <4F265C31.8090006@informatik.uni-tuebingen.de> <4F33C268.4010003@informatik.uni-tuebingen.de> <4F33DB26.3020107@informatik.uni-tuebingen.de> <4F34D319.4050804@informatik.uni-tuebingen.de> <4F34EAAE.2020505@informatik.uni-tuebingen.de> Message-ID: <4F392426.6090107@informatik.uni-tuebingen.de> Hi Boris, thats it, now it works as expected. Thanks a lot, Andreas On 02/13/2012 03:30 PM, Boris Kolpackov wrote: > Hi Andreas, > > Andreas Gerasch writes: > >> The first call of driver contains the code for creating the objects. >> The second call of driver does not contain this code, it only loads >> the objects from the database. > > Ok, that's the part that I was missing. Now I could reproduce the > problem and come up with the fix: > > http://scm.codesynthesis.com/?p=odb/odb.git;a=commit;h=99a42b94dcb9de7f36190b1eb79e03cca777beb0 > > I also built two ODB compiler binaries (for Linux and Windows) with the > fix: > > http://www.codesynthesis.com/~boris/tmp/odb/odb-1.8.1-x86_64-linux-gnu.tar.bz2 > http://www.codesynthesis.com/~boris/tmp/odb/odb-1.8.1-i686-windows.zip > > Can you give it a try and confirm that it works in your application? And > thanks for reporting this! > > Boris -------------- next part -------------- A non-text attachment was scrubbed... Name: gerasch.vcf Type: text/x-vcard Size: 435 bytes Desc: not available Url : http://codesynthesis.com/pipermail/odb-users/attachments/20120213/3ac53ef8/gerasch.vcf From wesmharris at gmail.com Wed Feb 15 12:16:50 2012 From: wesmharris at gmail.com (Wesley Harris) Date: Wed Feb 15 12:51:24 2012 Subject: [odb-users] C++11 support Message-ID: Hi! I'm just starting to use ODB, and I really like it (aside from the extra tool in the build chain). What really gets me down though is the lack of C++11 support. While I know that the standard was only recently published, some of the language features have been around for a long time. It would be really great to see some more support for these new features. Two things which I've encountered: 1) std::shared_ptr (rather than std::tr1::shared_ptr). I know that they're the same, but I don't like to have to use the tr1 namespace just for serialization code. 2) The use of nested template types with out a space between the angle brackets. e.g. I want to use shared_ptr> rather than shared_ptr_> (underscore to emphasize the space) Thanks for the great library! I really think that it is the best out there as it is reasonably non-intrusive, and doesn't require hefty dependancies like Qt Wes From boris at codesynthesis.com Thu Feb 16 09:45:34 2012 From: boris at codesynthesis.com (Boris Kolpackov) Date: Thu Feb 16 09:39:34 2012 Subject: [odb-users] C++11 support In-Reply-To: References: Message-ID: Hi Wesley, Wesley Harris writes: > 2) The use of nested template types with out a space between the angle > brackets. e.g. I want to use shared_ptr> rather than > shared_ptr_> (underscore to emphasize the space) This you can fix right now by passing -x -std=c++0x to the ODB compiler. It will switch GCC the into C++11 mode. I just tried to compile all the tests with this flag and aside from a simple shared_ptr ambiguity in the common/lazy-ptr test everything compiles and runs just fine. > 1) std::shared_ptr (rather than std::tr1::shared_ptr). I know that > they're the same, but I don't like to have to use the tr1 namespace just > for serialization code. I could add support for std::shared_ptr (along with an ODB compiler option for C++11, e.g., --std c++11) in the next couple of days. Would you be interested to try it out? > Thanks for the great library! I really think that it is the best out there > as it is reasonably non-intrusive, and doesn't require hefty dependancies > like Qt Thanks, I am glad you like it. And thanks for the suggestions. C++11 is definitely something we are planning to support so having someone actually using ODB in this mode and giving us feedback is very much appreciated. Boris From n.albeza at gmail.com Thu Feb 16 19:50:38 2012 From: n.albeza at gmail.com (Nicolas ALBEZA) Date: Thu Feb 16 19:50:50 2012 Subject: [odb-users] C++11 support In-Reply-To: References: Message-ID: Hello, Since i'm using both ODB and C++11 daily, having some C++11 support would be indeed greatly appreciated, and i'd gladly help trying it out and giving some feedback. Big thanks for this nice library ! 2012/2/16 Boris Kolpackov > Hi Wesley, > > Wesley Harris writes: > > > 2) The use of nested template types with out a space between the angle > > brackets. e.g. I want to use shared_ptr> rather than > > shared_ptr_> (underscore to emphasize the space) > > This you can fix right now by passing -x -std=c++0x to the ODB compiler. > It will switch GCC the into C++11 mode. I just tried to compile all the > tests with this flag and aside from a simple shared_ptr ambiguity in the > common/lazy-ptr test everything compiles and runs just fine. > > > > 1) std::shared_ptr (rather than std::tr1::shared_ptr). I know that > > they're the same, but I don't like to have to use the tr1 namespace just > > for serialization code. > > I could add support for std::shared_ptr (along with an ODB compiler option > for C++11, e.g., --std c++11) in the next couple of days. Would you be > interested to try it out? > > > > Thanks for the great library! I really think that it is the best out > there > > as it is reasonably non-intrusive, and doesn't require hefty dependancies > > like Qt > > Thanks, I am glad you like it. And thanks for the suggestions. C++11 is > definitely something we are planning to support so having someone actually > using ODB in this mode and giving us feedback is very much appreciated. > > Boris > > -- ALBEZA "Pause" Nicolas From pstath at axxcelera.com Fri Feb 24 11:31:33 2012 From: pstath at axxcelera.com (Stath, Paul) Date: Fri Feb 24 11:31:46 2012 Subject: [odb-users] Generate DDL and DML methods in separate output files. Message-ID: <3233D27CC5658E4598557F8521F6B07E20F7EC8C81@RIC-MS01.abw.int> Feature request -------------------- Separate the DDL and DML methods generated by ODB into separate source modules. Justification --------------- The management of the database (DDL) and editing of data (DML) needs to be separated into different processes and/or libraries. The files generated by ODB when the schema format is "embedded" contain a number of create_schema() methods that perform DDL like management actions to drop (optionally) and create the required tables, indexes and constraints of the persistent classes in the database. If I want to package my object model classes and ODB generated classes into a library for third party use, the ODB generated classes contain functions that will allow the tables in the database to be dropped and recreated! May not be something you want to provide in a third party library. In addition, for a complex object model with many persistent ODB classes, there is a significant amount for DDL strings in the create_schema() methods that will be stored in the .text segment of the program, and only be used if the database schema needs to be created. (The first time the program is run.) In an embedded environment, this would be a waste of memory. I would expect that during device startup, the database would be checked to see if the Schema is properly initialized. If not, the database schema is created and then the Schema update program exits. The program that is used to manipulate the data model objects can be run, without having all of the DDL statements unnecessarily loaded into the .text segment of that program. From boris at codesynthesis.com Mon Feb 27 08:38:28 2012 From: boris at codesynthesis.com (Boris Kolpackov) Date: Mon Feb 27 08:31:29 2012 Subject: [odb-users] Generate DDL and DML methods in separate output files. In-Reply-To: <3233D27CC5658E4598557F8521F6B07E20F7EC8C81@RIC-MS01.abw.int> References: <3233D27CC5658E4598557F8521F6B07E20F7EC8C81@RIC-MS01.abw.int> Message-ID: Hi Paul, Stath, Paul writes: > Separate the DDL and DML methods generated by ODB into separate source > modules. Yes, I agree this can be useful, especially for embedded systems. I believe just generating the implementation of the create_schema() functions and the catalog registration code into a separate source file (e.g., foo-schema.cxx or foo-odb-schema.cxx) will do the trick here. Do you see any issues with this approach in your use-case? We are planning to build a beta for the upcoming 1.9.0 release later in the week. If you are interested, I could implement this feature before then so that you could give it a try. BTW, another option to handle this would be to generate the schema as a separate SQL file (--schema-format sql). Then you could use the sqlite3 driver to initialize the database, for example: sqlite3 foo.db '.read foo.sql' Boris From pstath at axxcelera.com Mon Feb 27 13:28:33 2012 From: pstath at axxcelera.com (Stath, Paul) Date: Mon Feb 27 13:28:43 2012 Subject: [odb-users] RE: Generate DDL and DML methods in separate output files. In-Reply-To: References: <3233D27CC5658E4598557F8521F6B07E20F7EC8C81@RIC-MS01.abw.int> Message-ID: <3233D27CC5658E4598557F8521F6B07E20F7EC8D24@RIC-MS01.abw.int> I had already thought of the "--schema-format sql" option. I had also thought of generating the code with both embedded and sql arguments and creating two separate libraries. I still would like to use the create_schema() methods to create the database, as well as populate initial default datasets and lookup tables programmatically. I would be very interested in seeing this feature implemented. It would make using ODB in an embedded environment more palatable. > -----Original Message----- > From: Boris Kolpackov [mailto:boris@codesynthesis.com] > Sent: Monday, February 27, 2012 8:38 AM > To: Stath, Paul > Cc: odb-users@codesynthesis.com > Subject: Re: [odb-users] Generate DDL and DML methods in separate > output files. > > Hi Paul, > > Stath, Paul writes: > > > Separate the DDL and DML methods generated by ODB into separate > source > > modules. > > Yes, I agree this can be useful, especially for embedded systems. I > believe just generating the implementation of the create_schema() > functions and the catalog registration code into a separate source > file (e.g., foo-schema.cxx or foo-odb-schema.cxx) will do the trick > here. Do you see any issues with this approach in your use-case? > > We are planning to build a beta for the upcoming 1.9.0 release later > in the week. If you are interested, I could implement this feature > before then so that you could give it a try. > > BTW, another option to handle this would be to generate the schema > as a separate SQL file (--schema-format sql). Then you could use > the sqlite3 driver to initialize the database, for example: > > sqlite3 foo.db '.read foo.sql' > > Boris From boris at codesynthesis.com Tue Feb 28 06:48:23 2012 From: boris at codesynthesis.com (Boris Kolpackov) Date: Tue Feb 28 06:41:24 2012 Subject: [odb-users] Re: Generate DDL and DML methods in separate output files. In-Reply-To: <3233D27CC5658E4598557F8521F6B07E20F7EC8D24@RIC-MS01.abw.int> References: <3233D27CC5658E4598557F8521F6B07E20F7EC8C81@RIC-MS01.abw.int> <3233D27CC5658E4598557F8521F6B07E20F7EC8D24@RIC-MS01.abw.int> Message-ID: Hi Paul, Stath, Paul writes: > I still would like to use the create_schema() methods to create the > database, as well as populate initial default datasets and lookup > tables programmatically. > > I would be very interested in seeing this feature implemented. Ok, I will let you know as soon as I have it ready. > It would make using ODB in an embedded environment more palatable. BTW, if you have any other suggestions/complaints about using ODB in embedded environments, we are all ears. One feature in this area that we are planning to implement for the next release is to make the generation of the session support code optional. Right now it pulls in quite a bit of template code regardless of whether sessions are actually used by the application or not. Boris From wesmharris at gmail.com Wed Feb 29 11:18:07 2012 From: wesmharris at gmail.com (Wesley Harris) Date: Wed Feb 29 11:18:15 2012 Subject: [odb-users] Polymorphic inheritance Message-ID: Hi I noticed that the docs say that polymorphic inheritance is not yet supported. Is there any time frame on when it will be implemented? Thanks! Wesley From boris at codesynthesis.com Wed Feb 29 12:52:39 2012 From: boris at codesynthesis.com (Boris Kolpackov) Date: Wed Feb 29 12:45:23 2012 Subject: [odb-users] Polymorphic inheritance In-Reply-To: References: Message-ID: Hi Wesley, Wesley Harris writes: > I noticed that the docs say that polymorphic inheritance is not yet > supported. Is there any time frame on when it will be implemented? We are actually planning to add this support for the next release and I hope to have something ready to try in a few weeks, if you are interested. Also, there are generally three different approaches to modeling polymorphic inheritance in the database: 1. Table per hierarchy, where all derived objects belonging to a hierarchy are stored in a single table. 2. Table per difference, where additional columns corresponding to the derived classes are stored in additional tables. 3. Table per class, where each class in a hierarchy gets its own independent table that contains all its members. The first approach is the most inflexible: you have to provide the so- called discriminator (basically a value that distinguishes different classes) and the whole hierarchy must be known at compile-time (e.g., reside in a single header or similar). But it is also the most efficient in terms of the database statements that need to be executed. The second and third approaches are more flexible but are generally not as efficient as the first one. Do you have any preference as to which approach would work best in your case? Boris From n.albeza at gmail.com Wed Feb 29 13:07:06 2012 From: n.albeza at gmail.com (Nicolas ALBEZA) Date: Wed Feb 29 13:07:13 2012 Subject: [odb-users] "Dynamic" joins in views Message-ID: Hello odb-users, I was wondering if it was possible to do "dynamic" joins in views, for example, to be able to specify a join condition at runtime, without using native queries. Result SQL query example: select field from t1 left join t2 on (t1.id = t2.t1_id && t2.t3_id = ); -- ALBEZA "Pause" Nicolas From wesmharris at gmail.com Wed Feb 29 13:37:39 2012 From: wesmharris at gmail.com (Wesley Harris) Date: Wed Feb 29 13:37:48 2012 Subject: [odb-users] Polymorphic inheritance In-Reply-To: References: Message-ID: Hi Boris I really like emailing this list: everytime I do, the features I want are in the next release :) Thanks for all your hard work! I would be very interested in trying it out, as the project I am working on requires polymorphic inheritance. For my current needs, table per heirarchy would be fine as the child classes are mainly different in their behavior. That being said, I would prefer the flexibility of the other approaches in the event that TPH does not meet my needs. Thus, for my current project, the flexibility and space saving benifits of table per difference would be most benificial (especially as I am passing off the database access to a background thread to reduce the persistance latency). Looking forward to the release! Wesley On Wed, Feb 29, 2012 at 7:52 PM, Boris Kolpackov wrote: > Hi Wesley, > > Wesley Harris writes: > > > I noticed that the docs say that polymorphic inheritance is not yet > > supported. Is there any time frame on when it will be implemented? > > We are actually planning to add this support for the next release and > I hope to have something ready to try in a few weeks, if you are > interested. > > Also, there are generally three different approaches to modeling > polymorphic inheritance in the database: > > 1. Table per hierarchy, where all derived objects belonging to a > hierarchy are stored in a single table. > > 2. Table per difference, where additional columns corresponding to > the derived classes are stored in additional tables. > > 3. Table per class, where each class in a hierarchy gets its own > independent table that contains all its members. > > The first approach is the most inflexible: you have to provide the so- > called discriminator (basically a value that distinguishes different > classes) and the whole hierarchy must be known at compile-time (e.g., > reside in a single header or similar). But it is also the most > efficient in terms of the database statements that need to be > executed. > > The second and third approaches are more flexible but are generally > not as efficient as the first one. > > Do you have any preference as to which approach would work best in > your case? > > Boris >