[odb-users] Questions and future direction of ODB

Raindog raindog at macrohmasheen.com
Mon Oct 18 19:56:47 EDT 2010


On 10/18/2010 9:25 AM, Boris Kolpackov wrote:
> 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.
>    
Windows support is being consistently improved. In fact, it compiles 
very easy out of the box now on windows.

> >  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?
>    
>>  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.

Sorry, I meant something like a use case for #2. If I have a query or 
stored procedure that is not just pulling single entities from a 
database, IE i have several joins, etc, and I want to display these 
results in something like an HTML table, it seems like the current 
feature set makes that complex to do.

>
> >  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++.
>    
If you are being bound to valid syntax of C++, isn't it possible to 
build a DSL on top of something like say, boost.proto similar to how 
boost.spirit is a great way for EBNF in 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.
>
>    
If you already generate code, what harm is there in making it a little 
easier to use by making it harder to forget "boilerplate" code.

> >  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.
>    

Ok, that makes sense, I've just been reading the documentation without 
looking at any of the source to ODB yet.

> >  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.
>    
It is possible in MS SQL, it's just not very easy, hence by abstracting 
the difficulty into a feature of the library, it would be much easier to 
use and rely upon.


> >  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.
>    
Yes, but most support returning several result sets at once.

> >  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?
>    
Yes. This way the user can receive some form of compile time 
verification that his code matches his schema, IE column names, table 
names, etc all match.

> >  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
>
>    



More information about the odb-users mailing list