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

["Alex R. Mosteo" <devnull@mailinator.com>]

(back from vacancy)

Maciej Sobczak wrote:

> 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.

I see what you say. My C++ is certainly rusty (not seriously used for some like
4 years), but I remember "fun" times with temporaries. I'm not really prepared
to offer a solution right now, but who knows. I have the gut feeling that
something somewhat similar could be done without incurring in Ada bending, but
I'd need to think it carefully. Likewise I could be wrong, if you have already
devoted some time to this.

(snip)

>> 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.

This is basically what I had in mind.

>> I always end
>> implementing something like that.
> 
> And I've never seen any need for this.

It's certainly not something necessary; it's more a personal preference. I find
more natural to iterate over a matrix. It incurs in some memory overhead, but
for small queries it's OK.

>> 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 likely would, if it were not strictly private... Even so I guess it's more
open to zap something in the database if I make some mistake.

(snip)

Cheers,

Alex.