[odb-users] Questions and future direction of ODB

[raindog]

Hello,

I wanted to ask several questions about the development of ODB.

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.

2. When will support for stored procedures come?

3. Have you thought about immitating the syntax of LINQ?

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>

5. Comment: Finally a library that imitates STL lowercase naming!

6. Was your goal to have dependencies only on the standard library and 
the various database library front-ends? I say this because of your use 
of std::auto_ptr which makes it difficult to store things in STL containers.

7. Why does retrieving data from the database require being wrapped in a 
transaction?

8. Is this used anywhere in production 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?

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.

11. The limitation with having only one uncached result set per 
transaction, is this a design limitation or database limitation? In an 
application with a large number of concurrent users (website, game 
server, etc), having whole result sets cached can become a huge memory 
overhead.

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.

13. How are relationships treated? It seems like you could just add a 
field to the persistable object for the FK of the relationship and then 
use the load functionality, but in that case it might be quite slow if 
you have returned a large result set and now you need to load 
individually all of the foreign entities one by one.


14. What is the dev roadmap?


Thanks!