SOCI-Ada: The Database Access Library for Ada

SOCI-Ada: The Database Access Library for Ada

[Maciej Sobczak]

I am pleased to announce that the first version of SOCI-Ada is
available to download:

http://www.inspirel.com/soci-ada/

The SOCI-Ada library is built on top of a successful SOCI library that
was written for C++ programmers.
The advantages of SOCI-Ada are:

*  Modular design based on dynamic backend loading. Thanks to this
feature, new backends implemented within the context of the main SOCI
project are immediately available for Ada programmers without any
additional work. A large community of C++ users can help ensure that
the new backends are well tested in a variety of environments and
usage scenarios.

* Native backends for major database servers ensure optimal
performance and minimize configuration overhead and complexity that is
usually associated with other database access methods.

* Direct support for bulk operations allow to achieve high performance
with queries that operate on large data sets.

* Very liberal open-source license (Boost, accepted by Open Source
Initiative) that encourages both commercial and non-commercial use.

* Easy to use and compact interface.

Currently the following backends are available, each communicating
with the database server via its native interface (no ODBC required):

* Oracle
* PostgreSQL
* MySQL

The link above is a starting point for both downloads and online docs,
but I think the best way to attract attention is to show examples of
*full* programs that access a database using this library. Such
examples are available here:

http://www.inspirel.com/soci-ada/doc/idioms.html

This is the first version of the library and as such provides only the
basic functionality, at least when compared with what is available in
the main SOCI project. Your comments are highly welcome and will
certainly contribute to my understanding of what further functionality
would be needed. Support for BLOB is the most likely candidate for
future versions of the library.

All comments welcome.

(BTW - please do not hesitate to contact me in case of any questions
related to the main SOCI project)

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

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

[Alex R. Mosteo]

Maciej Sobczak wrote:

> I am pleased to announce that the first version of SOCI-Ada is
> available to download:
> 
> http://www.inspirel.com/soci-ada/
> 
> The SOCI-Ada library is built on top of a successful SOCI library that
> was written for C++ programmers.
(...)
> The link above is a starting point for both downloads and online docs,
> but I think the best way to attract attention is to show examples of
> *full* programs that access a database using this library. Such
> examples are available here:
> 
> http://www.inspirel.com/soci-ada/doc/idioms.html

Maciej, it looks great. From these examples this library seems right on target,
because of both simplicity and backend transparency.

As for comments for improvement, after a quick read I would like to see one
example on how to use pooled connections.

Another thing is that in C++ there's mimicking of embedded SQL using the "<<"
operator. Can't this be to some extent emulated in Ada with some operator
overloading?

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

[Maciej Sobczak]

On 7 Sie, 17:10, "Alex R. Mosteo" <devn...@mailinator.com> wrote:

> As for comments for improvement, after a quick read I would like to see one
> example on how to use pooled connections.

You can find it in the test program that is included as part of the
package (the archive, not the Ada one :-) ).
I have decided not to include the connection pool example in the
"idioms" part, because connection pools are usually needed in bigger
contexts and the simple example would be artificial - whereas other
examples still make sense, even in such short forms.

I will think about some reasonable example for connection pools.
Again, one is in the test program - it is the last test.

> Another thing is that in C++ there's mimicking of embedded SQL using the "<<"
> operator. Can't this be to some extent emulated in Ada with some operator
> overloading?

I think that the design of the library, including its syntax, needs to
reflect the general spirit of the community that is going to use it.

For example, I find it quite easy to sell this:

int count;
sql << "select count(*) from persons", into(count);

to C++ programmers - for one thing, it looks like streams and indeed
streams can be involved to format parts of the query and in general
the whole statement looks "cool".
An important factor here is that there are lots of C++ libraries that
use operator overloading extensively (including the standard library!)
and that's why C++ programmers can accept this technique even on the
border of abuse.
Please see this page:

http://soci.sourceforge.net/doc/rationale.html

for the rationale of different syntax elements in C++.

Contrary to the above, I think that Ada programmers would find such
syntax "a bit" overboard.
I have decided not to stress the audience with any operator
overloading and provide the "classical" interface that is in line with
the interfaces of other Ada libraries - in particular the standard
library.

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

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

[Alex R. Mosteo]

Maciej Sobczak wrote:

> On 7 Sie, 17:10, "Alex R. Mosteo" <devn...@mailinator.com> wrote:
> 
>> As for comments for improvement, after a quick read I would like to see one
>> example on how to use pooled connections.
> 
> You can find it in the test program that is included as part of the
> package (the archive, not the Ada one :-) ).
> I have decided not to include the connection pool example in the
> "idioms" part, because connection pools are usually needed in bigger
> contexts and the simple example would be artificial - whereas other
> examples still make sense, even in such short forms.
> 
> I will think about some reasonable example for connection pools.
> Again, one is in the test program - it is the last test.
> 
>> Another thing is that in C++ there's mimicking of embedded SQL using the
>> "<<" operator. Can't this be to some extent emulated in Ada with some
>> operator overloading?
> 
> I think that the design of the library, including its syntax, needs to
> reflect the general spirit of the community that is going to use it.
> 
> For example, I find it quite easy to sell this:
> 
> int count;
> sql << "select count(*) from persons", into(count);
> 
> to C++ programmers - for one thing, it looks like streams and indeed
> streams can be involved to format parts of the query and in general
> the whole statement looks "cool".
> An important factor here is that there are lots of C++ libraries that
> use operator overloading extensively (including the standard library!)
> and that's why C++ programmers can accept this technique even on the
> border of abuse.
> Please see this page:
> 
> http://soci.sourceforge.net/doc/rationale.html
> 
> for the rationale of different syntax elements in C++.
> 
> Contrary to the above, I think that Ada programmers would find such
> syntax "a bit" overboard.
> I have decided not to stress the audience with any operator
> overloading and provide the "classical" interface that is in line with
> the interfaces of other Ada libraries - in particular the standard
> library.

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. 

Of course, one can have it in several ways ;) (obviously it requires more
work). I personally don't mind some operator overloading in well-defined
contexts, where there's no risk of confusion. Take a look for example at
Gnat.Spitbol.Patterns, where "&", "*" and "**" are used to great effect: at
first it was a bit surprising but then it is really comfortable. In your case
it wouldn't feel wrong to me, because it's done for a very specific purpose.

In any case we are now icing the cake; I guess that these kinds of high-level
pieces can arrive at a later date if someone has the motivation to contribute
them. If I were idle, for example, I'd like some controlled type for
automatically scoped transactions, and a matrix view of results. I always end
implementing something like that.

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

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

[Maciej Sobczak]

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

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

[Alex R. Mosteo]

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