[odb-users] Questions and future direction of ODB

Boris Kolpackov boris at codesynthesis.com
Wed Oct 20 10:07:01 EDT 2010


Raindog <raindog at macrohmasheen.com> writes:
> Right. Which is exactly the point I am saying is not needed. If you are  
> generating code, your code generator can easily determine that you are  
> missing the include, or missing the friend declaration.

Yes, we can detect this. And, perhaps, issue a warning/error.

> The fact that it is needed by the generated code is an implementation 
> detail that the client of ODB should not need to worry about.

I still think we are not on the same page here. The friend declaration
is needed by the generated code so that it can be compiled by the native
compiler. If it were possible to put some magic in the generated code to
make the friend declaration unnecessary, I would be the first person to
advocate for it.

At the moment I don't know any way other than having this declaration
in the hand-written header. And automatically modifying it seems like
too brittle an approach to me.

Or do you see any other way?

> In MS SQL a stored procedure can return several result sets. I think  
> that pgsql has the same ability.

Well, that's not what we need. We need the ability to multiplex result
sets from multiple queries that were initiated at different times.

> I think so, but IMO that would be more complex to parse than just  
> connecting to the database as you will be getting a lot more data than  
> needed, plus, each DB implementation will have slightly different  
> formats.


> I think an alternative is to connect to the database, gather only the
> data you need and store it for later use. 

Yes, that's a pretty good idea. As long as we don't have to have this
in the ODB compiler. I think a separate client for each database system
will be a reasonable approach.

> Maybe I am wrong, but it seems you are really limiting the scope, and  
> therefore overall utility of ODB by not automating as much as possible.

Of course the goal is to automate as much as possible. The difficult
part is to find a way to automate things so that we won't bring more 
problems than we solve. Plus we have to work in the constraints of C++
and performance expectations of C++ developers.


More information about the odb-users mailing list