[odb-users] Support more then one database vendor in a single application?

[Boris Kolpackov]

Hi Oded,

Oded Arbel <oded at geek.co.il> writes:

> I'm writing an application that I want to use with multiple database
> servers, from multiple vendors (actually only two - I use MS-SQL as a
> "serious database" and SQLite for "database server is optional" mode).

This is not yet properly supported by ODB, though it is high up on our
TODO list.


> I was thinking of writing database agnostic model (with some #ifdefs in the
> more hairy parts, though for most cases ODB vendor agnostic pragmas are
> enough), then run the ODB compiler twice to generate two code sets - one
> for each database vendor, then build two DLLs out of the whole shebang and
> load either one in the application depending on the runtime configuration.

That will probably work if you don't use queries. The problem with
queries is that they are a very, very thin layer over the native
SQL queries (and this is done for good reasons, specifically to
minimize code bloat and maintain good performance).

The result of this design is that the actual query code that you
use in your application is very-database specific (i.e., a lot of
database-specific non-virtual/inline functions).

This is actually the biggest obstacle that we need to overcome
in order to provide proper multi-database support. The challenge
here is on the one hand to maintain good performance for applications
that use only one database (probably the majority of them) and on the
other to "abstract" the API sufficiently to allow for multi-database
support.

So if you need queries, the most straightforward approach would
probably be to just build two versions of your application (you
can also have a "starter program" that decided which version to
run). You could also probably go the DLL route, though in this
case you will need to package your whole database-using code 
(and not just the ODB-generated code) into the DLLs.


> The main problem I have is that, building for MS-Windows, I have to use
> __declspec(dllexport) on the model API, and that causes the VC++ compiler
> to get really upset that ODB types do not declare dllexports as well.

That's something that we can fix. However, as I mentioned above, it
probably won't help you much.

Boris