Re: The future of Ada is at risk

[Georg Bauhaus <rm.tsoh+bauhaus@maps.futureapps.de>]

On Sat, 2008-01-05 at 12:40 +0100, Dmitry A. Kazakov wrote:
> On Sat, 05 Jan 2008 12:11:46 +0100, Georg Bauhaus wrote:
> 
> > For those who have to write portable DB software,
> > and who for some reason must not disclose their software,
> > GNADE is not really an option because it is effectively written
> > in what might be called the GNAT language.
> 
> I think that can be fixed.

Yes. I'm not that sure this is what is wanted...

> > It also uses 64bit types.
> 
> Hmm, how would you deal with SQLBIGINT otherwise?

Using a Big_Integer type corresponding to the DB's big integers
and make SQLBIGINT correspond to this type.
Not straight forward, not nice, not easy, but not impossible.
The GMP library might be of use in several ways.

Currently we have

 type SQLBIGINT    is range -(2 ** 63) .. +(2 ** 63) - 1;
 for SQLBIGINT'Size use 64;

We'd need an alternative user defined type that provides the
integer operations and that can be input from and output to the
DB in the same way.


>  that they pursue a philosophy
> alien to Ada. Rather than to describe a DB in a higher-level way
> independently on the target DB, they try to stay as DB-close as possible.

What would be the higher level? GNADE includes embedded SQL.
While that's not DBI or LINQ, it still offers a nice integration
and is pretty standard.

OTOH, I trust that DBI or JDBC might win a popularity contest.
Or something like SOCI ;-)

Even more higher level bindings hiding the SQL nature
of DB do what they promise. Not what I want because while they offer
high level abstractions, the high level abstractions
should be be problem domain abstractions, not database
abstractions. 

Hypothesis: The more magic is put in the layer above the high
level language SQL, the more difficult it is to actually use
that language, hiding all advantages of SQL[*].

[*] Actually, if you use one of the CRUD frameworks and you
want the effect of an "advanced" SQL command (JOIN, sub-SELECT,
etc.), chances you'll find yourself writing high level SQL
at the low level of the framework...