ANN: Introducing AdaBase - Thick database bindings for Ada

ANN: Introducing AdaBase - Thick database bindings for Ada

[jrmarino]

Hey guys, I know there are several options for Ada to interface with databases, but I wasn't happy with any of them for various reasons and thus created yet another option to scratch my itch.  I was aiming at a consistent interface to which the various drivers adapt.  With some care, the database backends should be interchangeable.

So far I've created drivers for MySQL and SQLite and the driver for PostgreSQL is next on my list.  I'd like to eventually support others such as Firebird, MSSQL, Oracle, etc., but those will be very low priority for me over the next year.  Contributions are welcome of course -- It's been released under the developer- and commercial-friendly ISC licence.

I've spent a lot of time documenting the interface and providing a lot of real examples.  If you are at all looking for something like this, I recommend that you spend a few minutes going through the descriptions and examples of all the functions:

http://jrmarino.github.io/AdaBase/

It's been developed on DragonFly and FreeBSD, and I haven't tested it on Windows yet, but I will.  it's already available for BSD users, see: http://www.freshports.org/databases/adabase

I believe AdaBase is already mature for MySQL and SQLite, but reports of issues will be welcome.  I'm active on github, so issues and pull requests will be dispositioned quickly if you wish to leverage those tools.

Hopefully other people will find this project useful!

--  John

Re: ANN: Introducing AdaBase - Thick database bindings for Ada

[Per Sandberg]

Reflection.

Why could we not try to agree on one implementation on bindings to 
databases and collaborate instead of writing my-own since I'm so bloody 
good,

Unfortunate that goes for the whole software industry, and it gives 
enormous power to anyone that could get 10 strong persons to collaborate.

/P


Den 2016-05-13 kl. 22:37, skrev jrmarino:
> Hey guys, I know there are several options for Ada to interface with databases, but I wasn't happy with any of them for various reasons and thus created yet another option to scratch my itch.  I was aiming at a consistent interface to which the various drivers adapt.  With some care, the database backends should be interchangeable.
>
> So far I've created drivers for MySQL and SQLite and the driver for PostgreSQL is next on my list.  I'd like to eventually support others such as Firebird, MSSQL, Oracle, etc., but those will be very low priority for me over the next year.  Contributions are welcome of course -- It's been released under the developer- and commercial-friendly ISC licence.
>
> I've spent a lot of time documenting the interface and providing a lot of real examples.  If you are at all looking for something like this, I recommend that you spend a few minutes going through the descriptions and examples of all the functions:
>
> http://jrmarino.github.io/AdaBase/
>
> It's been developed on DragonFly and FreeBSD, and I haven't tested it on Windows yet, but I will.  it's already available for BSD users, see: http://www.freshports.org/databases/adabase
>
> I believe AdaBase is already mature for MySQL and SQLite, but reports of issues will be welcome.  I'm active on github, so issues and pull requests will be dispositioned quickly if you wish to leverage those tools.
>
> Hopefully other people will find this project useful!
>
> --  John
>

Re: ANN: Introducing AdaBase - Thick database bindings for Ada

[Randy Brukardt]

"Per Sandberg" <per.s.sandberg@bahnhof.se> wrote in message 
news:8VrZy.128683$4%6.19185@fx28.fr7...
> Reflection.
>
> Why could we not try to agree on one implementation on bindings to 
> databases and collaborate instead of writing my-own since I'm so bloody 
> good,

Impossible, I fear. I tried that with Claw, but even having a several year 
head start didn't prevent someone from making their own incompatible 
version.

On top of which:

(1) One size does not fit all. Especially when it comes to tasking (it was 
the handling of tasking issues in Claw that was one of the major reasons for 
David Botton making his own binding).

(2) Collaboration is hard, especially if one wants to come up with a 
consistent interface. You really need a strong presence at the center of the 
work in order to keep everything on track.

(3) A lot of people find these projects fun (for some definition of fun). 
How do you stop people from having fun (even if that fun isn't in the best 
interests of Ada)?

                        Randy.

Re: ANN: Introducing AdaBase - Thick database bindings for Ada

[gautier_niouzes]

Le samedi 14 mai 2016 01:37:02 UTC+2, Randy Brukardt a écrit :

> Impossible, I fear. I tried that with Claw, but even having a several year 
> head start didn't prevent someone from making their own incompatible 
> version.

And in retrospect, it was a good thing: since around 2000, GWindows [1] is the only Ada thick binding for Windows maintained, developed, and usable for real applications (just tested the 3rd one, JEWL [2]; builds and runs fine, but very limited beyond demos or toy projects).

G.
__
[1] https://sourceforge.net/projects/gnavi/
[2] http://archive.adaic.com/tools/bindings/JEWL/jewl.html

Re: ANN: Introducing AdaBase - Thick database bindings for Ada

[Randy Brukardt]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 2034 bytes --]


<gautier_niouzes@hotmail.com> wrote in message 
news:f1c76310-e74f-4734-9961-5743e877b5e2@googlegroups.com...
>Le samedi 14 mai 2016 01:37:02 UTC+2, Randy Brukardt a écrit :

>> Impossible, I fear. I tried that with Claw, but even having a several 
>> year
>> head start didn't prevent someone from making their own incompatible
>> version.
>
>And in retrospect, it was a good thing: since around 2000, GWindows [1] is
>the only Ada thick binding for Windows maintained, developed, and usable
>for real applications (just tested the 3rd one, JEWL [2]; builds and runs 
>fine,
>but very limited beyond demos or toy projects).

Not remotely true (except the point about JEWL - but it was always intended 
to be easy rather than powerful).

(1) Plenty of real-world projects use/used Claw - I haven't asked for 
permission to talk about customers projects, but we've used it for the 
Trash-Finder UI, for the Claw Builder itself (a *very* tough task for an 
interface library), and a variety of internal tools.
(2) Claw was actively developed for many years after 2000, and still is 
actively maintained now. (Not doing much development because of lack of 
demand.)
(3) The above of course is a self-fufilling prophecy; once the split 
happened, the community had to make a choice and the effect was to duplicate 
all of the effort spent on Claw. The same effort could have been spent on 
enhancing Claw and more good stuff would have been available.

At least Claw was not a total waste of time: (1) it toughened up the OOP and 
finalization support in Ada compilers, so GWindows and the like were even 
possible. (When we started with Claw, most of our code didn't work on early 
Ada 95 compilers for one reason or another.) (2) Claw.Directories turned 
into Ada.Directories, and Claw.Time turned into Ada.Calendar.Arithmetic and 
Ada.Calendar.Formatting - so those things are now available to all Ada 
programmers. Too bad that I could never get Ada.Sockets (after Claw.Sockets) 
off the ground.

                           Randy.

Re: ANN: Introducing AdaBase - Thick database bindings for Ada

[gautier_niouzes]

> (2) Claw was actively developed for many years after 2000, and still is 
> actively maintained now. (Not doing much development because of lack of 
> demand.)

That's great news!
Unfortunately search engines lead potential CLAW users wanting to have a glimpse, to this page:
  http://www.rrsoftware.com/html/prodinf/claw/clawintro.html
where all demo material is time-stamped with year 2000 (more problematic:
a build with GNAT fails with an elaboration circularity).
Is there another page with a more recent version of Claw Introductory Edition ?

> (3) The above of course is a self-fufilling prophecy; once the split 
> happened, the community had to make a choice and the effect was to duplicate 
> all of the effort spent on Claw. The same effort could have been spent on 
> enhancing Claw and more good stuff would have been available.

More than often duplication of effort leads to better results than a centralized development.
It is not logical, but it is how it works with human beings...
_________________________ 
Gautier's Ada programming 
http://gautiersblog.blogspot.com/search/label/Ada 
NB: follow the above link for a valid e-mail address 

Re: ANN: Introducing AdaBase - Thick database bindings for Ada

[G.B.]

On 17.05.16 09:35, gautier_niouzes@hotmail.com wrote:
> GNAT fails with an elaboration circularity

A guess: try -gnatE

Re: ANN: Introducing AdaBase - Thick database bindings for Ada

