Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!uunet!pilchuck!dataio!gtenmc!fst
From: fst@gtenmc.UUCP (Fariborz "Skip" Tavakkolian)
Newsgroups: comp.lang.c++
Subject: Re: C++ interfaces to Relational Databses.
Summary: Some ideas
Keywords: C++, OOP, OODBMS.
Message-ID: <288@gtenmc.UUCP>
Date: 6 Dec 89 09:18:17 GMT
Organization: GTE Telecom Inc., Bothell, WA
Lines: 75


In article <1989Dec5.010812.3485@sjsumcs.sjsu.edu> horstman@sjsumcs.SJSU.EDU (Cay Horstmann) writes:
>In article <6515@pbhyf.PacBell.COM> mtc@PacBell.COM (Mitchell T. Christensen) writes:
>>
>>
>>	Oracle. 
>>	Is there anyone out there who has solved this problem?
>>
>I'd like to amend this query--does anyone know of some set of classes
>implementing SQL? One could have a table class and overloaded operators
>for the relational operations instead of the yucky SQL syntax. Somewhere
>down the line they should map to embedded SQL queries. Is any such work
>done anywhere?
>Cay Horstmann
>horstman@sjsumcs.sjsu.edu


I have been thinking about a nice way to handle this for some time now.
I am still using embedded SQL in my C++ routines (I think this is my payment
for a past sin).  But here are some untried ideas.

Say you have something like:

    class Query {
    private:
       .
       .
       .
    public:
	Query(char* query_statement);
	~Query();
	prepare();
	execute(char* inputfmt, char *outputfmt, ...);
	...
    };

Then you could do this:

    Query foo("select tabid from systables where tabname = ?");

and then you could invoke Query::prepare() which ``finds out'' (in talking
to db-agent or looking up database catalogs) what is expected as input and
output (i.e. compiling the query) and setup internal storage for it.
Then you could execute the query like so:

    foo.execute("%s", "%d",  "systables", &someintvar);

Where the the number of input and output vars would be variable and dependent
on the query. My main reason for having an input and output format specifier
(a la printf(3), scanf(3)), is the following:  A database type DATE may be
stored as a "long" internally, but you want to be able to compare it to things
like "12/06/89" (i.e. char array), where the internal format does not tell
you what the host variable type may be.

You could also have a class called QueryCursor where you expect to
have a number of retrieved rows:

    QueryCursor xfoo("cursor_name", "select * from systables");

Then you could either have a QueryCursorIterator class (If that makes sense)
or have some member function like:

    QueryCursor::Fetch(DIRECTION sense, char* outputfmt, ...);

(WHERE:    enum DIRECTION { NEXT, PREVIOUS, /* or whatever */ } )

One other class you may need is probably the SimpleStatement class
for things like update, delete, grant, etc.

Hope this helps.

-- 
Fariborz "Skip" Tavakkolian of  Automated Cellular Engineering
Currently consulting at         GTE Telecom, Inc.
Mail                            tiny1!fst@mcgp1 / tiny1!fst@gtenmc / fst@gtenmc