[odb-users] Questions and future direction of ODB
raindog at macrohmasheen.com
Mon Oct 18 19:56:47 EDT 2010
On 10/18/2010 9:25 AM, Boris Kolpackov wrote:
> 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
> 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 ;-)
More information about the odb-users