[Randy Brukardt]

"G.B." <bauhaus@futureapps.invalid> wrote in message 
news:nheojd$3me$1@dont-email.me...
> On 17.05.16 09:35, gautier_niouzes@hotmail.com wrote:
>> GNAT fails with an elaboration circularity
>
> A guess: try -gnatE

Correct. There is a FAQ that mentions that (and some alternative 
workarounds).

I do need to package up a more recent version of the Intro version, but it 
hasn't been a priority. (I need to package a new version of the full Claw, 
too, and that ought to be done first. But I'm kinda stuck on some Windows 7 
issues with the Builder, gotta work those out first.)

                              Randy.

Re: ANN: Introducing AdaBase - Thick database bindings for Ada

[David Botton]

On Friday, May 13, 2016 at 7:37:02 PM UTC-4, Randy Brukardt wrote:
> Impossible, I fear. I tried that with Claw, but even having a several year 
> head start didn't prevent someone from making their own incompatible 
> version.

Being the principle author of that "incompatible version" (that's cute as implies CLAW had some sort of foot hold which it didnt't) the chief reason was the incompatible license CLAW had.

BTW Windex proceeded my efforts and had a license that was compatible but it would have been too difficult to add the event model I needed to support ActiveX and the Delphi style of programming (that model is preserved in GNOGA).

CLAW is a great example of a fantastic product that had the right license been in place would have been extended and become the standard for Windows and Ada that GWindows became. Much the story of Ada as a whole had the licensing not been played with the community would have grown instead of shrink.

David Botton

Re: ANN: Introducing AdaBase - Thick database bindings for Ada

[Dmitry A. Kazakov]

On 2016-05-13 22:37, jrmarino wrote:
> Hey guys, I know there are several options for Ada to interface with
> databases, but I wasn't happy with any of them for various reasons and
> thus created yet another option to scratch my itch. I was aiming at a
> consistent interface to which the various drivers adapt. With some care,
> the database backends should be interchangeable.

Under database you understand a relational database, furthermore one of 
SQL. And that "SQL" limited to some unstated subset, an empty subset, if 
you want it interchangeable...

I am afraid, such efforts are futile, even when massively funded with 
resources, as ODBC perfectly illustrates.

And, of course, the "thickness" of sending SQL statements as strings is 
up to discussion...

In my opinion the approach is unrealistic. It is technically impossible 
to deal with a *legacy* database in a DBMS-independent manner. It was 
not designed to have this. Neither it is really interesting for Ada 
projects that wished to use a DB. Such projects would most likely create 
a new DB from scratch. Therefore they would be perfectly served by a 
persistency layer for Ada objects, with no traces of SQL, DB-specific 
data types and other mess.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: ANN: Introducing AdaBase - Thick database bindings for Ada

[jrmarino]

On Saturday, May 14, 2016 at 8:23:18 AM UTC+2, Dmitry A. Kazakov wrote:
> Under database you understand a relational database, furthermore one of 
> SQL. And that "SQL" limited to some unstated subset, an empty subset, if 
> you want it interchangeable...

Yes, I mean SQL relational databases.


> I am afraid, such efforts are futile, even when massively funded with 
> resources, as ODBC perfectly illustrates.
> 
> And, of course, the "thickness" of sending SQL statements as strings is 
> up to discussion...

Some of the SQL statements are constructed, tailored to driver.  You can send raw strings if you want, but that limits portability.  Using the abstraction features improves portability.  But yes, if one wants to have interchangeable backends, they need to be smart about it, but the subset is definitely not empty, far from it.


> In my opinion the approach is unrealistic. It is technically impossible 
> to deal with a *legacy* database in a DBMS-independent manner. It was 
> not designed to have this. Neither it is really interesting for Ada 
> projects that wished to use a DB. Such projects would most likely create 
> a new DB from scratch. Therefore they would be perfectly served by a 
> persistency layer for Ada objects, with no traces of SQL, DB-specific 
> data types and other mess.

Well, Dmitry, AdaBase exists now.  You've focused on the "possiblity of interchangeable backends" as the main design driver which of course it was not.  The main objective is constant API which behaves identically no matter which backend is chosen.

Guys, nobody has to use this.  I created it for me because none of the existing ones were satisfactory *to me*.  It's under a permissive license.  I'm just sharing.  I get the idea that people are posting opinions without actually reviewing the documention (which I spent many many hours writing).  In any case, all I am doing is letting people know a new non-copyleft option exists with the assumption that some people will be interested.  

Re: ANN: Introducing AdaBase - Thick database bindings for Ada

[Björn Lundin]

On 2016-05-14 12:41, jrmarino wrote:
> Guys, nobody has to use this.  I created it for me because none of the existing ones were satisfactory *to me*. 
> It's under a permissive license.  I'm just sharing. 
> I get the idea that people are posting opinions without actually reviewing the documention
> (which I spent many many hours writing).  
> In any case, all I am doing is letting people know a new non-copyleft option exists with the assumption that some people will be interested.  

I like the idea. Not too many discussions about Ada here is about using
it with an sql-database. I use them all the time - I guess that is a
design pattern I'm used to. And not too many good solutions exits.
Most packages lacks some datatype, like date/time/timestamp, or clobs,
or something else.

I will certainly have a look and see how you solve 'prepare' for
PostgreSQL, when you are done.

As is, I got a fair bit of code using my own binding.
If the api is close enough to what I use now,
I sure will consider switch.

If I can't, then looking at other peoples's code gives new ideas.

And hearing that there is a good set of documentation is always nice.

--
Björn

Re: ANN: Introducing AdaBase - Thick database bindings for Ada

[Jeffrey R. Carter]

On 05/14/2016 03:41 AM, jrmarino wrote:
>
> Guys, nobody has to use this.  I created it for me because none of the
> existing ones were satisfactory *to me*.  It's under a permissive license.
> I'm just sharing.  I get the idea that people are posting opinions without
> actually reviewing the documention (which I spent many many hours writing).
> In any case, all I am doing is letting people know a new non-copyleft option
> exists with the assumption that some people will be interested.

I haven't looked at this, but I'd like to thank you for your effort. Accessing 
DBs is a difficult problem, given the many mismatches between Ada and SQL, but 
one that must frequently be addressed. We have no agreement on good ways to do 
it. Maybe we never will, but having multiple approaches might help reach some 
consensus, or at least increase the chances of a project being able to find an 
existing approach that seems right to them.

My experience is that you should completely hide the fact that you're using an 
external DB. Anything else leads to dependencies that bite you when you try to 
change the actual storage, as frequently happens. No binding achieves that for you.

-- 
Jeff Carter
"I'm off to Alaska. If you need me, I'll be at
Frozen Tundra 6-9290."
Play It Again, Sam
130

Re: ANN: Introducing AdaBase - Thick database bindings for Ada

[AdaMagica]

Am Freitag, 13. Mai 2016 22:37:16 UTC+2 schrieb jrmarino:
> I've spent a lot of time documenting the interface and providing a lot of real examples.  If you are at all looking for something like this, I recommend that you spend a few minutes going through the descriptions and examples of all the functions:

Hm, I personally have never worked with databases. So if the need arose, I'd look for some introduction about how to use the database. There is none.

Browsing your site, I see an "Introduction", which is just some kind of "Welcome". And then a list of a plethora of seemingly unordered procedures and functions I have no idea about what they do and how to use them.

I'm missing some introductory pages about "Where to begin and how to use this database interface".

To be more specific:
The documentatin should provide all the package specifications and descriptions in a way similar to the Ada RM.

Ask yourself: Would you be able to use the Ada container library if there were only a list of all subprograms and their descriptions?

I very much appreciate your detailed description of each single subprogram and even usage examples. This surely was a lot of work and is much more than one can find on most Ada sites! But I direly need a map of the paths through this jungle.

Re: ANN: Introducing AdaBase - Thick database bindings for Ada

[Georg Bauhaus]

On 14.05.16 14:22, AdaMagica wrote:
> I'm missing some introductory pages about "Where to begin and how to use this database interface".

