[odb-users] Questions and future direction of ODB

[Boris Kolpackov]

Hi,

Raindog <raindog at macrohmasheen.com> writes:

> Windows support is being consistently improved. In fact, it compiles  
> very easy out of the box now on windows.

That's good to know, thanks. Just to clarify, is this just the compiler
frontend or the whole toolchain? If it is the toolchain, does it reuse
some existing bits, e.g., from MinGW?


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

The "object-oriented database way" of doing it would be to pull individual
objects into the application's memory and then intersect them there using
C++. The advantage of this approach is that it may reduce the database
load since the processing will be done by the application instead of the
database server. I said "may" because it is also possible that this will
increase the database load if the number of returned objects is large.

But it seems that this is not a very popular approach (you are the second
person who asks for support for joins). So we will need to think of a way
to support this. Maybe something like a read-only, "view object":

#pragma view table("table1", "table2")
class test_view
{
  #pragma column("table1.v1")
  string v1;

  #pragma column("table2.v2")
  string v2;
};

db->query<test_view> (query::v1 == query::v2);

What do you think?


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

Yes, but which functionality will this provide that is not already
possible with the ODB Query Language? Can you give an example?

Plus, Spirit is nice on toy languages. When you need to handle something
non-trivial, things get very complicated very fast (I used Spirit to
create a compiler for CORBA IDL).


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

I am not sure I follow you here. What is important to remember is that
the friend declaration is there not for the ODB compiler but for the
native C++ compiler that will be used to compile the generated code.
So here we would have to modify the hand-written class declarations,
not the generated code.


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

Ok, I guess we need to clarify this in the documentation. Added to the
TODO.


> Yes, but most support returning several result sets at once.

Ok, I will need to look into this in more detail for other databases,
but MySQL definitely doesn't support this.


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

Hm, I see how this can be useful but I don't see how this can be 
implemented in a manageable way. Ideally the ODB compiler would do 
this checking when compiling the header. Automatically connecting
the database doesn't sound like a good idea. Perhaps we could use
a DDL file that was dumped by the database to perform this 
verification. Would this meet your requirements?

Boris