Re: Call for review: Database API for the GNADE Project

[Michael Erdmann <michael.erdmann@snafu.de>]

Nick Roberts schrieb:

> "Michael Erdmann" <michael.erdmann@snafu.de> wrote in message
> news:3C318524.98C9035A@snafu.de...
>
> > > My preference would be for Module SQL (92). Is your API intended to be
> at a
> > > level below this?
> >
> > Please could you clarify this a little bit. The GNADE project already
> provides
> > and embedded SQL preprocessor, so i am not sure what you realy mean by
> > this.
>
> Simply that the choice I would personally prefer (usually) for
> database-access support within Ada programs is Module SQL. I wouldn't mind
> in the least if the same macro/pre-processor approach were taken to the SQL
> module files, e.g. translating them into the equivalent Ada code.

Any how what is Module SQL, do you have link?

> Such Ada code would need to have a low-level method of accessing the
> database(s); I was wondering if the API you are suggesting is intended for
> this purpose (or is it for use directly by application software?).

It is intended for application development.  The idea is to provide a common
interface to access data sources (e.g. Microsoft ADO). In the moment the
proposal is just the smalles possible interface which i think which can be
supported
by most data base products,

> The nice thing about Module SQL is that it does separate the SQL bit from
> the Ada code (unlike Embedded SQL). This means that you could, for example,
> rewrite a module in Ada (e.g. if the data was no longer coming from or going
> into a database), and know that (provided it replicated the behaviour of the
> module's procedures) the rest of the Ada program will be unaffected.

I am still not sure what Module SQL is, but it comes quite near to the idea
of MS ADO, that by changing the query you might use a new data source
without  rewriting the the whole applicaition.

> I must admit, I would like a way -- even if it were a bit yukky -- to add
> datatypes beyond the standard SQL 92 canon.

I think this makes sense because most of the data bases are supporting
a wide variaty of data types. I will check on this!


> Of course lots of SQL3 features
> would be handy, but I get the impression that's an issue (SQL3 has yet to be
> convincingly accepted by the mainstream database companies).

This is to mutch for the first step!

>
>
> --
> Happy New Year,
> Nick Roberts