Re: SOCI-Ada: The Database Access Library for Ada

[Maciej Sobczak <see.my.homepage@gmail.com>]

On 8 Sie, 15:47, "Alex R. Mosteo" <devn...@mailinator.com> wrote:

> I see your reasoning, and I agree it's a good idea to adapt to the particular
> culture surrounding a language, albeit I'm not so sure what's a "valid" Ada
> way. For me, as long as there are no pointers around, it's kinda enough.

:-)

> I personally don't mind some operator overloading in well-defined
> contexts

Note that in the C++ version of SOCI there is also a lot contributed
by temporary objects. For example, here:

int salary;
int id = 123;
sql << "select salary from persons where id = :id",
       into(salary), use(id);

there is a temporary (and invisible) object that has lifetime spanning
to the end of the full expression and that provides a hook for actual
statement execution. The statement cannot be executed before gathering
all the information, including variable binding, and the temporary
object is a nice way to "subscribe" the the end-of-expression point.
This is possible because temporary objects are part of the language
and they have well-defined lifetimes.
I see no way to even come close with Ada.

Another issue is that in Ada operators produce results that need to be
"consumed" (either assigned to something or used in bigger
expressions). This excludes the use of operators at the "top level" of
the statement.
Even something as simple as this:

cout << "Hello";

cannot have a simple equivalent in Ada.

Note that I do not want to imply that C++ is better than Ada in these
examples - everything has its price and the issues with temporary
objects or the ability of the expression results to be silently
ignored create lots of opportunities for problems to creep in. I have
just read a coding standard that forbids operator overloading
whatsoever - and it was justified.

These are just two different language cultures. I don't think it makes
sense to cram one into another - the resulting bricolage might be
indigestible and this is certainly not in the interest of the library.

But I'm open for any suggestions. I just cannot come up with anything
reasonable on my own.

> If I were idle, for example, I'd like some controlled type for
> automatically scoped transactions

Yes, this is a natural candidate.

> and a matrix view of results

Why would you ever want it? The database rowset is not a random-access-
thingy.
Note that at least in theory it might be possible for the database to
produce the result without actually having the full span on the
resulting rowset (and without possibility to rewind back).
If you need a matrix, copy the result (using the batch idiom) to the
matrix created specifically for this purpose.

> I always end
> implementing something like that.

And I've never seen any need for this.

> I have a small project with only a few database queries that now are really
> ugly (because the library I'm using can't bind vars to values and thus there's
> a lot of string concatenation).

Probably it also introduces some security issues.

> It would be a good opportunity for me to clean
> it up and get a feel for SOCI; I'll tell you how it goes if I do it.

Don't hesitate to ask questions if you have any.

--
Maciej Sobczak * www.msobczak.com * www.inspirel.com