I've felt at home immediately. It's a binding! It is using
standards based technology, vocabulary and syntax. Even ISO
standards based.

However, maybe I felt at home because relational databases
form a larger part of my day job.
Storage and retrieval of relational data using SPARK like
predicates — one could call them that, tables and joins and
projections and restrictions and so forth being logic made
operational.

So, I'd consider that readers of the site might even take offense
at being directed towards an introduction to relational databases
and related theory.

Last but not least, I don't really understand the presumption
that 40+ years of developing technology for managing substitution
instances of truth-valued predicates in a systematic, concurrent
fashion is somehow not worth being considered. Or why, of necessity,
all of this should be replaced with simple record storage and some
ad-hoc, idiosyncratic subprograms for managing them. Is everything
embedded really so special?

The fact that SQL is a vendor run ISO standardization business is
related matter. But it is not stopping portability entirely.

-- 
"HOTDOGS ARE NOT BOOKMARKS"
Springfield Elementary teaching staff

Re: ANN: Introducing AdaBase - Thick database bindings for Ada

[Dmitry A. Kazakov]

On 2016-05-14 15:27, Georg Bauhaus wrote:

> Last but not least, I don't really understand the presumption
> that 40+ years of developing technology for managing substitution
> instances of truth-valued predicates in a systematic, concurrent
> fashion is somehow not worth being considered. Or why, of necessity,
> all of this should be replaced with simple record storage and some
> ad-hoc, idiosyncratic subprograms for managing them. Is everything
> embedded really so special?

Because there is no best single method of storing data (container for 
all cases and all sizes). Relational DB are suboptimal to drastically 
inefficient in most cases. Not that performance was real concern behind 
relational approach. It rather was an ability to access the DB by 
submitting queries, skipping any application if necessary or using quite 
generic applications. Not good engineering, at least.

The approach proved successful (in terms of monetizing) but I would 
challenge naming it "40+ years of developing technology."

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: ANN: Introducing AdaBase - Thick database bindings for Ada

[Shark8]

On Saturday, May 14, 2016 at 7:27:52 AM UTC-6, Georg Bauhaus wrote:
> 
> The fact that SQL is a vendor run ISO standardization business is
> related matter. But it is not stopping portability entirely.

If we're being fair, the reason that the SQL ISO is a failure as a standard is precisely because it has so many optional features (and alternate syntax forms) that it's rather common that two implementations would reject each other's SQL-statements for any non-trivial operation.

Re: ANN: Introducing AdaBase - Thick database bindings for Ada

[Björn Lundin]

On 2016-05-15 15:59, Shark8 wrote:
> On Saturday, May 14, 2016 at 7:27:52 AM UTC-6, Georg Bauhaus wrote:
>>
>> The fact that SQL is a vendor run ISO standardization business is
>> related matter. But it is not stopping portability entirely.
> 
> If we're being fair, the reason that the SQL ISO is a failure as a standard 
>is precisely because it has so many optional features (and alternate syntax forms)
> that it's rather common that two implementations would reject each other's
> SQL-statements for any non-trivial operation.

Does that matter in practice ?
I've ported a system with 700-800 sql-statements from
Oracle to MS Sql Server
where all of them where one of

*select
*insert
*update
*delete


(and 500 + are not trivial - inner and/or outer joins, sub-selects,
aggregates and so on)

I ended up with looking at what database is in use at 1 single statement.

Oracle calls it substr
and MS sql server calls it substring

I find it harsh to call that a failure.

Sure, the creation of tables/indexes/views are all different,
but that is of no significance (at least to me)

--
Björn

Re: ANN: Introducing AdaBase - Thick database bindings for Ada

[Shark8]

On Sunday, May 15, 2016 at 11:03:29 AM UTC-6, björn lundin wrote:
> On 2016-05-15 15:59, Shark8 wrote:
> > On Saturday, May 14, 2016 at 7:27:52 AM UTC-6, Georg Bauhaus wrote:
> >>
> >> The fact that SQL is a vendor run ISO standardization business is
> >> related matter. But it is not stopping portability entirely.
> > 
> > If we're being fair, the reason that the SQL ISO is a failure as a standard 
> >is precisely because it has so many optional features (and alternate syntax forms)
> > that it's rather common that two implementations would reject each other's
> > SQL-statements for any non-trivial operation.
> 
> Does that matter in practice ?
> I've ported a system with 700-800 sql-statements from
> Oracle to MS Sql Server
> where all of them where one of
> 
> *select
> *insert
> *update
> *delete
> 
> 
> (and 500 + are not trivial - inner and/or outer joins, sub-selects,
> aggregates and so on)
> 
> I ended up with looking at what database is in use at 1 single statement.
> 
> Oracle calls it substr
> and MS sql server calls it substring
> 
> I find it harsh to call that a failure.
> 
> Sure, the creation of tables/indexes/views are all different,
> but that is of no significance (at least to me)
> 
> --
> Björn

Yes, it does matter.
Just look at these popular implementations compared against the standard: http://troels.arvin.dk/db/rdbms/

Re: ANN: Introducing AdaBase - Thick database bindings for Ada

[AdaMagica]

Am Samstag, 14. Mai 2016 15:27:52 UTC+2 schrieb Georg Bauhaus:
> On 14.05.16 14:22, AdaMagica wrote:
> > I'm missing some introductory pages about "Where to begin and how to use this database interface".
> 
> I've felt at home immediately. It's a binding! It is using
> standards based technology, vocabulary and syntax. Even ISO
> standards based.
> 
> However, maybe I felt at home because relational databases
> form a larger part of my day job.
> Storage and retrieval of relational data using SPARK like
> predicates — one could call them that, tables and joins and
> projections and restrictions and so forth being logic made
> operational.
> 
> So, I'd consider that readers of the site might even take offense
> at being directed towards an introduction to relational databases
> and related theory.

I do not see how presence of some documentation should or could offend someone already knowing about how to do it. As I said, I have no idea of RDB. I would have to learn, as it seems, two interfaces, the binding and the interface it binds to. As I understand your description, they differ.

If I wasn't clear enough about appreciating your fine work, I appologize. I thought my last sentence made this clear.

Re: ANN: Introducing AdaBase - Thick database bindings for Ada

[jrmarino]

On Sunday, May 15, 2016 at 4:23:04 PM UTC+2, AdaMagica wrote:
> 
> I do not see how presence of some documentation should or could offend someone already knowing about how to do it. As I said, I have no idea of RDB. I would have to learn, as it seems, two interfaces, the binding and the interface it binds to. As I understand your description, they differ.
> 
> If I wasn't clear enough about appreciating your fine work, I appologize. I thought my last sentence made this clear.

I think you lost track of who you are talking to.  George is not the author; I am.
However, he's spot on.  You've circled a target audience that of A) has no SQL database knowledge whatsoever and B) is an Ada user.  People in that union are not my targets.

