From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=unavailable autolearn_force=no version=3.4.4 X-Received: by 10.50.32.37 with SMTP id f5mr5493119igi.10.1463222500486; Sat, 14 May 2016 03:41:40 -0700 (PDT) X-Received: by 10.157.8.54 with SMTP id 51mr243997oty.13.1463222500455; Sat, 14 May 2016 03:41:40 -0700 (PDT) Path: eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!news.eternal-september.org!mx02.eternal-september.org!feeder.eternal-september.org!news.glorb.com!i5no8379602ige.0!news-out.google.com!uv8ni424igb.0!nntp.google.com!i5no8379601ige.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail Newsgroups: comp.lang.ada Date: Sat, 14 May 2016 03:41:40 -0700 (PDT) In-Reply-To: Complaints-To: groups-abuse@google.com Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=83.34.249.176; posting-account=Zsf4jwoAAADEqwCydv835KU9-S3h_Y26 NNTP-Posting-Host: 83.34.249.176 References: User-Agent: G2/1.0 MIME-Version: 1.0 Message-ID: Subject: Re: ANN: Introducing AdaBase - Thick database bindings for Ada From: jrmarino Injection-Date: Sat, 14 May 2016 10:41:40 +0000 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Xref: news.eternal-september.org comp.lang.ada:30404 Date: 2016-05-14T03:41:40-07:00 List-Id: 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= =20 > SQL. And that "SQL" limited to some unstated subset, an empty subset, if= =20 > you want it interchangeable... Yes, I mean SQL relational databases. > I am afraid, such efforts are futile, even when massively funded with=20 > resources, as ODBC perfectly illustrates. >=20 > And, of course, the "thickness" of sending SQL statements as strings is= =20 > up to discussion... Some of the SQL statements are constructed, tailored to driver. You can se= nd raw strings if you want, but that limits portability. Using the abstrac= tion features improves portability. But yes, if one wants to have intercha= ngeable backends, they need to be smart about it, but the subset is definit= ely not empty, far from it. > In my opinion the approach is unrealistic. It is technically impossible= =20 > to deal with a *legacy* database in a DBMS-independent manner. It was=20 > not designed to have this. Neither it is really interesting for Ada=20 > projects that wished to use a DB. Such projects would most likely create= =20 > a new DB from scratch. Therefore they would be perfectly served by a=20 > persistency layer for Ada objects, with no traces of SQL, DB-specific=20 > data types and other mess. Well, Dmitry, AdaBase exists now. You've focused on the "possiblity of int= erchangeable backends" as the main design driver which of course it was not= . The main objective is constant API which behaves identically no matter w= hich backend is chosen. Guys, nobody has to use this. I created it for me because none of the exis= ting 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 act= ually reviewing the documention (which I spent many many hours writing). I= n 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. =20