[odb-users] Questions and future direction of ODB

[Boris Kolpackov]

Hi,

raindog <raindog at macrohmasheen.com> writes:

> 1. Why did you choose the GCC plugin system of clang? At this time clang  
> is supposedly a fully featured C++ compiler that conforms to the  
> standard, it seems like clang was designed specifically for these types  
> of projects.

I assume you mean "GCC plugin system over clang" above. There are several
reasons:

1. When we started working on ODB (which was about a year ago), Clang still
   wasn't a fully-conforming C++ compiler. In fact, the project announced
   full conformity only a couple of weeks ago, which still needs to be 
   tested by real-world usage.

2. As far as I know, Clang is not very well supported on Windows. Its
   primary target is OS X with Linux being an "also supported" platform.

3. GCC is a very mature, cross-platform C++ compiler. While Clang claims
   to provide a conforming C++ frontend, I am not sure about the whole 
   compilation system (runtimes, STL, etc, etc). While in most cases
   ODB only needs a C++ frontend, there are situations where one may
   need a complete C++ compiler on which ODB is based. This, for example,
   would be necessary if persistent classes used headers from another
   library which has to be configured for each specific C++ compiler.
   That's the reason, for example, why pre-compiled binaries for ODB
   include working GCC compiler binaries with all the libraries, etc.

If, however, in the future we see that Clang becomes a better choice
for the C++ compiler frontend, it probably won't be very difficult
to switch since ODB builds its own "semantics graph" from the GCC
syntax tree and generated all the code based on that.


> 2. When will support for stored procedures come?

I am not sure which C++ class constructs would be mapped to stored
procedures. Do you have a sample scenario in mind?


> 3. Have you thought about immitating the syntax of LINQ?

We already do something similar with the ODB Query Language, given
the constraints of C++.


> 4. Can't the ODB code generator insert the "friend class odb::access;"  
> in entities that it finds so that the user does not have to do that?  
> Same with the #include <odb/core.hxx>

While the friend declaration can be annoying, I don't think it is a
good idea for ODB to modify hand-written C++ headers. Plus, there is
no guarantee that the header won't be compiled by the native C++
compiler before ODB had a chance to change it.


> 5. Comment: Finally a library that imitates STL lowercase naming!

Yes, we decided to use the standard C++ naming convention.


> 6. Was your goal to have dependencies only on the standard library and  
> the various database library front-ends?

Yes, we tried to keep the external dependencies to a minimum.


> I say this because of your use of std::auto_ptr which makes it difficult
> to store things in STL containers.

By default, the ODB runtime returns objects as ordinary pointers so you
can use any smart pointer. We use auto_ptr in examples to avoid extra
dependencies (tr1, unfortunately, is not yet portable).

Plus, in the text release of ODB you will be able to specify your own
smart pointer so that if you specify, for example, boost::shared_ptr,
then that's what will be returned by the ODB runtime.


> 7. Why does retrieving data from the database require being wrapped in
> a transaction?

Most database systems that support proper transactions start and
terminate a transaction implicitly even if one is not started explicitly.
The drawback of this is that if you have 5 database operations, there
will be 5 transactions, which is wasteful. Plus, with 5 individual
transactions you don't have the consistent read guarantee. So we decided
to keep it simple and always require a transaction.


> 8. Is this used anywhere in production yet?

Yes, ODB is used in a couple of real-world projects that started "beta-
using" it before the official release.


> 9. What about "paging" (returning a subset of results per query based on  
> some page #) support, some databases have support for it, but others  
> like MS SQL don't, can we emulate that with ODB?

If the underlying database doesn't support this, then it will be hard
to emulate in ODB and hope for any kind of efficiency. On the other
hand, if the underlying database supports this, then it should be
possible to use even now with the native query syntax.


> 10. It looks like ODB will do really well for objects that need  
> persisted, but what about for use cases where we just need to run  
> arbitrary queries for say, generating a table and we don't really need  
> persistent objects for that.

You mean DDL queries? If so, then this is on the TODO list.


> 11. The limitation with having only one uncached result set per  
> transaction, is this a design limitation or database limitation?

It is a database limitation that I think is fairly common. Most database
systems have a notion of a connection and it is impossible to read result
sets for several queries over the same connection at the same time.


> 12. Is it possible for ODB to connect to the database to validate that  
> the persistence code one has written is in some way 'correct', in this  
> case, the transient pragma could be removed or automatically determined.

Hm, do you mean that ODB validates that the persistent class declarations
actually correspond to the database schema?


> 13. How are relationships treated? It seems like you could just add a  
> field to the persistable object for the FK of the relationship and then  
> use the load functionality, but in that case it might be quite slow if  
> you have returned a large result set and now you need to load  
> individually all of the foreign entities one by one.

Yes, that is the recommended way to handle this in the meantime. Proper
support for relationships is coming in the next version.


> 14. What is the dev roadmap?

The next release, due mid-to-end-November, will add support for relationships
and containers. In subsequent versions we will be adding support for other
database systems (PostgreSQL, SQLite, Oracle are all in the pipeline) plus
additional features based on developer feedback, just like yours ;-)

Boris