More over, an analogous work for PHP is PDO (PHP data objects) and nowhere in their documentation do they try to test potential users the fundamentals of SQL relational databases (see http://php.net/manual/en/intro.pdo.php).  They have books for that sort of thing and it's way out of scope for what I wish to document.   People need these fundamentals long before they should attempt to interface a database programmatically (in any language).

I feel comfortable that users that already have populated databases that they want to interface with programmatically and can already do interactively clients will have no problems with the current level of documentation.

Re: ANN: Introducing AdaBase - Thick database bindings for Ada

[Olivier Henley]

Thank you. I checked the doc and I find it awesome.

Re: ANN: Introducing AdaBase - Thick database bindings for Ada

[Anh Vo]

On Friday, May 13, 2016 at 1:37:16 PM UTC-7, jrmarino wrote:
> Hey guys, I know there are several options for Ada to interface with databases, but I wasn't happy with any of them for various reasons and thus created yet another option to scratch my itch.  I was aiming at a consistent interface to which the various drivers adapt.  With some care, the database backends should be interchangeable.
> 
> So far I've created drivers for MySQL and SQLite and the driver for PostgreSQL is next on my list.  I'd like to eventually support others such as Firebird, MSSQL, Oracle, etc., but those will be very low priority for me over the next year.  Contributions are welcome of course -- It's been released under the developer- and commercial-friendly ISC licence.
> 
> I've spent a lot of time documenting the interface and providing a lot of real examples.  If you are at all looking for something like this, I recommend that you spend a few minutes going through the descriptions and examples of all the functions:
> 
> http://jrmarino.github.io/AdaBase/
> 
> It's been developed on DragonFly and FreeBSD, and I haven't tested it on Windows yet, but I will.  it's already available for BSD users, see: http://www.freshports.org/databases/adabase
> 
> I believe AdaBase is already mature for MySQL and SQLite, but reports of issues will be welcome.  I'm active on github, so issues and pull requests will be dispositioned quickly if you wish to leverage those tools.
> 
> Hopefully other people will find this project useful!
> 
> --  John

Thank you for sharing your work with others.

I am a newbie when it comes to database. Your work is a perfect start for me. I just finished building your bindings on Windows. I will try on my Linux box later.

My first test was on fruit1.gpr. When running I got error message "raised ADABASE.ERRMODE_EXCEPTION : Failed to connect to file:///home/marino/adabase.sqlite". Look like most of the tests depended on /home/marino/adabase.sqlite file. 

Is there any way you can put it on GitHub? Thanks.

Anh Vo

Re: ANN: Introducing AdaBase - Thick database bindings for Ada

[jrmarino]

On Wednesday, May 18, 2016 at 7:13:01 PM UTC+2, Anh Vo wrote: 
> My first test was on fruit1.gpr. When running I got error message "raised ADABASE.ERRMODE_EXCEPTION : Failed to connect to file:///home/marino/adabase.sqlite". Look like most of the tests depended on /home/marino/adabase.sqlite file. 
> 
> Is there any way you can put it on GitHub? Thanks.

It is only located in one place: GitHub.
The documentation are "github pages" which means the website itself is part of the repository (located in the gh-pages branch).  At the top of every pages are 4 hyperlinks, the second of which is called, "View on github".  Clicking on it brings the user to https://github.com/jrmarino/AdaBase .  So wish granted. :)

Secondly, if you are trying to run the test cases you have to first import the given data dumps into the database and then update the testcases/driver_connections/*/connect.adb to match your particular setup.

So in your sqlite case, find the file "testcases/dumps/adabase_examples.sqlite.sql" and create an sqlite database with it, and update "testcases/driver_connections/sqlite/connect.adb" accordingly.

-- John

Re: ANN: Introducing AdaBase - Thick database bindings for Ada

[Martin]

On Friday, May 13, 2016 at 9:37:16 PM UTC+1, jrmarino wrote:
[snip]
> --  John

John, firstly thanks for the effort put into this and I hope it isn't just yourself that finds this useful after all your effort.

I hope this doesn't sound too negative after that but I do find it quite an "un-Ada"-ish binding. All languages come with their own look and feel, some even enforced at compile-time and Ada is no exception but you don't seem to have followed standard Ada conventions (which GNAT can do a great job of helping you enforce).

Two examples - firstly, words are encouraged to be separated by an underscore; secondly, there is no need to add a common prefix to enumerates (and confusingly this is done for some enumeration types but not others).

If there is an Ada-look release, I'll come back and have another look at using it but not til then.
-- Martin

Re: ANN: Introducing AdaBase - Thick database bindings for Ada

[jrmarino]

On Friday, May 20, 2016 at 5:18:02 PM UTC+2, Martin wrote:
> Two examples - firstly, words are encouraged to be separated by an underscore; 

I honestly have no idea what you are referencing here.

> secondly, there is no need to add a common prefix to enumerates (and confusingly this is done for some enumeration types but not others).

Really?  "No need"?

This compiles:
package Martin is
  type field_types is (ft_nbyte1, ft_nbyte2);
  type nbyte1 is mod 2 ** 8;
  type nbyte2 is mod 2 ** 16;
end Martin;

This doesn't:
package Martin is
  type field_types is (nbyte1, nbyte2);
  type nbyte1 is mod 2 ** 8;
  type nbyte2 is mod 2 ** 16;
end Martin;


> If there is an Ada-look release, I'll come back and have another look at using it but not til then.

It sounds like you are saying this in the context of endorsement or certification, meaning that I'll be worse off somehow if I fail to take corrective action.

I guess I would respond that if the lack of underscores or presence of prefixes in AdaBase causes disgust that exceeds its usefulness then it's probably not very useful.  I've made it public in the hopes that some people will find it useful with the additional benefit that those people might help by reporting issues and/or contributing new features or bug fixes, but if that doesn't materialize, that's okay.  I won't have lost anything in the process.

Re: ANN: Introducing AdaBase - Thick database bindings for Ada

[Jeffrey R. Carter]

On 05/20/2016 10:44 AM, jrmarino wrote:
> On Friday, May 20, 2016 at 5:18:02 PM UTC+2, Martin wrote:
>> Two examples - firstly, words are encouraged to be separated by an underscore;
>
> I honestly have no idea what you are referencing here.

Identifiers such as Adabase and Tisokeywords. The "Ada Way" is Ada_Base and 
ISO_Keyword_List. Similarly, "read_uncommitted" and the like would be 
"Read_Uncommitted".

> Really?  "No need"?
>
> This compiles:
> package Martin is
>   type field_types is (ft_nbyte1, ft_nbyte2);
>   type nbyte1 is mod 2 ** 8;
>   type nbyte2 is mod 2 ** 16;
> end Martin;
>
> This doesn't:
> package Martin is
>   type field_types is (nbyte1, nbyte2);
>   type nbyte1 is mod 2 ** 8;
>   type nbyte2 is mod 2 ** 16;
> end Martin;

Really. These are terrible naming schemes. With a little thought you can come up 
with something better. I'd probably use something like

package Martin is
    type Field_Size_ID is (One_Byte, Two_Bytes);

    type Unsigned_One_Byte  is mod 2 **  8;
    type Unsigned_Two_Bytes is mod 2 ** 16;
end Martin;

-- 
Jeff Carter
"Run away! Run away!"
Monty Python and the Holy Grail
58

Re: ANN: Introducing AdaBase - Thick database bindings for Ada

[jrmarino]

On Friday, May 20, 2016 at 10:36:26 PM UTC+2, Jeffrey R. Carter wrote:
> Identifiers such as Adabase and Tisokeywords. The "Ada Way" is Ada_Base and 
> ISO_Keyword_List. Similarly, "read_uncommitted" and the like would be 
> "Read_Uncommitted".

Ada_Base would be wrong because it's AdaBase, by definition.  It's not two words.  The only difference with "read_uncommitted" is the capitalization.  So basically the assertion here is that if somebody chooses not to capitalize enumerations, it's not Ada-like?  I'll give you Tisokeywords but I had no idea people were anal about this sort of thing (And I'll point out that I use underscores overwhelmingly, so a minority of cases where I didn't shouldn't invalidate the whole thing)

But frankly, not using a library because somebody doesn't subscribe to the same style guide in every aspect is bit over the top, no?

> 
> Really. These are terrible naming schemes. With a little thought you can come up 
> with something better. I'd probably use something like
> 
> package Martin is
>     type Field_Size_ID is (One_Byte, Two_Bytes);
> 
>     type Unsigned_One_Byte  is mod 2 **  8;
>     type Unsigned_Two_Bytes is mod 2 ** 16;
> end Martin;

Subjective.  I think your suggestions are worse (honestly, not lashing out) plus they aren't even feasible because there are actually signed versions too (so ambiguous).  Why should the type names have to suffer to avoid a prefix on an enumeration?  But we're talking about opinions here and the subjective criticism seems to be about my naming choice.

To summarize:
1) suggesting re-capitalization is okay and somebody that really cared even could provide a git pull request to speed that along
2) Suggesting to rename types and enumerations to break all programs currently using the library is a much bigger deal and what's the benefit?

Re: ANN: Introducing AdaBase - Thick database bindings for Ada

[Jeffrey R. Carter]

On 05/20/2016 04:44 PM, jrmarino wrote:
>
> Ada_Base would be wrong because it's AdaBase, by definition. It's not two
words. The only difference with "read_uncommitted" is the capitalization. So
basically the assertion here is that if somebody chooses not to capitalize
enumerations, it's not Ada-like? I'll give you Tisokeywords but I had no idea
people were anal about this sort of thing (And I'll point out that I use
underscores overwhelmingly, so a minority of cases where I didn't shouldn't
invalidate the whole thing)

If it's one word, then it should be Adabase. CamelCase is antithetical to some 
basic Ada concepts, case insensitivity being one. Remember that many of us use 
language-sensitive editors that will recapitalize identifiers when we load a 
file. Resulting identifiers like Tisokeywords will be difficult to figure out 
and understand. Enough of them may make it difficult enough to use your library 
that people won't.

I doubt if you can find 2 Ada developers who agree completely on matters of Ada 
formatting, but there is a very broad consensus on something similar to the 
formatting used in the ARM. (Even there you'll find all-lower-case identifiers 
in Interfaces.C.) Differing significantly from it will get you some flak and 
some people who will presume that it indicates that you're not very good at 
using the language.

> But frankly, not using a library because somebody doesn't subscribe to the
same style guide in every aspect is bit over the top, no?

I wouldn't advocate that, though apparently Martin does. While I find some of 
your formatting irritating, I have used libraries with much worse formatting 
(based on looking only at package Adabase). Primarily I was trying to show you 
what Martin had objected to. (But I would, if defining the language, make 
CamelCase an error.)

>> package Martin is
>>     type Field_Size_ID is (One_Byte, Two_Bytes);
>>
>>     type Unsigned_One_Byte  is mod 2 **  8;
>>     type Unsigned_Two_Bytes is mod 2 ** 16;
>> end Martin;
>
> Subjective. I think your suggestions are worse (honestly, not lashing out)
plus they aren't even feasible because there are actually signed versions too
(so ambiguous). Why should the type names have to suffer to avoid a prefix on an
enumeration? But we're talking about opinions here and the subjective criticism
seems to be about my naming choice.

All such matters are subjective. Nbyte1 is a cryptic type name, no matter how 
it's capitalized, but seems to indicate that it's a type occupying 1 byte. One 
has to look at the type definition to see that it's an unsigned integer type. 
Unsigned_One_Byte seems a clearer name for such a thing, especially as it's 
similar to the types named Unsigned_* in Interfaces, which we presume all Ada 
developers are familiar with. Greater clarity and familiarity are good things in 
identifiers. Signed versions would be named Signed_One_Byte, again similar to 
types in Interfaces, so I don't see ambiguity or conflict.

> 2) Suggesting to rename types and enumerations to break all programs
> currently using the library is a much bigger deal and what's the benefit?

I wouldn't suggest that. I would suggest in future using a style closer to the 
community consensus and putting a little more thought into your names to make 
them clearer and the code easier to read. As you have seen, it would lead to 
greater acceptance of your libraries by others.

-- 
Jeff Carter
"Run away! Run away!"
Monty Python and the Holy Grail
58

Re: ANN: Introducing AdaBase - Thick database bindings for Ada

[jrmarino]

On Saturday, May 21, 2016 at 3:13:00 AM UTC+2, Jeffrey R. Carter wrote:
> If it's one word, then it should be Adabase. CamelCase is antithetical to some 
> basic Ada concepts, case insensitivity being one. Remember that many of us use 
> language-sensitive editors that will recapitalize identifiers when we load a 
> file. Resulting identifiers like Tisokeywords will be difficult to figure out 
> and understand. Enough of them may make it difficult enough to use your library 
> that people won't.

Artistic licence.  I can call it (AdaBase) whatever I want and stylize however I like.  I'll take a look at the types at the top of the package and see if underscores makes sense although I don't see why "Tisokeywords" would case an invasive automatic code-reformatting editor to have fits, unless you mean it must also be all lower case.

 
> I doubt if you can find 2 Ada developers who agree completely on matters of Ada 
> formatting, but there is a very broad consensus on something similar to the 
> formatting used in the ARM. (Even there you'll find all-lower-case identifiers 
> in Interfaces.C.) Differing significantly from it will get you some flak and 
> some people who will presume that it indicates that you're not very good at 
> using the language.


Their loss due to poor evaluating skills based on way too little information, no?  A style thoughout a project should be consistent (and looking through it now I can see AdaBase can improve in this regard, but there was a several month lag in development that helps explain it), but I don't think the style has to mimick ARM which I don't think is particularly great, only consistent.


> I wouldn't advocate that, though apparently Martin does. While I find some of 
> your formatting irritating, I have used libraries with much worse formatting 
> (based on looking only at package Adabase). Primarily I was trying to show you 
> what Martin had objected to. (But I would, if defining the language, make 
> CamelCase an error.)

Then you'd define that language as case-sensitive, something Ada is not, and that's the major flaw in people objection to how capitals are used.  While some people might use weird editors, they also might be in the great minority.
 
> > 2) Suggesting to rename types and enumerations to break all programs
> > currently using the library is a much bigger deal and what's the benefit?
> 
> I wouldn't suggest that. I would suggest in future using a style closer to the 
> community consensus and putting a little more thought into your names to make 
> them clearer and the code easier to read. As you have seen, it would lead to 
> greater acceptance of your libraries by others.

I seriously doubt anyone beyond beginner would have the slighly issue understanding the code or understanding the purpose of the variables or types based on the names.  I'll give you the style could be more uniform, and I'll give you I had no idea of the level of anal-retentiveness about things, but I will not concede that the quality or readability of the actual code is affected.  It seems this situation is the equivalent of moving Rafael Nadal's water bottles out of their perfect alignment before he serves -- something that shouldn't make a bit of differences but is crippling to somebody with OCD. :)

Re: ANN: Introducing AdaBase - Thick database bindings for Ada

[Georg Bauhaus]

On 21.05.16 09:01, jrmarino wrote:

> I seriously doubt anyone beyond beginner would have the slighly issue understanding the code or understanding the purpose of the variables or types based on the names.  I'll give you the style could be more uniform, and I'll give you I had no idea of the level of anal-retentiveness about things, but I will not concede that the quality or readability of the actual code is affected.  It seems this situation is the equivalent of moving Rafael Nadal's water bottles out of their perfect alignment before he serves -- something that shouldn't make a bit of differences but is crippling to somebody with OCD. :)

Some less subjective issues to consider.

- Pattern recognition: a human's capability to recognize some
arrangement of visible items is so well developed that deviations
of any kind can lead to rejection even when differences are
minor. Worse, even when rejection actually means a failure to
recognize that the thing seen is just right, structurally. In a sense:
false negatives resulting from minor pattern deviations.

- Expectations: anyone beyond beginner might have grown expectations
that he or she will find met by much software. Using any programming
language. These typically create some group pressure on authors to
(somewhat) conform in order for their work to be more welcome, pompous
and condescending as this might be. The mechanism works, statistically.
Solution below.

- Crowd addressed: All of C#, Swift, Java, Scala, Haskell, ...
use letter case and underscores in ways that make software "usual",
stylistically, even when grammatically it does not matter:
a piece of software typically needs to be "properly dressed"
to make a first impression. You know how important first impressions
are. Write an Objective-C class using Ada underscores, or
K&R C style for method names, and you're out for these reasons.
Even when the compiled structure is in line with the structure
of the system for which is was written.

- Precedent (+/-): There were two Ada bindings for OS/2. One did use
IBM's names, the other tore them apart using Ada underscores and turned
IBM's two-letter prefixes into package names, IIRC. Apparently,
some readers found it difficult to (pattern-)recognize the original
names after Ada-ification.  Which brings me to:

- Existing names: Typical database stuff names that are already known
by readers. So, whenever two things in are written in different
programming languages' names (e.g., original, binding) to denote the
same thing, then the names should perhaps be the very same, including
letter case (in a thin binding).


A tutorial example using RM style could render the issue less
controversial, and less in need of body-part psychological reference.
(Is a public Ada interface style and private body style is
useful as a means to match any author's working habits? It seems to
work outside Ada.)

I like fully spelled names in public interfaces, also types in
preference to names, particularly to composite names. Just had to
type and type again those varied names used for Base 64 Encoding
functions, while using three programming languages. Python's
incarnation ends the package name with "64", and starts method
names with "b64", "b32", and so on. Logical? Yes. Usable?
Not near the end of a workday. For me, monotonous uniformity of
naming makes focusing job matters easier.


-- 
"HOTDOGS ARE NOT BOOKMARKS"
Springfield Elementary teaching staff

Re: ANN: Introducing AdaBase - Thick database bindings for Ada

[Jeffrey R. Carter]

On 05/21/2016 12:01 AM, jrmarino wrote:
>
> Artistic licence.  I can call it (AdaBase) whatever I want and stylize
> however I like.

True. Choosing names and styles that have been demonstrated to alienate at least
some of your potential users seems counterproductive, however.

> Then you'd define that language as case-sensitive, something Ada is not, and
> that's the major flaw in people objection to how capitals are used.  While
> some people might use weird editors, they also might be in the great
> minority.

No, it would be case insensitive, but case aware. That is, identifiers that 
differ only in case would be the same identifier, but some of them would be 
illegal. The language would have a lot of such rules, intended mainly to 
alienate potential users.

-- 
Jeff Carter
"Son of a window-dresser."
Monty Python & the Holy Grail
12

Re: ANN: Introducing AdaBase - Thick database bindings for Ada

[jrmarino]

On Saturday, May 21, 2016 at 7:49:56 PM UTC+2, Jeffrey R. Carter wrote:
> On 05/21/2016 12:01 AM, jrmarino wrote:
> >
> > Artistic licence.  I can call it (AdaBase) whatever I want and stylize
> > however I like.
> 
> True. Choosing names and styles that have been demonstrated to alienate at least
> some of your potential users seems counterproductive, however.

I getting to a place where I question if such users are an asset though, and it's not like they are paying customers.  Asserting there is only valid style guide or that ARM style is a timeless measure and then letting those style criteria trump actual performance sounds like grief I don't need.  I'll make an exception if these hypothetical users contribute patches in addition to complaints, but if it's only complaints I'm not too bothered.  (I also distinguish between constructive "You might consider ..." comments and "Rework this to my specifications or else I refuse to look at it again" feedback.)

Re: ANN: Introducing AdaBase - Thick database bindings for Ada

[J-P. Rosen]

Le 21/05/2016 à 01:44, jrmarino a écrit :
> 2) Suggesting to rename types and enumerations to break all programs
> currently using the library is a much bigger deal and what's the
> benefit?

This shouldn't be an argument. Download AdaSubst from Adalog's web site.
You provide a dictionary (a text file giving the old name and the new
name), and the tool makes the necessary substitutions program-wide,
taking all visibility rules, use clauses, etc. into consideration.

It can also be used to adjust programs when you move an element from a
package to another one (great to split a big package into child packages).

-- 
J-P. Rosen
Adalog
2 rue du Docteur Lombard, 92441 Issy-les-Moulineaux CEDEX
Tel: +33 1 45 29 21 52, Fax: +33 1 45 29 25 00
http://www.adalog.fr

Re: ANN: Introducing AdaBase - Thick database bindings for Ada

[jrmarino]

On Saturday, May 21, 2016 at 7:11:37 AM UTC+2, J-P. Rosen wrote:
> This shouldn't be an argument. Download AdaSubst from Adalog's web site.
> You provide a dictionary (a text file giving the old name and the new
> name), and the tool makes the necessary substitutions program-wide,
> taking all visibility rules, use clauses, etc. into consideration.
> 
> It can also be used to adjust programs when you move an element from a
> package to another one (great to split a big package into child packages).

Of course it is an argument!
You are saying, for the sake of sujective cosmetics, that every current user has to fix their programs if they upgrade the library.  E.g. If 100 people used it, and 250 programs were based on it, those 100 people would all to do the rework.  Frankly I can't think of anything more "anti-Ada" then intentionally breaking compatibility.

On the flip side, AdaBase isn't really "set" until PostgreSQL is finished and doubtfully anybody is using it seriously at all, so now would be the time to make breaking changed.

Much later, however, it is most definitely "an argument".

Re: ANN: Introducing AdaBase - Thick database bindings for Ada

[J-P. Rosen]

Le 21/05/2016 à 08:43, jrmarino a écrit :
> You are saying, for the sake of sujective cosmetics, that every
> current user has to fix their programs if they upgrade the library.
> E.g. If 100 people used it, and 250 programs were based on it, those
> 100 people would all to do the rework.  Frankly I can't think of
> anything more "anti-Ada" then intentionally breaking compatibility.

Of course, breaking compatibility has a cost - and benefits. Gratuitous
changes should be avoided, but it is a matter of evaluating the
cost/benefit ratio.

In the free software world, people often do not refrain from making
incompatible changes - a bit too often to my taste. OTOH, there is this
famous quote from the people who made "make":

The day after we released it, we realized that using the Tab was a big
mistake; but it was too late to make a change, we had more than 20 users...

Nowadays, millions of people are pested by this!
-- 
J-P. Rosen
Adalog
2 rue du Docteur Lombard, 92441 Issy-les-Moulineaux CEDEX
Tel: +33 1 45 29 21 52, Fax: +33 1 45 29 25 00
http://www.adalog.fr

Re: ANN: Introducing AdaBase - Thick database bindings for Ada

[jrmarino]

Okay, it broke the API thus all the testcases and documentation, and took some time to fix them, but I updated the types in AdaBase, AdaBase.Results.Sets, and AdaBase.Results.Fields to take into account some of these suggestions:

https://raw.githubusercontent.com/jrmarino/AdaBase/master/src/adabase.ads
https://raw.githubusercontent.com/jrmarino/AdaBase/master/src/results/adabase-results-field.ads
https://raw.githubusercontent.com/jrmarino/AdaBase/master/src/results/adabase-results-sets.ads

Mostly this was removing CamelCase from public-facing types and replacing them with something similar with understores and/or capitalizing type definitions.  I did not capitalize enumerations or constants, nor do I wish to.  I left the prefixes on the field_types enumeration because the "there's no reason for it" assertion was obviously false (regardless if the solution is universally liked, there was definitely a reason for it).

Re: ANN: Introducing AdaBase - Thick database bindings for Ada

[Jeffrey R. Carter]

On 05/21/2016 09:54 AM, jrmarino wrote:
 >
> I left the prefixes on the field_types enumeration because the "there's
> no reason for it" assertion was obviously false (regardless if the solution
> is universally liked, there was definitely a reason for it).

Now that I've looked at this in a little greater detail, I see that the 
enumeration type in question is in a different package from the other types that 
you want to have the same names as the enumeration literals, and so they have 
different complete names. For example

package P1 is
    type Field_Size_ID is (One_Byte, Two_Bytes);
end P1;

package P1.P2 is
    type One_Byte  is mod 2 **  8;
    type Two_Bytes is mod 2 ** 16;
end P1.P2;

package P1.P2.P3 is
    type R (Kind : Field_Size_ID := P1.One_Byte) is record
       case Kind is
       when P1.One_Byte =>
          Small : One_Byte := 0;
       when P1.Two_Bytes =>
          Big : Two_Bytes := 0;
       end case;
    end record;
end P1.P2.P3;

compiles fine. It seems the only reason for the prefixes on the enumeration 
literals was a desire to avoid the extra typing required to prefix the literals 
with the pkg name.

-- 
Jeff Carter
"Son of a window-dresser."
Monty Python & the Holy Grail
12

Re: ANN: Introducing AdaBase - Thick database bindings for Ada

[jrmarino]

On Saturday, May 21, 2016 at 8:20:27 PM UTC+2, Jeffrey R. Carter wrote:
> compiles fine. It seems the only reason for the prefixes on the enumeration 
> literals was a desire to avoid the extra typing required to prefix the literals 
> with the pkg name.

well, no, I almost never utilize the "USE" keyword so everything is prefixed; I wouldn't try to avoid that.

IIRC, the field_types enumeration was once in the same child package and I probably moved it to the root one.  And then I never tried prefixing with "AdaBase." 

Now, even if that's the solution, I'm not sure having a type and an enumeration being identical is a good idea.

Re: ANN: Introducing AdaBase - Thick database bindings for Ada

[Martin]

On Saturday, May 21, 2016 at 7:44:35 PM UTC+1, jrmarino wrote:
> On Saturday, May 21, 2016 at 8:20:27 PM UTC+2, Jeffrey R. Carter wrote:
> > compiles fine. It seems the only reason for the prefixes on the enumeration 
> > literals was a desire to avoid the extra typing required to prefix the literals 
> > with the pkg name.
> 
> well, no, I almost never utilize the "USE" keyword so everything is prefixed; I wouldn't try to avoid that.
> 
> IIRC, the field_types enumeration was once in the same child package and I probably moved it to the root one.  And then I never tried prefixing with "AdaBase." 
> 
> Now, even if that's the solution, I'm not sure having a type and an enumeration being identical is a good idea.

It isn't you're right...which is why people often suffix all types with _Type, which I find ugly but I grit my teeth and go with the flow. I much prefer the prefix A_ - as it draws attention to the fact that types are 'indefinite article'. Back in the early 90s there was a far bit of A_ style around but not now.

However, the ft_ prefix really isn't needed as the context will tell you they are field types, e.g. you could have:

package AdaBase.Results.Field is

   type Std_Field is tagged private;
   type Field_Access is access Std_Field;

-- NB: check this tautology out! And that's what I hate about the _Type style :-(
   type Variant (Field_Type : Field_Type_Type := nbyte8) is
-- or
   type Variant (Field_Type : A_Field_Type := nbyte8) is
      record
         case Field_Type is
            when NBYTE0    => v00 : Boolean;
            when NBYTE1    => v01 : NByte1;
            when NBYTE2    => v02 : NByte2;
-- etc

BTW, typenames in Interface.C follow the C convension as they are supposed to represent the types in C!

Thanks for making the name changes - I'll go download now and give it a go, it looks much more like Ada!

If you want real style obsession check out Python and it's idea of 'Pythonic' code...Ada users are no where near as obsessive as that! :-D

-- Martin

Re: ANN: Introducing AdaBase - Thick database bindings for Ada

[brbarkstrom]

I find myself using p_Access_Variable_Type to indicate pointers, although the result is probably not quite in accord with standard Ada naming conventions.  However, if you look back, Ada95 authors often used upper case for key words in Ada (like IF, ELSE, and so on).  I've been working on tutorials that deal with Ada concurrency and find the earliest example files need extensive editing to get them to the point where I can understand them when I put them into the Ada2012 Windows XP version.  On the other hand, I've also been dealing with another set of tutorials where the editing is minimal.

Probably the key point is to recognize that you're dealing with a variety of sociological groupings that have different ways of naming things.  If you want
some light, but (maybe) interesting reading, try Eco, U.: Kant and the Platypus
that deals with how communities of discourse develop a community dialect that
lets the members talk about common experiences.  You might even want to try
figuring out which communities you're dealing with in the Thick Ada Binding
and see which ones have different conventions.  If you do that, you might want
to look up Thomas: Strategic Product Development.  It's a book that shows how
to lay out a marketing strategy that deals with user needs (and user desires).
It's really a classic book on marketing and has a very helpful list of 
procedures for how to do that work.

If you want to do this for commercial purposes, it's the first step in the
development of a marketing plan.  There is, as I recall, an Ada Web Server
project that used databases and promised a complete developed Ada Web Site.
You might look at https://github.com/stcarrez/ada-awa.  Ada-awa was intended
to be a complete Ada Web site took kit that included Ada tools that accessed
databases.  I haven't dug deep enough to check out how its doing now, but
it might be a useful site to take a look at.  The usual problem is that someone
gets interested in doing a project, has enough resources to get something
working, and then moves on to something that pays them enough to get started
on some new project.

The isaviz project (at https://www.w3.org/2001/11/IsaViz/) is a reasonable
cautionary note.  It looked like a good start, got W3C approval, and then
was abandoned by its developer when he found something else that paid better.
Track through all the libraries it refers to (like graphviz - hosted by ATT,
and Jena - hosted by HP and then sent on to Apache).  If you wanted to 
reconstruct it now, you've got quite a bunch of threads to pick up and
recreate or harmonize).

I guess it's a fact of life that you arrange for someone to pick up on the
initial development and continue to support it for the life of the entire
project future.

Bruce B.

Re: ANN: Introducing AdaBase - Thick database bindings for Ada

[Martin]

On Monday, May 23, 2016 at 1:33:04 AM UTC+1, brbar...@gmail.com wrote:
> [snip]However, if you look back, Ada95 authors often used upper case for key words in Ada (like IF, ELSE, and so on).[snip]

Which was the recommended style for Ada83.

-- Martin

Re: ANN: Introducing AdaBase - Thick database bindings for Ada

[AdaMagica]

Am Montag, 23. Mai 2016 13:40:59 UTC+2 schrieb Martin:
> On Monday, May 23, 2016 at 1:33:04 AM UTC+1, brbar...@gmail.com wrote:
> > [snip]However, if you look back, Ada95 authors often used upper case for key words in Ada (like IF, ELSE, and so on).[snip]
> 
> Which was the recommended style for Ada83.
> 
> -- Martin

No, the ARM used all upper case for identifiers, all lower case for reserved words (an the latter hasn't changed).

But I find the whole discussion quite unnecessary and not very constructive. Of course you can make style proposals (in a polite manner), but it's the author's choice to follow them or not. And of course it's a good choice to follow the common style used in a given language.

Re: ANN: Introducing AdaBase - Thick database bindings for Ada

[Martin]

On Monday, May 23, 2016 at 1:46:18 PM UTC+1, AdaMagica wrote:
> Am Montag, 23. Mai 2016 13:40:59 UTC+2 schrieb Martin:
> > On Monday, May 23, 2016 at 1:33:04 AM UTC+1, brbar...@gmail.com wrote:
> > > [snip]However, if you look back, Ada95 authors often used upper case for key words in Ada (like IF, ELSE, and so on).[snip]
> > 
> > Which was the recommended style for Ada83.
> > 
> > -- Martin
> 
> No, the ARM used all upper case for identifiers, all lower case for reserved words (an the latter hasn't changed).

You're right...I have distinct memories of 'IF' and 'ELSE' etc but that must have been local (and rather horrible) coding standards.


> But I find the whole discussion quite unnecessary and not very constructive. Of course you can make style proposals (in a polite manner), but it's the author's choice to follow them or not. And of course it's a good choice to follow the common style used in a given language.

Indeed, but the original API didn't follow the common style, that was my point. And it's very easy to configure GNAT to check your coding style.

-- Martin

Re: ANN: Introducing AdaBase - Thick database bindings for Ada

[jrmarino]

On Tuesday, May 24, 2016 at 12:03:37 AM UTC+2, Martin wrote:
> Indeed, but the original API didn't follow the common style, that was my point. And it's very easy to configure GNAT to check your coding style.
> 

I have (and alway had) virtually every style switch set on.  You've mentioned GNAT twice, but I don't see that as having played any role here.  Gnat doesn't balk on CamelCase or suffixed enumeration type elements under any setting I'm aware of.  I see keyword casing, but not identifier casing switches.

Re: ANN: Introducing AdaBase - Thick database bindings for Ada

[J-P. Rosen]

Le 24/05/2016 à 09:28, jrmarino a écrit :
> Gnat doesn't balk on CamelCase or suffixed enumeration type elements
> under any setting I'm aware of.  I see keyword casing, but not
> identifier casing switches.

Of course. If you need sophisticated style enforcement, you'd better use
AdaControl ;-)

-- 
J-P. Rosen
Adalog
2 rue du Docteur Lombard, 92441 Issy-les-Moulineaux CEDEX
Tel: +33 1 45 29 21 52, Fax: +33 1 45 29 25 00
http://www.adalog.fr

Re: ANN: Introducing AdaBase - Thick database bindings for Ada

[Simon Wright]

jrmarino <dragonlace.cla@marino.st> writes:

> On Tuesday, May 24, 2016 at 12:03:37 AM UTC+2, Martin wrote:
>> Indeed, but the original API didn't follow the common style, that
>> was my point. And it's very easy to configure GNAT to check your
>> coding style.
>> 
>
> I have (and alway had) virtually every style switch set on.  You've
> mentioned GNAT twice, but I don't see that as having played any role
> here.  Gnat doesn't balk on CamelCase or suffixed enumeration type
> elements under any setting I'm aware of.  I see keyword casing, but
> not identifier casing switches.

In GPS, under Edit > Preferences > Editor > Ada, there are

  Casing policy - when to automatically adjust case, I have On_The_Fly.
  Reserved word casing - I have Lower.
  Identifier casing - I have Smart_Mixed, I think this means Title_Case,
    leaving alone any explicitly upper-case letters (e.g. CamelCase).

Under Project > Properties > Switches > Ada > Style checks, there are
a couple of relevant switches, the most important of which is 'Check
references' (-gnatyr), All identifier references must be cased in the
same way as the corresponding declaration.

Re: ANN: Introducing AdaBase - Thick database bindings for Ada

[Jeffrey R. Carter]

On 05/23/2016 04:40 AM, Martin wrote:
> On Monday, May 23, 2016 at 1:33:04 AM UTC+1, brbar...@gmail.com wrote:
>> [snip]However, if you look back, Ada95 authors often used upper case for key words in Ada (like IF, ELSE, and so on).[snip]
>
> Which was the recommended style for Ada83.

No, that was lower-case for reserved words and all caps for identifiers. Upper 
case for reserved words was never a common style.

-- 
Jeff Carter
"It's all right, Taggart. Just a man and a horse being hung out there."
Blazing Saddles
34

Re: ANN: Introducing AdaBase - Thick database bindings for Ada

[brbarkstrom]

This isn't the first project to have pleasantries with naming conventions and nomenclature -- nor will it be the last.  The upper case, lower case, camel case and use of other conventions has certainly bedeviled the folks trying to use XML and XML Schema for naming concepts.  This is one of the sources of "semantic heterogeneity" that still bothers the semantic web community [see
the references to a Google search for this term, particularly Halevy, Bergman, and the Web page on the Open Semantic Framework].

There's an excellent summary of the issues involved in naming in

Schneider, D. C., 2009: Quantitative Ecology: Measurement, Models, and Scaling,
Second Edition, Academic Press, Amsterdam, NL

The author notes "Good notation is a tremendous aid in working with [a subject]. ... [When a subject] lacks a clear and consistent notational system [an author is tempted to create such a system] that, once proposed, will, of course, be immediately adopted.  The lessons of history are otherwise.  New notation, if noticed at all, typically passes into oblivion [Cajori,F., 1929: A History of Mathematical Notations, The Open Court Publishing Company, Chicago, IL].  ... This is largely due to the effort required to learn new notation.  Once a notation has been learned ..., it resists replacement by another ... .

A second reason for slow diffusion of new notation is that only experience will tell whether ... [an innovation] is indispensable.  It could take years or decades to find out if ... [an innovation] is worth keeping.  Why go to the effort of learning a new notation unless it is already known to aid comprehension or simplify computation?

Good notation would seem to require little thought.  In fact, there are principles of good notation based on historical experience [Cajori, 1929] ..."

This author tabulates five criteria for good (mathematical) notation:

"
1.  Consistent with current usage
2.  Reduces the burden on memory
3.  Demonstrated utility ...
4.  Brevity
5.  Lends itself to computer applications
"

Then he notes

"The first criterion, consistency with current usage, is important because of the perpetual temptation to improve existing notation.  The reason for listing this criterion first is that notational improvements do not take root and flourish until they are adapted by a nonconferring group of specialists [Cajori, 1929].  Notation that is consistent with current usage increases the communication of ideas.  Novel signs and symbols usually hinder communication.

...

The third criterion ..., utility in application, can really only be determined from experience of groups of people working on similar problems.  This can take decades.  Thirty years between the proposal and eventual adoption of a [notation] ... has not been unusual in the past [Cajori, 1929]."

Biological notation provides one example of the difficulties involved.  It took about a century and five or six international congresses of biologists to settle on the usual Linnean nomenclature [p. ix in Britton, N. and Brown, A., 1913 and republished in 1970: An Illustrated Flora of the Northern United States and Canada, Second Edition, Vol. I, Dover, New York, NY].  Of course there's more nomenclatural turmoil when taxonomists turn to cladistics and the use of DNA and evolutionary models to classify based on the "tree of life".

Bruce B.

Re: ANN: Introducing AdaBase - Thick database bindings for Ada

[Graham Stark]

On Friday, 13 May 2016 21:37:16 UTC+1, jrmarino  wrote:
> Hey guys, I know there are several options for Ada to interface with databases, but I wasn't happy with any of them for various reasons and thus created yet another option to scratch my itch.  I was aiming at a consistent interface to which the various drivers adapt.  With some care, the database backends should be interchangeable.
> 
> So far I've created drivers for MySQL and SQLite and the driver for PostgreSQL is next on my list.  I'd like to eventually support others such as Firebird, MSSQL, Oracle, etc., but those will be very low priority for me over the next year.  Contributions are welcome of course -- It's been released under the developer- and commercial-friendly ISC licence.
> 
> I've spent a lot of time documenting the interface and providing a lot of real examples.  If you are at all looking for something like this, I recommend that you spend a few minutes going through the descriptions and examples of all the functions:
> 
> http://jrmarino.github.io/AdaBase/
> 
> It's been developed on DragonFly and FreeBSD, and I haven't tested it on Windows yet, but I will.  it's already available for BSD users, see: http://www.freshports.org/databases/adabase
> 
> I believe AdaBase is already mature for MySQL and SQLite, but reports of issues will be welcome.  I'm active on github, so issues and pull requests will be dispositioned quickly if you wish to leverage those tools.
> 
> Hopefully other people will find this project useful!
> 
> --  John

I'm late to this. I've just downloaded this and it looks a great thing, exactly what's needed. It's a shame that so many subsequent emails have been about formatting issues.

Graham

Re: ANN: Introducing AdaBase - Thick database bindings for Ada

[jrmarino]

This is just a quick note that may be of interest to some people.
I just released version 3.0 of AdaBase, which comes with a fully supported PostgreSQL driver.  During its testing and development, I discovered minor issues/bugs with the other two drivers, so I fixed those too.  Of course, some of the type names changed since 2.0 so beware of that.  Finally, in order to treat multiple rowset from stored procedures identically with respect to "fetch_next_row_set", I had to create a new function "call_stored_procedure".  This is supported by both PostgreSQL and MySQL and function identically.  (I check all the drivers against several testcases that I wrote to make sure they behave as expected and as similarly to each other as possible).

I think version 3.1 will come out relatively soon.  I would like to add full support for geometry data types (new data type) and add better support for bit strings (new data type) and get MySQL to try to handle other native data types it currently rejects (e.g. xml, json, etc).  Once that is done, I'll probable limit development to addressing bug reports and driver improvements as use cases dictate.  I am not looking to add any new drivers for a while.

Re: ANN: Introducing AdaBase - Thick database bindings for Ada

[karsar]

Someone at least started creating useful code instead of discussing old, probably
very ancient times and how everything was not properly designed since then! 
Someone puts code on Github, makes it available under liberal license 
and makes it possible to contribute. Code in Ada! A rare event to witness.

I'm using databases myself and will check AdaBase soon.
Would like to add a small comment, after reading discussion list.
Don't bother with style. Get it working, style is something you can 
change afterwards. Or someone annoyed but in need of AdaBase 
will commit an update.

If I find something else to add, I'll open an Issue or
pull request on Github. Thx for making cool things.