[Erlang] ODBC interface to Mnesia

Bruce Fitzsimons Bruce@REDACTED
Sat Aug 28 14:25:37 CEST 1999

Håkan Mattsson wrote in message ...

>A more ambitious approach is to implement an ODBC wrapper for Mnesia.
>As a result of a master thesis we have a SQL compiler which generates
>the internal format of Mnemosyne. The parser accepts the entire syntax
>of SQL, but the rest of the compiler is far from complete. It requires
>a substantial amount of work in order to implement an ODBC complient
>interface to Mnesia, but you are very welcome to make a try.
Thanks, thats all good information for me to use. I think there is some
alternatives to implementing the full SQL syntax in Erlang. They might not
be better alternatives but I don't know until I work through the
implications, and receive some input.

This page: http://www.openlink.co.uk/info/docs/odbcwhp/odbcobj.htm has quite
a good summary of the ODBC architecture in plain english.

Basically it seems that it would be possible to implement an SQL interpreter
in <your choice of language here> as a driver on the client side, and have
the driver use the IIOC interface to the Mnesia Session.

The limitations on this method are basically that I would have to find a way
to represent every type of SQL/ODBC query/action as something in
Mnesia/Mnemosyne. I haven't dug enough to see how well the two map together.

The other thing that I'm still considering is if this should be a
multi-level architecture where I attempt to do all the query processing on
the Erlang/Mnesia side, or simply to extract the data in a more raw form and
do query processing on the client side. There's arguments for both ways - it
depends on what I want to do(processing power of client vs server, datacom
link capacity), and also if I want this to be a generic solution.

I don't really need sub-second performance for my intended application, but
doing the query on the client side doesn't appeal.

Even if I used the SQL parser in Erlang, I still need to define some sort of
custom communications prototocol between the client driver and server
process. This would appear to have to be IIOC or "... yet another back end
for IC ...", with an Erlang server process processing the SQL.

Do you have any more comments on this? I'm still at an architecture level of
design - I think an ODBC interface would be very positive for the growth of
Erlang because it allows admin and reporting interfaces to be written with
familiar Windows tools (or *nix tools, if a compatible driver was written
for it).

You are correct about this being a lot of work. Its a good challenge to get
my teeth into on the fast approaching winter nights.


PS Cross-posted to Erlang-Questions list, please send follow-ups there.

More information about the erlang-questions mailing list