[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