* Windows Ada database support. @ 2004-11-24 12:31 Mark Doherty 2004-11-24 15:04 ` Marius Amado Alves ` (3 more replies) 0 siblings, 4 replies; 96+ messages in thread From: Mark Doherty @ 2004-11-24 12:31 UTC (permalink / raw) I am developing a (GNAT 3.15p) ADA web (AWS) / Database (???) application that will run on LINUX but developed on windows (xp). What is the current best advice. GNADE / CLAW / GWINDOWS.Database GNAVI, or something else? Thanx Mark. ^ permalink raw reply [flat|nested] 96+ messages in thread
* Re: Windows Ada database support. 2004-11-24 12:31 Windows Ada database support Mark Doherty @ 2004-11-24 15:04 ` Marius Amado Alves 2004-11-24 18:35 ` Pascal Obry ` (2 subsequent siblings) 3 siblings, 0 replies; 96+ messages in thread From: Marius Amado Alves @ 2004-11-24 15:04 UTC (permalink / raw) To: comp.lang.ada Mark Doherty wrote: > I am developing a (GNAT 3.15p) ADA web (AWS) / Database (???) > application that will run on LINUX but developed on windows (xp). > > What is the current best advice. GNADE / CLAW / GWINDOWS.Database > GNAVI, or something else? I don't think there can be a "best" advice. I would recommend my babies Mneson and Pgsql, in that order. Check AdaPower for more choices. The items you list above and Pgsql are all "bindings" to external systems. In AdaPower there are also "libraries" listed. With a library you can embbed the database with your application. Mneson is more developed than the published version. Contact me if you're interested. ^ permalink raw reply [flat|nested] 96+ messages in thread
* Re: Windows Ada database support. 2004-11-24 12:31 Windows Ada database support Mark Doherty 2004-11-24 15:04 ` Marius Amado Alves @ 2004-11-24 18:35 ` Pascal Obry 2004-11-24 19:17 ` Alex R. Mosteo 2004-11-25 1:03 ` David Botton 2004-11-25 2:18 ` bubble 3 siblings, 1 reply; 96+ messages in thread From: Pascal Obry @ 2004-11-24 18:35 UTC (permalink / raw) mark_doherty@yahoo.co.uk (Mark Doherty) writes: > What is the current best advice. GNADE / CLAW / GWINDOWS.Database > GNAVI, or something else? I would go for GNADE. AFAIK this is the only one (on the list above, not counting "something else" of course :) to run on GNU/Linux and Windows. I have lot of good experiences with GNADE (using ODBC) on both GNU/Linux and Windows. Pascal. -- --|------------------------------------------------------ --| Pascal Obry Team-Ada Member --| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE --|------------------------------------------------------ --| http://www.obry.org --| "The best way to travel is by means of imagination" --| --| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595 ^ permalink raw reply [flat|nested] 96+ messages in thread
* Re: Windows Ada database support. 2004-11-24 18:35 ` Pascal Obry @ 2004-11-24 19:17 ` Alex R. Mosteo 2004-11-24 19:30 ` Dmitry A. Kazakov 0 siblings, 1 reply; 96+ messages in thread From: Alex R. Mosteo @ 2004-11-24 19:17 UTC (permalink / raw) Pascal Obry wrote: > mark_doherty@yahoo.co.uk (Mark Doherty) writes: > > >>What is the current best advice. GNADE / CLAW / GWINDOWS.Database >>GNAVI, or something else? > > > I would go for GNADE. AFAIK this is the only one (on the list above, not > counting "something else" of course :) to run on GNU/Linux and Windows. I have > lot of good experiences with GNADE (using ODBC) on both GNU/Linux and Windows. And I'm using the GNADE PSQL binding and it's really easy. ^ permalink raw reply [flat|nested] 96+ messages in thread
* Re: Windows Ada database support. 2004-11-24 19:17 ` Alex R. Mosteo @ 2004-11-24 19:30 ` Dmitry A. Kazakov 2004-11-24 22:32 ` Ching Bon Lam 0 siblings, 1 reply; 96+ messages in thread From: Dmitry A. Kazakov @ 2004-11-24 19:30 UTC (permalink / raw) On Wed, 24 Nov 2004 20:17:58 +0100, Alex R. Mosteo wrote: > Pascal Obry wrote: >> mark_doherty@yahoo.co.uk (Mark Doherty) writes: >> >>>What is the current best advice. GNADE / CLAW / GWINDOWS.Database >>>GNAVI, or something else? >> >> I would go for GNADE. AFAIK this is the only one (on the list above, not >> counting "something else" of course :) to run on GNU/Linux and Windows. I have >> lot of good experiences with GNADE (using ODBC) on both GNU/Linux and Windows. > > And I'm using the GNADE PSQL binding and it's really easy. GNADE ODBC bindings are easy. The problem is that ODBC itself ain't easy. But if you want portability across different databases there is little choice. The optimal choice could be GNADE ADBC, unfortunately, its development was stopped. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 96+ messages in thread
* Re: Windows Ada database support. 2004-11-24 19:30 ` Dmitry A. Kazakov @ 2004-11-24 22:32 ` Ching Bon Lam 0 siblings, 0 replies; 96+ messages in thread From: Ching Bon Lam @ 2004-11-24 22:32 UTC (permalink / raw) "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in news:1mmefmfb0ld12.1ahn4lp4c0nt1.dlg@40tude.net: > On Wed, 24 Nov 2004 20:17:58 +0100, Alex R. Mosteo wrote: > >> Pascal Obry wrote: >>> mark_doherty@yahoo.co.uk (Mark Doherty) writes: >>> >>>>What is the current best advice. GNADE / CLAW / GWINDOWS.Database >>>>GNAVI, or something else? >>> >>> I would go for GNADE. AFAIK this is the only one (on the list above, >>> not counting "something else" of course :) to run on GNU/Linux and >>> Windows. I have lot of good experiences with GNADE (using ODBC) on >>> both GNU/Linux and Windows. >> >> And I'm using the GNADE PSQL binding and it's really easy. > > GNADE ODBC bindings are easy. The problem is that ODBC itself ain't > easy. But if you want portability across different databases there is > little choice. The optimal choice could be GNADE ADBC, unfortunately, > its development was stopped. > In GNADE CVS there is also Sqlite3 bindings which i wrote (dir dbi/sqlite). It supports quite most of the functions of sqlite3 except for user functions which you can call in SQL. It's still not much tested, but it's stable as far as i know. www.sqlite.org gnade.sf.net C.B. Lam ^ permalink raw reply [flat|nested] 96+ messages in thread
* Re: Windows Ada database support. 2004-11-24 12:31 Windows Ada database support Mark Doherty 2004-11-24 15:04 ` Marius Amado Alves 2004-11-24 18:35 ` Pascal Obry @ 2004-11-25 1:03 ` David Botton 2004-11-25 17:50 ` Warren W. Gay VE3WWG 2004-11-25 2:18 ` bubble 3 siblings, 1 reply; 96+ messages in thread From: David Botton @ 2004-11-25 1:03 UTC (permalink / raw) On 2004-11-24 07:31:57 -0500, mark_doherty@yahoo.co.uk (Mark Doherty) said: > > What is the current best advice. GNADE / CLAW / GWINDOWS.Database > GNAVI, or something else? They each serve different purpose. If your application is windows only (or doing GUI programming on windows using GNAVI), then using ADO via GWindows.Database or ADO bindings directly from GNATCOM are the likely winner. Otherwise it is about your needs, I have an entire section on databases in AdaPower: http://www.adapower.com/index.php?Command=Class&ClassID=Database David Botton http://www.adapower.com ^ permalink raw reply [flat|nested] 96+ messages in thread
* Re: Windows Ada database support. 2004-11-25 1:03 ` David Botton @ 2004-11-25 17:50 ` Warren W. Gay VE3WWG 2004-11-26 9:15 ` Dmitry A. Kazakov 0 siblings, 1 reply; 96+ messages in thread From: Warren W. Gay VE3WWG @ 2004-11-25 17:50 UTC (permalink / raw) David Botton wrote: > On 2004-11-24 07:31:57 -0500, mark_doherty@yahoo.co.uk (Mark Doherty) said: > >> What is the current best advice. GNADE / CLAW / GWINDOWS.Database >> GNAVI, or something else? > > They each serve different purpose. If your application is windows only > (or doing GUI programming on windows using GNAVI), then using ADO via > GWindows.Database or ADO bindings directly from GNATCOM are the likely > winner. > > Otherwise it is about your needs, I have an entire section on databases > in AdaPower: > > http://www.adapower.com/index.php?Command=Class&ClassID=Database APQ Plug: The good news is that you do have "choice". I have been dragging my feet in getting the latest version of APQ out, but the published version supports PostgreSQL and MySQL in OO form. The version to be released (pending install scripts), supports PostgreSQL, MySQL and SYBASE (I have been distracted with another fun and absorbing project lately). The OO level support is database neutral in most places, so that you can write portable database code. Differences do exist however, but this can be accomodated in the code if the programmer does a little planning (avoid certain database features). Good for Linux/Windows/*NIX, local or remote databases. The same database code should compile to all platforms. And... no *ODBC required. Totally native, no preprocessing of source code. Also includes comprehensive manual with examples. -- Warren W. Gay VE3WWG http://home.cogeco.ca/~ve3wwg ^ permalink raw reply [flat|nested] 96+ messages in thread
* Re: Windows Ada database support. 2004-11-25 17:50 ` Warren W. Gay VE3WWG @ 2004-11-26 9:15 ` Dmitry A. Kazakov 2004-11-26 18:36 ` David Botton ` (4 more replies) 0 siblings, 5 replies; 96+ messages in thread From: Dmitry A. Kazakov @ 2004-11-26 9:15 UTC (permalink / raw) On Thu, 25 Nov 2004 12:50:07 -0500, Warren W. Gay VE3WWG wrote: > David Botton wrote: > >> On 2004-11-24 07:31:57 -0500, mark_doherty@yahoo.co.uk (Mark Doherty) said: >> >>> What is the current best advice. GNADE / CLAW / GWINDOWS.Database >>> GNAVI, or something else? >> >> They each serve different purpose. If your application is windows only >> (or doing GUI programming on windows using GNAVI), then using ADO via >> GWindows.Database or ADO bindings directly from GNATCOM are the likely >> winner. >> >> Otherwise it is about your needs, I have an entire section on databases >> in AdaPower: >> >> http://www.adapower.com/index.php?Command=Class&ClassID=Database > > APQ Plug: > > The good news is that you do have "choice". I have been dragging my feet > in getting the latest version of APQ out, but the published version > supports PostgreSQL and MySQL in OO form. The version to be released > (pending install scripts), supports PostgreSQL, MySQL and SYBASE > (I have been distracted with another fun and absorbing project lately). > > The OO level support is database neutral in most places, so that you > can write portable database code. Differences do exist however, but > this can be accomodated in the code if the programmer does a little > planning (avoid certain database features). > > Good for Linux/Windows/*NIX, local or remote databases. The same > database code should compile to all platforms. > > And... no *ODBC required. Totally native, no preprocessing of source > code. Also includes comprehensive manual with examples. What about support for MS-Access, MS-SQL server, Oracle? And more importantly why that crappy SQL over and over again? I would like to see a high level Ada.Database[.Relational?] package totally independent on what happens beneath. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 96+ messages in thread
* Re: Windows Ada database support. 2004-11-26 9:15 ` Dmitry A. Kazakov @ 2004-11-26 18:36 ` David Botton 2004-11-27 8:59 ` Dmitry A. Kazakov 2004-11-29 1:28 ` Georg Bauhaus ` (3 subsequent siblings) 4 siblings, 1 reply; 96+ messages in thread From: David Botton @ 2004-11-26 18:36 UTC (permalink / raw) You have that on Win32 with GWindows.Databases it uses ADO which abstracts OLE-DB, ODBC, LDAP, and Mail, and much more. David Botton On 2004-11-26 04:15:06 -0500, "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> said: > What about support for MS-Access, MS-SQL server, Oracle? > > And more importantly why that crappy SQL over and over again? I would like > to see a high level Ada.Database[.Relational?] package totally independent > on what happens beneath. ^ permalink raw reply [flat|nested] 96+ messages in thread
* Re: Windows Ada database support. 2004-11-26 18:36 ` David Botton @ 2004-11-27 8:59 ` Dmitry A. Kazakov 2004-11-28 0:46 ` David Botton 0 siblings, 1 reply; 96+ messages in thread From: Dmitry A. Kazakov @ 2004-11-27 8:59 UTC (permalink / raw) On Fri, 26 Nov 2004 13:36:42 -0500, David Botton wrote: > You have that on Win32 with GWindows.Databases it uses ADO which > abstracts OLE-DB, ODBC, LDAP, and Mail, and much more. But in some sense ADO is even worse than SomeDB-binding. At least databases are more or less platform independent. In my view ADO is just as SQL, ODBC and anything else. I would consider ADO as yet another database interface to be abstracted away by our Ada(tm) way. So I am for Ada.Database in the standard. > On 2004-11-26 04:15:06 -0500, "Dmitry A. Kazakov" > <mailbox@dmitry-kazakov.de> said: >> What about support for MS-Access, MS-SQL server, Oracle? >> >> And more importantly why that crappy SQL over and over again? I would like >> to see a high level Ada.Database[.Relational?] package totally independent >> on what happens beneath. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 96+ messages in thread
* Re: Windows Ada database support. 2004-11-27 8:59 ` Dmitry A. Kazakov @ 2004-11-28 0:46 ` David Botton 2004-11-28 9:51 ` Dmitry A. Kazakov 0 siblings, 1 reply; 96+ messages in thread From: David Botton @ 2004-11-28 0:46 UTC (permalink / raw) I didn't pick up at the time you were talking about an Ada standard. ADO is just a way to offer an abstraction on Win32 (of course you get thick fairly easy to use Ada bindings to ADO via GNATCOM and even simpler via GWindows.Databases). While I am not thrilled with the idea of create Ada standards for bindings to complex externals systems, a good look at the ADO way of doing things would certainly be a prerequisite to creating such a standard. David Botton On 2004-11-27 03:59:53 -0500, "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> said: > On Fri, 26 Nov 2004 13:36:42 -0500, David Botton wrote: > >> You have that on Win32 with GWindows.Databases it uses ADO which >> abstracts OLE-DB, ODBC, LDAP, and Mail, and much more. > > But in some sense ADO is even worse than SomeDB-binding. At least databases > are more or less platform independent. In my view ADO is just as SQL, ODBC > and anything else. I would consider ADO as yet another database interface > to be abstracted away by our Ada(tm) way. So I am for Ada.Database in the > standard. > >> On 2004-11-26 04:15:06 -0500, "Dmitry A. Kazakov" >> <mailbox@dmitry-kazakov.de> said: >>> What about support for MS-Access, MS-SQL server, Oracle? >>> >>> And more importantly why that crappy SQL over and over again? I would like >>> to see a high level Ada.Database[.Relational?] package totally independent >>> on what happens beneath. ^ permalink raw reply [flat|nested] 96+ messages in thread
* Re: Windows Ada database support. 2004-11-28 0:46 ` David Botton @ 2004-11-28 9:51 ` Dmitry A. Kazakov 2004-11-28 10:23 ` Pascal Obry 0 siblings, 1 reply; 96+ messages in thread From: Dmitry A. Kazakov @ 2004-11-28 9:51 UTC (permalink / raw) On Sat, 27 Nov 2004 19:46:58 -0500, David Botton wrote: > While I am not thrilled with the idea of create Ada standards for > bindings to complex externals systems, Yes, that would be too much to swallow. But I meant data bases, narrowly understood. Also a data base is not necessarily an "external" system, Berkeley DB for example. So it is not equivalent. > a good look at the ADO way of > doing things would certainly be a prerequisite to creating such a > standard. Undoubtedly. Though I am a bit sceptical about MS-ways. Just because they changed their "standards" so often that it makes almost no sense to call that standard. Maybe it is illogical, but to me the intention behind is as important as the technical substance of a standard. Or better to say, that substance can be better understood when the true intention is known... -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 96+ messages in thread
* Re: Windows Ada database support. 2004-11-28 9:51 ` Dmitry A. Kazakov @ 2004-11-28 10:23 ` Pascal Obry 2004-11-28 11:03 ` Dmitry A. Kazakov 0 siblings, 1 reply; 96+ messages in thread From: Pascal Obry @ 2004-11-28 10:23 UTC (permalink / raw) "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes: > On Sat, 27 Nov 2004 19:46:58 -0500, David Botton wrote: > > > While I am not thrilled with the idea of create Ada standards for > > bindings to complex externals systems, > > Yes, that would be too much to swallow. But I meant data bases, narrowly > understood. Also a data base is not necessarily an "external" system, > Berkeley DB for example. So it is not equivalent. I think that if we want a database interface in the Ada standard it should be based on ODBC. ODBC is just that a cross-platform standard to access any databases. Maybe it is not the best in term of performance but it is standard, simple, comprehensive well known at this point... and it is always possible to provide external high level libraries not in the standard. Pascal. -- --|------------------------------------------------------ --| Pascal Obry Team-Ada Member --| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE --|------------------------------------------------------ --| http://www.obry.org --| "The best way to travel is by means of imagination" --| --| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595 ^ permalink raw reply [flat|nested] 96+ messages in thread
* Re: Windows Ada database support. 2004-11-28 10:23 ` Pascal Obry @ 2004-11-28 11:03 ` Dmitry A. Kazakov 2004-11-28 14:38 ` Martin Dowie 2004-11-28 18:45 ` Pascal Obry 0 siblings, 2 replies; 96+ messages in thread From: Dmitry A. Kazakov @ 2004-11-28 11:03 UTC (permalink / raw) On 28 Nov 2004 11:23:31 +0100, Pascal Obry wrote: > "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes: > >> On Sat, 27 Nov 2004 19:46:58 -0500, David Botton wrote: >> >>> While I am not thrilled with the idea of create Ada standards for >>> bindings to complex externals systems, >> >> Yes, that would be too much to swallow. But I meant data bases, narrowly >> understood. Also a data base is not necessarily an "external" system, >> Berkeley DB for example. So it is not equivalent. > > I think that if we want a database interface in the Ada standard it should be > based on ODBC. ODBC is just that a cross-platform standard to access any > databases. Maybe it is not the best in term of performance but it is standard, > simple, comprehensive well known at this point... and it is always possible to > provide external high level libraries not in the standard. I am not sure. For one of my projects I even have implemented thick OO-ish bindings to ODBC via GNADE, but I am not satisfied with ODBC. Not just because of performance, which is awful. The very design of ODBC is something. It abstracts SQL, but you still have to use SQL. So it takes the worst of two worlds. Do you know, how to query via ODBC, if the data base supports "PRIMARY KEY" in "CREATE TABLE"? The number of questions like that is countless. The idea, ask how it spelt and tune the application in accordance, is just idiotic. Ada's way(tm) is: I want "type X is range 1..100", go, do what should be done. So in my view ODBC as an implementation (one of), yes of course, but as the template for the standard, God save us! -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 96+ messages in thread
* Re: Windows Ada database support. 2004-11-28 11:03 ` Dmitry A. Kazakov @ 2004-11-28 14:38 ` Martin Dowie 2004-11-28 16:51 ` Marius Amado Alves 2004-11-28 17:29 ` Dmitry A. Kazakov 2004-11-28 18:45 ` Pascal Obry 1 sibling, 2 replies; 96+ messages in thread From: Martin Dowie @ 2004-11-28 14:38 UTC (permalink / raw) Dmitry A. Kazakov wrote: > For one of my projects I even have implemented thick OO-ish bindings to > ODBC via GNADE, but I am not satisfied with ODBC. Not just because of > performance, which is awful. The very design of ODBC is something. It > abstracts SQL, but you still have to use SQL. So it takes the worst of two > worlds. Do you know, how to query via ODBC, if the data base supports > "PRIMARY KEY" in "CREATE TABLE"? The number of questions like that is > countless. The idea, ask how it spelt and tune the application in > accordance, is just idiotic. Ada's way(tm) is: I want "type X is range > 1..100", go, do what should be done. > > So in my view ODBC as an implementation (one of), yes of course, but as the > template for the standard, God save us! For my degree I wrote a abstraction of a relational database in SML/NJ. It could be converted to Ada fairly simply - is that the sort of thing you mean? e.g. package Relations is type Relation is private; ... procedure Union (X, Y : Relation; Result : out Relation); -- etc end Relations; ^ permalink raw reply [flat|nested] 96+ messages in thread
* Re: Windows Ada database support. 2004-11-28 14:38 ` Martin Dowie @ 2004-11-28 16:51 ` Marius Amado Alves 2004-11-28 19:50 ` Martin Dowie 2004-11-28 20:49 ` Christopher Browne 2004-11-28 17:29 ` Dmitry A. Kazakov 1 sibling, 2 replies; 96+ messages in thread From: Marius Amado Alves @ 2004-11-28 16:51 UTC (permalink / raw) To: comp.lang.ada Martin Dowie wrote: > For my degree I wrote a abstraction of a relational database in SML/NJ. This is interesting. What is SML/NJ and is your thesis accessible? ^ permalink raw reply [flat|nested] 96+ messages in thread
* Re: Windows Ada database support. 2004-11-28 16:51 ` Marius Amado Alves @ 2004-11-28 19:50 ` Martin Dowie 2004-11-28 20:49 ` Christopher Browne 1 sibling, 0 replies; 96+ messages in thread From: Martin Dowie @ 2004-11-28 19:50 UTC (permalink / raw) Marius Amado Alves wrote: > > Martin Dowie wrote: > >> For my degree I wrote a abstraction of a relational database in SML/NJ. > > > This is interesting. What is SML/NJ and is your thesis accessible? Thesis isn't available - that I know of! SML/NJ - "Standard Meta-Language/New Jersey", http://www.smlnj.org/ I've loads of other stuff to do right now but I'll try a get a port together one day. -- Martin ^ permalink raw reply [flat|nested] 96+ messages in thread
* Re: Windows Ada database support. 2004-11-28 16:51 ` Marius Amado Alves 2004-11-28 19:50 ` Martin Dowie @ 2004-11-28 20:49 ` Christopher Browne 1 sibling, 0 replies; 96+ messages in thread From: Christopher Browne @ 2004-11-28 20:49 UTC (permalink / raw) Marius Amado Alves <amado.alves@netcabo.pt> wrote: > Martin Dowie wrote: >> For my degree I wrote a abstraction of a relational database in >> SML/NJ. > > This is interesting. What is SML/NJ and is your thesis accessible? That's "Standard ML of New Jersey," a standards-compliant implementation of ML. <http://www.smlnj.org/> Implementing a RDBMS in ML is an interesting idea... -- select 'cbbrowne' || '@' || 'gmail.com'; http://www.ntlug.org/~cbbrowne/linuxdistributions.html "Programming is an unnatural act." -- Alan Perlis ^ permalink raw reply [flat|nested] 96+ messages in thread
* Re: Windows Ada database support. 2004-11-28 14:38 ` Martin Dowie 2004-11-28 16:51 ` Marius Amado Alves @ 2004-11-28 17:29 ` Dmitry A. Kazakov 2004-11-28 17:47 ` Marius Amado Alves 1 sibling, 1 reply; 96+ messages in thread From: Dmitry A. Kazakov @ 2004-11-28 17:29 UTC (permalink / raw) On Sun, 28 Nov 2004 14:38:49 +0000 (UTC), Martin Dowie wrote: > Dmitry A. Kazakov wrote: >> For one of my projects I even have implemented thick OO-ish bindings to >> ODBC via GNADE, but I am not satisfied with ODBC. Not just because of >> performance, which is awful. The very design of ODBC is something. It >> abstracts SQL, but you still have to use SQL. So it takes the worst of two >> worlds. Do you know, how to query via ODBC, if the data base supports >> "PRIMARY KEY" in "CREATE TABLE"? The number of questions like that is >> countless. The idea, ask how it spelt and tune the application in >> accordance, is just idiotic. Ada's way(tm) is: I want "type X is range >> 1..100", go, do what should be done. >> >> So in my view ODBC as an implementation (one of), yes of course, but as the >> template for the standard, God save us! > > For my degree I wrote a abstraction of a relational database in SML/NJ. > It could be converted to Ada fairly simply - is that the sort of thing > you mean? e.g. > > package Relations is > type Relation is private; > ... > procedure Union (X, Y : Relation; Result : out Relation); > -- etc > end Relations; Yes, though I am not sure whether a relational view is the best way of abstraction. But an abstraction should be. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 96+ messages in thread
* Re: Windows Ada database support. 2004-11-28 17:29 ` Dmitry A. Kazakov @ 2004-11-28 17:47 ` Marius Amado Alves 2004-11-28 18:56 ` Dmitry A. Kazakov 0 siblings, 1 reply; 96+ messages in thread From: Marius Amado Alves @ 2004-11-28 17:47 UTC (permalink / raw) To: comp.lang.ada Dmitry A. Kazakov wrote: > Yes, though I am not sure whether a relational view is the best way of > abstraction. But an abstraction should be. For an alternative to the relational model see my Mneson system, based on a network model. The relational model is highly overrated. The most known network models e.g. CODASYL were not pure enough to constitute a true alternative, and now the world now only knows relational. Mneson is pure. ^ permalink raw reply [flat|nested] 96+ messages in thread
* Re: Windows Ada database support. 2004-11-28 17:47 ` Marius Amado Alves @ 2004-11-28 18:56 ` Dmitry A. Kazakov 2004-12-06 14:57 ` Warren W. Gay VE3WWG 0 siblings, 1 reply; 96+ messages in thread From: Dmitry A. Kazakov @ 2004-11-28 18:56 UTC (permalink / raw) On Sun, 28 Nov 2004 17:47:34 +0000, Marius Amado Alves wrote: > Dmitry A. Kazakov wrote: >> Yes, though I am not sure whether a relational view is the best way of >> abstraction. But an abstraction should be. > > For an alternative to the relational model see my Mneson system, based > on a network model. The relational model is highly overrated. The most > known network models e.g. CODASYL were not pure enough to constitute a > true alternative, and now the world now only knows relational. Mneson is > pure. Is anybody here to argue for an hierarchical model to complete the picture? (:-)) Yes, in general I would agree with your assessment. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 96+ messages in thread
* Re: Windows Ada database support. 2004-11-28 18:56 ` Dmitry A. Kazakov @ 2004-12-06 14:57 ` Warren W. Gay VE3WWG 0 siblings, 0 replies; 96+ messages in thread From: Warren W. Gay VE3WWG @ 2004-12-06 14:57 UTC (permalink / raw) Dmitry A. Kazakov wrote: > On Sun, 28 Nov 2004 17:47:34 +0000, Marius Amado Alves wrote: >>Dmitry A. Kazakov wrote: >> >>>Yes, though I am not sure whether a relational view is the best way of >>>abstraction. But an abstraction should be. >> >>For an alternative to the relational model see my Mneson system, based >>on a network model. The relational model is highly overrated. The most >>known network models e.g. CODASYL were not pure enough to constitute a >>true alternative, and now the world now only knows relational. Mneson is >>pure. > > Is anybody here to argue for an hierarchical model to complete the picture? > (:-)) > > Yes, in general I would agree with your assessment. Theory is fine and dandy, and I support the concept of research. In fact it would be better if there was more of that going on. But whether research is happening in earnest or not, doesn't much matter to folks that must write applications today. They need to work with existing products. SQL relational databases, still represents the most practical choice for many applications. And the reason of course that databases are discussed here, is people want to use them effectively from Ada. For hierarchical databases, you have some choices (Windows Registry is one kind of "hierarchical database", though I have issues with its design and use ;-) Because the Reiser file system makes efficient use of disk space, a subdirectory structure can be used nicely as a hierarchical database. This can be neatly wrapped up in a nice Ada API (something on my TODO list). -- Warren W. Gay VE3WWG http://home.cogeco.ca/~ve3wwg ^ permalink raw reply [flat|nested] 96+ messages in thread
* Re: Windows Ada database support. 2004-11-28 11:03 ` Dmitry A. Kazakov 2004-11-28 14:38 ` Martin Dowie @ 2004-11-28 18:45 ` Pascal Obry 2004-11-28 19:13 ` Dmitry A. Kazakov 2004-11-28 20:36 ` Marius Amado Alves 1 sibling, 2 replies; 96+ messages in thread From: Pascal Obry @ 2004-11-28 18:45 UTC (permalink / raw) "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes: > For one of my projects I even have implemented thick OO-ish bindings to > ODBC via GNADE, but I am not satisfied with ODBC. Not just because of > performance, which is awful. The very design of ODBC is something. It > abstracts SQL, but you still have to use SQL. So it takes the worst of two Well that the nice point. It gives you an interface to retrieve data from any SQL statment. Are you really saying that you don't like SQL ? I'm not seeing around another language is is capable of expressing very complexe requests like SQL does. Pascal. -- --|------------------------------------------------------ --| Pascal Obry Team-Ada Member --| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE --|------------------------------------------------------ --| http://www.obry.org --| "The best way to travel is by means of imagination" --| --| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595 ^ permalink raw reply [flat|nested] 96+ messages in thread
* Re: Windows Ada database support. 2004-11-28 18:45 ` Pascal Obry @ 2004-11-28 19:13 ` Dmitry A. Kazakov 2004-11-28 20:04 ` Pascal Obry 2004-11-28 20:36 ` Marius Amado Alves 1 sibling, 1 reply; 96+ messages in thread From: Dmitry A. Kazakov @ 2004-11-28 19:13 UTC (permalink / raw) On 28 Nov 2004 19:45:59 +0100, Pascal Obry wrote: > "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes: > >> For one of my projects I even have implemented thick OO-ish bindings to >> ODBC via GNADE, but I am not satisfied with ODBC. Not just because of >> performance, which is awful. The very design of ODBC is something. It >> abstracts SQL, but you still have to use SQL. So it takes the worst of two > > Well that the nice point. It gives you an interface to retrieve data from any > SQL statment. More to the point. It is XXI century. We are talking about *statements*, it sounds like early 60s. Retrieving data, positioning cursors, stored procedures. Is it about IBM 360 channel program? (:-)) > Are you really saying that you don't like SQL? Yes, more than C++, even more than bash! (:-)) > I'm not seeing > around another language is is capable of expressing very complexe requests > like SQL does. What about Ada! (no smiley now) -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 96+ messages in thread
* Re: Windows Ada database support. 2004-11-28 19:13 ` Dmitry A. Kazakov @ 2004-11-28 20:04 ` Pascal Obry 2004-11-29 9:04 ` Dmitry A. Kazakov 2004-11-29 10:07 ` Adrien Plisson 0 siblings, 2 replies; 96+ messages in thread From: Pascal Obry @ 2004-11-28 20:04 UTC (permalink / raw) "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes: > What about Ada! (no smiley now) Well I love Ada as you probably know, but I do not see Ada as a good replacement for SQL! Pascal. -- --|------------------------------------------------------ --| Pascal Obry Team-Ada Member --| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE --|------------------------------------------------------ --| http://www.obry.org --| "The best way to travel is by means of imagination" --| --| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595 ^ permalink raw reply [flat|nested] 96+ messages in thread
* Re: Windows Ada database support. 2004-11-28 20:04 ` Pascal Obry @ 2004-11-29 9:04 ` Dmitry A. Kazakov 2004-11-29 10:07 ` Adrien Plisson 1 sibling, 0 replies; 96+ messages in thread From: Dmitry A. Kazakov @ 2004-11-29 9:04 UTC (permalink / raw) On 28 Nov 2004 21:04:57 +0100, Pascal Obry wrote: > "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes: > >> What about Ada! (no smiley now) > > Well I love Ada as you probably know, but I do not see Ada as a good > replacement for SQL! I would not put it so wide. Let's narrow it: what is so special in data bases, which makes impossible to use them with Ada? Maybe a flawed analogy, but networking also started with some crippled "languages" like FTP and Telnet. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 96+ messages in thread
* Re: Windows Ada database support. 2004-11-28 20:04 ` Pascal Obry 2004-11-29 9:04 ` Dmitry A. Kazakov @ 2004-11-29 10:07 ` Adrien Plisson 2004-11-29 11:00 ` Alex R. Mosteo 2004-12-01 16:19 ` Pascal Obry 1 sibling, 2 replies; 96+ messages in thread From: Adrien Plisson @ 2004-11-29 10:07 UTC (permalink / raw) Pascal Obry wrote: > "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes: >>What about Ada! (no smiley now) > > Well I love Ada as you probably know, but I do not see Ada as a good > replacement for SQL! you two should try PL/SQL: it is SQL extended with an Ada syntax that allows you to write procedures... if you love Ada, it will make you love SQL. if you love SQL, it will make you love Ada. -- rien ^ permalink raw reply [flat|nested] 96+ messages in thread
* Re: Windows Ada database support. 2004-11-29 10:07 ` Adrien Plisson @ 2004-11-29 11:00 ` Alex R. Mosteo 2004-11-29 13:12 ` Frank Piron 2004-12-01 16:19 ` Pascal Obry 1 sibling, 1 reply; 96+ messages in thread From: Alex R. Mosteo @ 2004-11-29 11:00 UTC (permalink / raw) Adrien Plisson wrote: > Pascal Obry wrote: > >> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes: >> >>> What about Ada! (no smiley now) >> >> >> Well I love Ada as you probably know, but I do not see Ada as a good >> replacement for SQL! > > > you two should try PL/SQL: it is SQL extended with an Ada syntax that > allows you to write procedures... > > if you love Ada, it will make you love SQL. if you love SQL, it will > make you love Ada. Until you come to PL/SQL arrays ;) (or lack thereof). But I love, for example, writing for I in (select something from wherever) loop ^ permalink raw reply [flat|nested] 96+ messages in thread
* Re: Windows Ada database support. 2004-11-29 11:00 ` Alex R. Mosteo @ 2004-11-29 13:12 ` Frank Piron 0 siblings, 0 replies; 96+ messages in thread From: Frank Piron @ 2004-11-29 13:12 UTC (permalink / raw) Mon, 29 Nov 2004 12:00:17 +0100 Alex R. Mosteo <devnull@mailinator.com> wrote: >> if you love Ada, it will make you love SQL. if you love SQL, it will >> make you love Ada. > > Until you come to PL/SQL arrays ;) (or lack thereof). Yes. There are PL/SQL "Tables" (kind of sparse dynamic arrays). But not handy for Ada people. > But I love, for example, writing > > for I in (select something from wherever) loop Implicit "cursor for loops" are beautiful until your app run into the first "snapshot too old" error. -- Frank Piron, defrankatkonaddot (leftrotate two) ^ permalink raw reply [flat|nested] 96+ messages in thread
* Re: Windows Ada database support. 2004-11-29 10:07 ` Adrien Plisson 2004-11-29 11:00 ` Alex R. Mosteo @ 2004-12-01 16:19 ` Pascal Obry 2004-12-02 10:37 ` Marius Amado Alves 1 sibling, 1 reply; 96+ messages in thread From: Pascal Obry @ 2004-12-01 16:19 UTC (permalink / raw) Adrien Plisson <aplisson-news@stochastique.net> writes: > Pascal Obry wrote: > > "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes: > >>What about Ada! (no smiley now) > > Well I love Ada as you probably know, but I do not see Ada as a good > > replacement for SQL! I know PL/SQL and I like it indeed ! Pascal. -- --|------------------------------------------------------ --| Pascal Obry Team-Ada Member --| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE --|------------------------------------------------------ --| http://www.obry.org --| "The best way to travel is by means of imagination" --| --| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595 ^ permalink raw reply [flat|nested] 96+ messages in thread
* Re: Windows Ada database support. 2004-12-01 16:19 ` Pascal Obry @ 2004-12-02 10:37 ` Marius Amado Alves 2004-12-02 10:58 ` Frank Piron 2004-12-03 2:50 ` John B. Matthews 0 siblings, 2 replies; 96+ messages in thread From: Marius Amado Alves @ 2004-12-02 10:37 UTC (permalink / raw) To: comp.lang.ada "I know PL/SQL and I like it indeed !" (Pascal.) And the fact that it looks a lot like Ada has nothing to do with it :-) ^ permalink raw reply [flat|nested] 96+ messages in thread
* Re: Windows Ada database support. 2004-12-02 10:37 ` Marius Amado Alves @ 2004-12-02 10:58 ` Frank Piron 2004-12-03 2:50 ` John B. Matthews 1 sibling, 0 replies; 96+ messages in thread From: Frank Piron @ 2004-12-02 10:58 UTC (permalink / raw) Am Thu, 02 Dec 2004 10:37:22 +0000 schrieb Marius Amado Alves <amado.alves@netcabo.pt>: > "I know PL/SQL and I like it indeed !" (Pascal.) > > And the fact that it looks a lot like Ada has nothing to do with it :-) > I was pointed to Ada via PL/SQL, because i read somewhere in the Oracle Doc that PL/SQL was initially derived from Ada83. -- Frank Piron, defrankatkonaddot (leftrotate two) ^ permalink raw reply [flat|nested] 96+ messages in thread
* Re: Windows Ada database support. 2004-12-02 10:37 ` Marius Amado Alves 2004-12-02 10:58 ` Frank Piron @ 2004-12-03 2:50 ` John B. Matthews 1 sibling, 0 replies; 96+ messages in thread From: John B. Matthews @ 2004-12-03 2:50 UTC (permalink / raw) In article <mailman.166.1101983875.10401.comp.lang.ada@ada-france.org>, Marius Amado Alves <amado.alves@netcabo.pt> wrote: > "I know PL/SQL and I like it indeed !" (Pascal.) > > And the fact that it looks a lot like Ada has nothing to do with it :-) Server-side procedures with Ada syntax! What's not to like? :-) To understand PL/SQL, it's helpful to recall that SQL is a declarative language: the desired result is specified; the details of getting that result are not. PL/SQL is a procedural "wrapper" that permits embedded SQL statements to be executed and the results examined. PL/SQL's use of Ada syntax lends a pleasant clarity to database programming. In particular, the Ada package concept allows related database objects to be grouped together in a familiar ADT style. Veterans of Ada may be disappointed by the relative lack of support for type extension and concurrency. In its defense, PL/SQL fully supports a rich set of database types, and concurrency is handled by the database engine itself. You can learn more about PL/SQL from the corresponding Oracle manual. It's available on TechNet, registration required: <http://download-west.oracle.com/docs/cd/B14117_01/appdev.101/b10807/ toc.htm> -- John jmatthews at wright dot edu www dot wright dot edu/~john.matthews/ ^ permalink raw reply [flat|nested] 96+ messages in thread
* Re: Windows Ada database support. 2004-11-28 18:45 ` Pascal Obry 2004-11-28 19:13 ` Dmitry A. Kazakov @ 2004-11-28 20:36 ` Marius Amado Alves 2004-11-29 1:40 ` Georg Bauhaus 1 sibling, 1 reply; 96+ messages in thread From: Marius Amado Alves @ 2004-11-28 20:36 UTC (permalink / raw) To: comp.lang.ada Pascal Obry wrote: > I'm not seeing > around another language is is capable of expressing very complexe requests > like SQL does. XQuery, the Mneson Calculus and a host of other languages are no less expressive than SQL, and same much more elegant and sound. ^ permalink raw reply [flat|nested] 96+ messages in thread
* Re: Windows Ada database support. 2004-11-28 20:36 ` Marius Amado Alves @ 2004-11-29 1:40 ` Georg Bauhaus 2004-11-29 10:30 ` Marius Amado Alves 0 siblings, 1 reply; 96+ messages in thread From: Georg Bauhaus @ 2004-11-29 1:40 UTC (permalink / raw) Marius Amado Alves <amado.alves@netcabo.pt> wrote: : Pascal Obry wrote: : > I'm not seeing :> around another language is is capable of expressing very complexe requests :> like SQL does. : : XQuery, the Mneson Calculus and a host of other languages are no less : expressive than SQL, and same much more elegant and sound. And read-only. ^ permalink raw reply [flat|nested] 96+ messages in thread
* Re: Windows Ada database support. 2004-11-29 1:40 ` Georg Bauhaus @ 2004-11-29 10:30 ` Marius Amado Alves 0 siblings, 0 replies; 96+ messages in thread From: Marius Amado Alves @ 2004-11-29 10:30 UTC (permalink / raw) To: comp.lang.ada Georg Bauhaus wrote: > Marius Amado Alves <amado.alves@netcabo.pt> wrote: > : Pascal Obry wrote: > : > I'm not seeing > :> around another language is is capable of expressing very complexe requests > :> like SQL does. > : > : XQuery, the Mneson Calculus and a host of other languages are no less > : expressive than SQL, and same much more elegant and sound. > > And read-only. Sorry, I interpreted "request" as "query." Naturaly Mneson can update too. The two primitives are connect two vertices, disconnect two vertices. See also Mntext. (I'm working on Uniformal, the Mneson language that encompasses all these aspects. I can send drafts if wanted.) XQuery cannot update, no. But I'm sure there is a subset of the myriad XLanguages that does. (Note I do not endorse the XML way. Mneson is partly a reaction to its *unnecessary* complexity.) ^ permalink raw reply [flat|nested] 96+ messages in thread
* Re: Windows Ada database support. 2004-11-26 9:15 ` Dmitry A. Kazakov 2004-11-26 18:36 ` David Botton @ 2004-11-29 1:28 ` Georg Bauhaus 2004-11-29 8:53 ` Dmitry A. Kazakov 2004-11-29 12:56 ` Marius Amado Alves ` (2 subsequent siblings) 4 siblings, 1 reply; 96+ messages in thread From: Georg Bauhaus @ 2004-11-29 1:28 UTC (permalink / raw) Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> wrote: : And more importantly why that crappy SQL over and over again? I would like : to see a high level Ada.Database[.Relational?] package totally independent : on what happens beneath. Because Ada is a high level systems programming language making you expect to be in control of well defined details? What about COMMIT? At what time should Oracle CURSORs be given up? How much precision can you portably specify for floating point values in your DB independent package? -- Georg Bauhaus ^ permalink raw reply [flat|nested] 96+ messages in thread
* Re: Windows Ada database support. 2004-11-29 1:28 ` Georg Bauhaus @ 2004-11-29 8:53 ` Dmitry A. Kazakov 2004-11-29 11:09 ` Georg Bauhaus 0 siblings, 1 reply; 96+ messages in thread From: Dmitry A. Kazakov @ 2004-11-29 8:53 UTC (permalink / raw) On Mon, 29 Nov 2004 01:28:03 +0000 (UTC), Georg Bauhaus wrote: > Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> wrote: >: And more importantly why that crappy SQL over and over again? I would like >: to see a high level Ada.Database[.Relational?] package totally independent >: on what happens beneath. > > Because Ada is a high level systems programming language making > you expect to be in control of well defined details? Yes. > What about COMMIT? That's easy. There should be a transaction object, kind of "external" protected object. BTW, there is an interesting Ada problem associated with it. When I wrote ODBC bindings I faced this problem: declare -- Transaction in manual-commit mode Mutex : Write_Mutex (Connection'Access); begin ... -- Do some DB stuff Commit (Mutex); -- Nasty, but necessary end; Upon exception Write_Mutex.Finalize does roll-back. This in turn requires that nasty call to Commit at the end of the scope. Commit just sets a flag in Write_Mutex for Finalize. Because in Finalize there is no way to determine whether the scope was left due to a stack roll-back upon an exception. Probably it is worth an AI for Ada 2010. > At what time should Oracle CURSORs be given up? What about n-th level of CPU cache? Do you really care when you write an Ada application? It is all compiler vendor business. As an application developer, I want to hear nothing about cursors. > How much precision can you portably specify for floating point > values in your DB independent package? The required precision should specify the application. And BTW, for a great majority of applications that should rather be fixed point. So you can't have any default. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 96+ messages in thread
* Re: Windows Ada database support. 2004-11-29 8:53 ` Dmitry A. Kazakov @ 2004-11-29 11:09 ` Georg Bauhaus 2004-11-29 12:01 ` Dmitry A. Kazakov 0 siblings, 1 reply; 96+ messages in thread From: Georg Bauhaus @ 2004-11-29 11:09 UTC (permalink / raw) Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> wrote: : : There should be a transaction object, kind of "external" : protected object. Interesting idea. :> At what time should Oracle CURSORs be given up? : : What about n-th level of CPU cache? Do you really care when you write an : Ada application? Is it unusual to think about hardware, timing, resources, ... when you write an Ada application? The moment my DB-software is to be portable, I might not want to have to think about DB specific things. In the case of Oracle cursors it turns out that you might have to manually free resources. Certainly this has effects on the performance characteristics, design etc. And my choice cannot be decided by the vendor. : It is all compiler vendor business. As an application : developer, I want to hear nothing about cursors. Neither would I but I have to. :> How much precision can you portably specify for floating point :> values in your DB independent package? : : The required precision should specify the application. Yes but this also influences what will be in this version of that DB. ^ permalink raw reply [flat|nested] 96+ messages in thread
* Re: Windows Ada database support. 2004-11-29 11:09 ` Georg Bauhaus @ 2004-11-29 12:01 ` Dmitry A. Kazakov 2004-11-29 14:07 ` Georg Bauhaus 0 siblings, 1 reply; 96+ messages in thread From: Dmitry A. Kazakov @ 2004-11-29 12:01 UTC (permalink / raw) On Mon, 29 Nov 2004 11:09:25 +0000 (UTC), Georg Bauhaus wrote: > Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> wrote: > >:> At what time should Oracle CURSORs be given up? >: >: What about n-th level of CPU cache? Do you really care when you write an >: Ada application? > > Is it unusual to think about hardware, timing, resources, ... > when you write an Ada application? In terms of differences between P4 and AMD? One thinks about resources in terms of the abstraction layer used in the application. > The moment my DB-software is to be portable, I might not want to have to think > about DB specific things. In the case of Oracle cursors it turns out that > you might have to manually free resources. Certainly this has effects > on the performance characteristics, design etc. > And my choice cannot be decided by the vendor. I meant the vendor of Ada.Database. It is up to the library implementation to take care about all Oracle specific things directly or indirectly (over ODBC, SQL or whatsoever layer). It is no different from, say, GTK, which hides from you either Win32 or X11. You do not care about closing windows handles when you are using GTK. >: It is all compiler vendor business. As an application >: developer, I want to hear nothing about cursors. > > Neither would I but I have to. Yes, because bindings are thin. >:> How much precision can you portably specify for floating point >:> values in your DB independent package? >: >: The required precision should specify the application. > > Yes but this also influences what will be in this version of that > DB. So what? As long as my application uses Ada.Database, I do not care. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 96+ messages in thread
* Re: Windows Ada database support. 2004-11-29 12:01 ` Dmitry A. Kazakov @ 2004-11-29 14:07 ` Georg Bauhaus 2004-11-29 18:04 ` Dmitry A. Kazakov 0 siblings, 1 reply; 96+ messages in thread From: Georg Bauhaus @ 2004-11-29 14:07 UTC (permalink / raw) Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> wrote: : It is no different from, say, GTK, which : hides from you either Win32 or X11. You do not care about closing windows : handles when you are using GTK. Depending on how my application must use windows, I might have to think about closing window handles. :>: It is all compiler vendor business. As an application :>: developer, I want to hear nothing about cursors. :> :> Neither would I but I have to. : : Yes, because bindings are thin. No, I have to think about cursors because - they have a life time, - they are linked to a limited number of connections, - they are a limited resource themselves, - and they point to shared data, subject to updates. This is interfacing to "world", not to some abstraction. The real problems have got little to do with the thickness of bindings, I think. In a multitasking, multiclient environment use of resources like cursors pointing to shared structured data means a lot in terms of resources as I'm sure you know. There is the additional burdon of managing a number of transaction logs, which is costly, and might incur locking. See also Frank Piron's comment about implicit cursors in PL/SQL. :>:> How much precision can you portably specify for floating point :>:> values in your DB independent package? :>: :>: The required precision should specify the application. :> :> Yes but this also influences what will be in this version of that :> DB. : : So what? As long as my application uses Ada.Database, I do not care. You should care. For instance, you might have large amounts of numeric data and your DB can store them as strings of decimal digits using thick Ada.Database facilities, or else you have to manually tweak and force things at low level and use tricks. Thick abstractions might take too much time. Thick abstractions leave some choices behind. This isn't always helpful. ^ permalink raw reply [flat|nested] 96+ messages in thread
* Re: Windows Ada database support. 2004-11-29 14:07 ` Georg Bauhaus @ 2004-11-29 18:04 ` Dmitry A. Kazakov 2004-11-29 22:05 ` Georg Bauhaus 0 siblings, 1 reply; 96+ messages in thread From: Dmitry A. Kazakov @ 2004-11-29 18:04 UTC (permalink / raw) On Mon, 29 Nov 2004 14:07:45 +0000 (UTC), Georg Bauhaus wrote: > Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> wrote: > >: It is no different from, say, GTK, which >: hides from you either Win32 or X11. You do not care about closing windows >: handles when you are using GTK. > > Depending on how my application must use windows, I might have to think > about closing window handles. ... under X11. >:>: It is all compiler vendor business. As an application >:>: developer, I want to hear nothing about cursors. >:> >:> Neither would I but I have to. >: >: Yes, because bindings are thin. > > No, I have to think about cursors because > - they have a life time, > - they are linked to a limited number of connections, > - they are a limited resource themselves, > - and they point to shared data, subject to updates. > > This is interfacing to "world", not to some abstraction. The real > problems have got little to do with the thickness of bindings, I think. > In a multitasking, multiclient environment use of resources like cursors > pointing to shared structured data means a lot in terms of resources as > I'm sure you know. There is the additional burdon of managing a number > of transaction logs, which is costly, and might incur locking. Which only supports the point that cursor might be wrong abstraction. > See also Frank Piron's comment about implicit cursors in > PL/SQL. > >:>:> How much precision can you portably specify for floating point >:>:> values in your DB independent package? >:>: >:>: The required precision should specify the application. >:> >:> Yes but this also influences what will be in this version of that >:> DB. >: >: So what? As long as my application uses Ada.Database, I do not care. > > You should care. For instance, you might have large amounts of numeric data > and your DB can store them as strings of decimal digits using thick > Ada.Database facilities, or else you have to manually tweak and force things > at low level and use tricks. Thick abstractions might take too much time. > Thick abstractions leave some choices behind. This isn't always helpful. Surely, but statistically irrelevant. Otherwise we would have no Ada and still were programming in assembly. So there were no cursors, no data base engines, no operating systems etc. Because one can always imagine a case, where manual positioning of the hard drive heads could be essential for performance. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 96+ messages in thread
* Re: Windows Ada database support. 2004-11-29 18:04 ` Dmitry A. Kazakov @ 2004-11-29 22:05 ` Georg Bauhaus 2004-11-30 11:00 ` Dmitry A. Kazakov 0 siblings, 1 reply; 96+ messages in thread From: Georg Bauhaus @ 2004-11-29 22:05 UTC (permalink / raw) Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> wrote: : On Mon, 29 Nov 2004 14:07:45 +0000 (UTC), Georg Bauhaus wrote: :> This is interfacing to "world", not to some abstraction. : Which only supports the point that cursor might be wrong abstraction. Aha. Cursors are not an abstraction from the point of view of an Ada program. SQL Cursors are a given part of the "world", in this case, the data base system. Go argue with Oracle Corp. :> See also Frank Piron's comment about implicit cursors in :> PL/SQL. Wrong abstractions in PL/SQL too? :>: So what? As long as my application uses Ada.Database, I do not care. Is this a motto? :> Thick abstractions leave some choices behind. This isn't always helpful. : Surely, but statistically irrelevant. Aha. But allow me to say, as much as I'd wish to be able to use a nice transparent, almost invisible interface to database system, I see no base in reality for saying that abstraction thickness is statistically irrelevant. For several reasons, and also because - cursors do occur, no matter whether you express them behind Ada abstractions or not. Working with snapshots affects performance/ shared resources to the point where you can no longer hide them relying on some AI system to free the resources automatically so the system keeps running. Working with RDBMSs means to have influence on another program's multiply shared data in soft real time! However, your program doesn't control that other program, your program must be well-behaved. Show me how to do this in some Ada.Databases. - saying that performance/resources in database systems are statistically irrelevant makes me think that your perspective on DBs is different from mine, and probably not just mine ;-) : Otherwise we would have no Ada and still were programming in assembly. What has Ada versus Assembly got to do with resource consumption of communicating programs (Ada program <-> database program?) Other than trying a rhetorical trick to support a notion of statistical irrelevance of SQL cursors in RDBMS? ;-) -- Georg Bauhaus ^ permalink raw reply [flat|nested] 96+ messages in thread
* Re: Windows Ada database support. 2004-11-29 22:05 ` Georg Bauhaus @ 2004-11-30 11:00 ` Dmitry A. Kazakov 2004-11-30 13:46 ` Ole-Hjalmar Kristensen 2004-11-30 16:07 ` Georg Bauhaus 0 siblings, 2 replies; 96+ messages in thread From: Dmitry A. Kazakov @ 2004-11-30 11:00 UTC (permalink / raw) On Mon, 29 Nov 2004 22:05:50 +0000 (UTC), Georg Bauhaus wrote: > Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> wrote: >: On Mon, 29 Nov 2004 14:07:45 +0000 (UTC), Georg Bauhaus wrote: > >:> This is interfacing to "world", not to some abstraction. > >: Which only supports the point that cursor might be wrong abstraction. > > Aha. > > Cursors are not an abstraction from the point of view of an Ada > program. SQL Cursors are a given part of the "world", in this case, the > data base system. Go argue with Oracle Corp. You are mixing abstractions and things [of the "world"]. The goal of an abstraction is to get rid of things [by replacing them by other, abstract, things]. >:> See also Frank Piron's comment about implicit cursors in >:> PL/SQL. > > Wrong abstractions in PL/SQL too? Is in your opinion PL/SQL better than Ada? >:>: So what? As long as my application uses Ada.Database, I do not care. > > Is this a motto? As long as the goal is to have a generic data base interface. >:> Thick abstractions leave some choices behind. This isn't always helpful. > >: Surely, but statistically irrelevant. > > Aha. But allow me to say, as much as I'd wish to be able to use > a nice transparent, almost invisible interface to database system, > I see no base in reality for saying that abstraction thickness is > statistically irrelevant. For several reasons, and also because > > - cursors do occur, no matter whether you express them behind Ada > abstractions or not. Working with snapshots affects performance/ > shared resources to the point where you can no longer hide them relying > on some AI system to free the resources automatically so the system > keeps running. This is a typical lack of abstraction. It is difficult to develop something large, complex and concurrent using only arrays. As a matter of fact. This is why thick bindings are so necessary. After all Ada's protected type is just a thick binding to a chunk of raw memory. You may argue that X'Address occur, would you? > Working with RDBMSs means to have influence on another program's > multiply shared data in soft real time! However, your program doesn't > control that other program, your program must be well-behaved. Show me > how to do this in some Ada.Databases. The same way we program concurrent distributed applications in Ada! A transaction is just an equivalent of protected procedure or rendezvous. For more advanced technique you should have higher abstraction, you should go ADT, OO, and so get rid of raw table views. Especially because there might be data bases for which table views could be very inefficient. > - saying that performance/resources in database systems are statistically > irrelevant makes me think that your perspective on DBs is different > from mine, and probably not just mine ;-) Performance is relevant, but you cannot achieve it maintaining that low level of abstraction. There is just a physical limit of application complexity for each level. IMO, DB applications have outgrown tables and cursors long time ago. Just look how many DB programmer positions are offered. This is a significant indicator, that the technology is outdated. >: Otherwise we would have no Ada and still were programming in assembly. > > What has Ada versus Assembly got to do with resource consumption of > communicating programs (Ada program <-> database program?) It is because you present performance as an argument for using a low level mechanism. It is a fundamentally flawed argument. The whole history of computer development is against it. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 96+ messages in thread
* Re: Windows Ada database support. 2004-11-30 11:00 ` Dmitry A. Kazakov @ 2004-11-30 13:46 ` Ole-Hjalmar Kristensen 2004-11-30 15:04 ` Dmitry A. Kazakov 2004-11-30 16:09 ` Georg Bauhaus 2004-11-30 16:07 ` Georg Bauhaus 1 sibling, 2 replies; 96+ messages in thread From: Ole-Hjalmar Kristensen @ 2004-11-30 13:46 UTC (permalink / raw) >>>>> "DAK" == Dmitry A Kazakov <mailbox@dmitry-kazakov.de> writes: <snip> DAK> This is why thick bindings are so necessary. After all Ada's protected type DAK> is just a thick binding to a chunk of raw memory. You may argue that DAK> X'Address occur, would you? >> Working with RDBMSs means to have influence on another program's >> multiply shared data in soft real time! However, your program doesn't >> control that other program, your program must be well-behaved. Show me >> how to do this in some Ada.Databases. DAK> The same way we program concurrent distributed applications in Ada! A DAK> transaction is just an equivalent of protected procedure or rendezvous. For DAK> more advanced technique you should have higher abstraction, you should go DAK> ADT, OO, and so get rid of raw table views. Especially because there might DAK> be data bases for which table views could be very inefficient. The transaction concept is significantly more powerful and complex than protected procedures or rendezvous mechanisms in programming languages. Unless your abstraction layer gives you full access to the complete transaction apparatus in a DB-independent way, it simply won't fly. You want to abstract away confusing details and differences in implementation, not simplifying the underlying concept so much as being unusable. >> - saying that performance/resources in database systems are statistically >> irrelevant makes me think that your perspective on DBs is different >> from mine, and probably not just mine ;-) DAK> Performance is relevant, but you cannot achieve it maintaining that low DAK> level of abstraction. There is just a physical limit of application DAK> complexity for each level. IMO, DB applications have outgrown tables and DAK> cursors long time ago. Just look how many DB programmer positions are DAK> offered. This is a significant indicator, that the technology is outdated. Cursors are somewhat evil, and certainly over-used. Relational algebra is not on a particularly low abstraction level, and certainly higher than the typical procedural manipulations you do within a programming language. It is certainly arguable whether there *are* better abstractions than the (object) relational model at the moment. Object-oriented databases certainly are not a better alternative for most applications. >> : Otherwise we would have no Ada and still were programming in assembly. >> >> What has Ada versus Assembly got to do with resource consumption of >> communicating programs (Ada program <-> database program?) DAK> It is because you present performance as an argument for using a low level DAK> mechanism. It is a fundamentally flawed argument. The whole history of DAK> computer development is against it. DAK> -- DAK> Regards, DAK> Dmitry A. Kazakov DAK> http://www.dmitry-kazakov.de -- C++: The power, elegance and simplicity of a hand grenade. ^ permalink raw reply [flat|nested] 96+ messages in thread
* Re: Windows Ada database support. 2004-11-30 13:46 ` Ole-Hjalmar Kristensen @ 2004-11-30 15:04 ` Dmitry A. Kazakov 2004-11-30 16:09 ` Georg Bauhaus 1 sibling, 0 replies; 96+ messages in thread From: Dmitry A. Kazakov @ 2004-11-30 15:04 UTC (permalink / raw) On 30 Nov 2004 14:46:13 +0100, Ole-Hjalmar Kristensen wrote: > The transaction concept is significantly more powerful and complex > than protected procedures or rendezvous mechanisms in programming > languages. Transaction is an atomic change. It is definitely less powerful than general notion of protected operation. Can you requeue a transaction? Can you synchronize on a transaction? > Cursors are somewhat evil, and certainly over-used. Relational algebra > is not on a particularly low abstraction level, and certainly higher > than the typical procedural manipulations you do within a programming > language. What makes you think so? If the above were true, then it would directly imply Ada and other compilers should be written in SQL. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 96+ messages in thread
* Re: Windows Ada database support. 2004-11-30 13:46 ` Ole-Hjalmar Kristensen 2004-11-30 15:04 ` Dmitry A. Kazakov @ 2004-11-30 16:09 ` Georg Bauhaus 1 sibling, 0 replies; 96+ messages in thread From: Georg Bauhaus @ 2004-11-30 16:09 UTC (permalink / raw) Ole-Hjalmar Kristensen <ole-hjalmar.kristensen@substitute_employer_here.com> wrote: : You want to abstract away confusing details and differences : in implementation, not simplifying the underlying concept so much as : being unusable. Thank you for saying this so clearly. -- Georg Bauhaus ^ permalink raw reply [flat|nested] 96+ messages in thread
* Re: Windows Ada database support. 2004-11-30 11:00 ` Dmitry A. Kazakov 2004-11-30 13:46 ` Ole-Hjalmar Kristensen @ 2004-11-30 16:07 ` Georg Bauhaus 2004-11-30 18:52 ` Dmitry A. Kazakov 1 sibling, 1 reply; 96+ messages in thread From: Georg Bauhaus @ 2004-11-30 16:07 UTC (permalink / raw) Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> wrote: : On Mon, 29 Nov 2004 22:05:50 +0000 (UTC), Georg Bauhaus wrote: :>:> See also Frank Piron's comment about implicit cursors in :>:> PL/SQL. :> :> Wrong abstractions in PL/SQL too? : : Is in your opinion PL/SQL better than Ada? PL/SQL has a specific purpose, and a rich set of facilities for handling relations. I don't see why anyone using an Oracle DB would want to write stored procedures in Ada? :>:>: So what? As long as my application uses Ada.Database, I do not care. :> :> Is this a motto? : : As long as the goal is to have a generic data base interface. Well, the prime goal for me has got to be an application that works within the limits set by the RDBMS, in this case Oracle. If I have to "descend" to sequential access or to random access via cursors, so be it. : It is difficult to develop something : large, complex and concurrent using only arrays. As a matter of fact. Say that to someone you uses one of the array programming languages... SQL is much more than just arrays. It also has sets and tables and cursors. Like Ada 2005. Indeed RDBMSs have some low level features, but why not? There are DBs based on different data structures, like extensible types. Nice as they are, they do have real time limits, as a matter of fact. And they do not always match the types of application data, which can be of a rather fixed shape. : The same way we program concurrent distributed applications in Ada! And you know what people say about task switching? Rendevous has its temporal aspects, how do you abstract them away? There are others who want to use the database, too, so "could you please stop shaking hands and give us some of the resources back if you don't need them any longer!" : ADT, OO, and so get rid of raw table views. Especially because there might : be data bases for which table views could be very inefficient. I'd leave RDBs only when table views are a burden, not because there might be cases. : IMO, DB applications have outgrown tables and : cursors long time ago. That may well depend on data. The "low level" Ada.Containers might be used to implement something more abstract. Does every part of a large Ada program outgrow Ada.Containers? How can I build a generic abstraction on top of Ada.Containers that covers all aspects of recourse consumption automagically? BTW, thinking of accounting, the stock exchange, time series, measurements, there are lots tabular data, and a sequence of records is fine as a data structure. Something as useful as a list together with predicates and recursion, depending on the application. Or, in imperative terms, a vector together with predicates and iteration? However, if you look at SETL2 or Haskell (which does have type classes which I'd guess you will like very much), there are cases where you have to use dumb old ways of manipulating data in a "low level" way. For example, you cannot just built a ton of sets and feed them to existential quantifiers, because this will quickly consume all of the available resources. Quicksort in SETL2 and Haskell is the standard example. This always happens the moment you have many data, or when you use high level constructs in too generous combinations. Can you present an efficient sort that is built around if # > 1 then sort {smaller} + arb + sort {larger} else arb end and that is high level, ADT, OO, using available processors, etc. and *still* uses a fairly small amount of memory in addition to the memory consumed by data? : Just look how many DB programmer positions are : offered. This is a significant indicator, that the technology is outdated. For me the number of database adminstrators/programmers has to do with the number of significant installations and the number of projects. This number depends on the number of organisations, and on their willingness/ability to invest. I don't think that the number of wealthy organisations will change significantly because some programming techniques evolve. :> What has Ada versus Assembly got to do with resource consumption of :> communicating programs (Ada program <-> database program?) : : It is because you present performance as an argument for using a low level : mechanism. I present resource consumption as a real time constraint on the structure of data and on techniques of data access. : It is a fundamentally flawed argument. The whole history of : computer development is against it. The history of computer development has it, that there are commercially viable successors to APL in use at companies using big data bases. Incidentally, APL is a high level functional language built around arrays... -- Georg Bauhaus ^ permalink raw reply [flat|nested] 96+ messages in thread
* Re: Windows Ada database support. 2004-11-30 16:07 ` Georg Bauhaus @ 2004-11-30 18:52 ` Dmitry A. Kazakov 2004-11-30 21:10 ` Georg Bauhaus 0 siblings, 1 reply; 96+ messages in thread From: Dmitry A. Kazakov @ 2004-11-30 18:52 UTC (permalink / raw) On Tue, 30 Nov 2004 16:07:06 +0000 (UTC), Georg Bauhaus wrote: > Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> wrote: >: On Mon, 29 Nov 2004 22:05:50 +0000 (UTC), Georg Bauhaus wrote: >:>:> See also Frank Piron's comment about implicit cursors in >:>:> PL/SQL. >:> >:> Wrong abstractions in PL/SQL too? >: >: Is in your opinion PL/SQL better than Ada? > > PL/SQL has a specific purpose, and a rich set of facilities for handling > relations. 1. Why relations should be handled? 2. Why Ada cannot handle them? > I don't see why anyone using an Oracle DB would want to write > stored procedures in Ada? Fair enough. Compare: "I don't see why anybody using C would want to switch to Ada". Indeed, they don't. >:>:>: So what? As long as my application uses Ada.Database, I do not care. >:> >:> Is this a motto? >: >: As long as the goal is to have a generic data base interface. > > Well, the prime goal for me has got to be an application that works > within the limits set by the RDBMS, in this case Oracle. If I have > to "descend" to sequential access or to random access via cursors, > so be it. You could simply say: we need no generic data base interface. >: It is difficult to develop something >: large, complex and concurrent using only arrays. As a matter of fact. > > Say that to someone you uses one of the array programming languages... > > SQL is much more than just arrays. It also has sets and tables and > cursors. Like Ada 2005. > > Indeed RDBMSs have some low level features, but why not? There are > DBs based on different data structures, like extensible types. > Nice as they are, they do have real time limits, as a matter of fact. So the point is: "real-time constraints cannot be met if data structures are extensible"? > And they do not always match the types of application data, which > can be of a rather fixed shape. Why? From my experience, there was no single case, when our customer didn't ask for an extensible data model [and was told that he/she cannot afford it]. Sooner or later they will break the wall. >: The same way we program concurrent distributed applications in Ada! > > And you know what people say about task switching? Rendevous has > its temporal aspects, how do you abstract them away? I wouldn't. But it is perfectly possible. In C, which has no tasks, an entry is replaced by a procedure with an additional parameter TimeOut. > There are > others who want to use the database, too, so "could you please stop > shaking hands and give us some of the resources back if you don't > need them any longer!" I do not see why exposing, say, tasks should be less effective than hiding them into connections, transactions whatsoever. Basically I am unable to see any crucial difference between a data base engine or embedded controller or JVM. Tell me 1. Why Ada cannot be targeted there? 2. Why Ada will be less efficient than SQL? >: ADT, OO, and so get rid of raw table views. Especially because there might >: be data bases for which table views could be very inefficient. > > I'd leave RDBs only when table views are a burden, not because there > might be cases. OK, in data acquisition it is a heavy burden. Customers wish a table (equidistant time, value1, value2 etc). But the system is event/data driven. So the table basically contains useless garbage. Yet they still want it, because tables are so cool. >: Just look how many DB programmer positions are >: offered. This is a significant indicator, that the technology is outdated. > > For me the number of database adminstrators/programmers has to do > with the number of significant installations and the number of > projects. > This number depends on the number of organisations, and on their > willingness/ability to invest. I don't think that the number of > wealthy organisations will change significantly because some > programming techniques evolve. They will invest in other things. Nowadays, nobody invests in chopping firewood... >:> What has Ada versus Assembly got to do with resource consumption of >:> communicating programs (Ada program <-> database program?) >: >: It is because you present performance as an argument for using a low level >: mechanism. > > I present resource consumption as a real time constraint > on the structure of data and on techniques of data access. But you do not explain why SELECT * is less resource consuming than anything else. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 96+ messages in thread
* Re: Windows Ada database support. 2004-11-30 18:52 ` Dmitry A. Kazakov @ 2004-11-30 21:10 ` Georg Bauhaus 2004-12-01 9:11 ` Dmitry A. Kazakov 0 siblings, 1 reply; 96+ messages in thread From: Georg Bauhaus @ 2004-11-30 21:10 UTC (permalink / raw) Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> wrote: : On Tue, 30 Nov 2004 16:07:06 +0000 (UTC), Georg Bauhaus wrote: : :> Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> wrote: :>: On Mon, 29 Nov 2004 22:05:50 +0000 (UTC), Georg Bauhaus wrote: :>:>:> See also Frank Piron's comment about implicit cursors in :>:>:> PL/SQL. :>:> :>:> Wrong abstractions in PL/SQL too? :>: :>: Is in your opinion PL/SQL better than Ada? :> :> PL/SQL has a specific purpose, and a rich set of facilities for handling :> relations. : : 1. Why relations should be handled? : 2. Why Ada cannot handle them? One reaon that Ada, as is, cannot handle the same set of problems as PL/SQL with the same ease is, I think, that PL/SQL is a programming language with built in support for database operations. You'd have to define at least everything that has been defined (or not) for PL/SQL, taking into account all Ada features and requirements. :> I don't see why anyone using an Oracle DB would want to write :> stored procedures in Ada? : : Fair enough. Compare: "I don't see why anybody using C would want to switch : to Ada". Indeed, they don't. Some do switch from C to Ada, because Ada solves a problem. If the task at hand is to write a conditionally triggered procedure that processes a value before it is inserted into a table, and hides this fact away from a client, that's fairly easy in PL/SQL. It's just not there in Ada, AFAIKT. What is your estimate of the effort it takes to merge this into Ada packages at a nice level of abstraction? For comparison, have a look at APQ, then at GNADE. : You could simply say: we need no generic data base interface. In fact we have convenience objects, but still it is necessary that we can get through to the database. : So the point is: "real-time constraints cannot be met if data structures : are extensible"? If real-time constraints cannot be met using a DB system storing more fancy data structures, I have to look for an alternative solution. The opposite direction away from RDBs seems to be a big problem; as has been mentioned, we have some object-relational DBs, some more advance O-O DBs, and some DBs that can store XML-like documents. Have a look at Microsoft's WinFS plans. Consider how long it takes for the biggest and richest software company to come up with something working. Substract compatibility issues and the profit made by selling interim improvements. Is it easy to build something that covers more than RDBMSs do? :> And they do not always match the types of application data, which :> can be of a rather fixed shape. : Why? There are things whose property set doesn't change frequently ;-) : From my experience, there was no single case, when our customer didn't : ask for an extensible data model [and was told that he/she cannot afford : it]. Sooner or later they will break the wall. Yes, sounds familiar, but first, hitting the wall is not equal to ruin as the technicians like to think ;-) and second, you'd have to demonstrate that an extended data model can be realized by just extending types. It might be necessary to add or change change types and add or change relations between types etc. :>: The same way we program concurrent distributed applications in Ada! :> :> And you know what people say about task switching? Rendevous has :> its temporal aspects, how do you abstract them away? : : I wouldn't. But it is perfectly possible. In C, which has no tasks, an : entry is replaced by a procedure with an additional parameter TimeOut. So adding a TimeOut parameter is an abstraction of a task entry? : Basically I am unable to see any crucial difference between a data base : engine or embedded controller or JVM. Tell me : : 1. Why Ada cannot be targeted there? Who said so? : 2. Why Ada will be less efficient than SQL? Again, Ada /= SQL, see above. Efficiency here is not necessarily a matter of PLs, but of how an operation can be performed regardless of implementation language at either end of the communication. If the program is blocking resources due to generalized expectations about cursors in some nice DB abstraction there is an efficiency problem. : They will invest in other things. Nowadays, nobody invests in chopping : firewood... Well, some do. (I've had to find firewood and briquettes for some 10 years, so I know. And those who have nice firesides in their homes need it, too.) :>:> What has Ada versus Assembly got to do with resource consumption of :>:> communicating programs (Ada program <-> database program?) :>: :>: It is because you present performance as an argument for using a low level :>: mechanism. :> :> I present resource consumption as a real time constraint :> on the structure of data and on techniques of data access. : : But you do not explain why SELECT * is less resource consuming than : anything else. I was trying to explain that a program (being written in Ada or not) needs to be able to release database resources when proper working of the database software requires that this be done. If an abstraction doesn't offer this possibility, then I cannot use the abstraction. Since I am in no position to discuss the difficult task of designing a modern database system, I'll leave this to others now. :-) -- Georg ^ permalink raw reply [flat|nested] 96+ messages in thread
* Re: Windows Ada database support. 2004-11-30 21:10 ` Georg Bauhaus @ 2004-12-01 9:11 ` Dmitry A. Kazakov 0 siblings, 0 replies; 96+ messages in thread From: Dmitry A. Kazakov @ 2004-12-01 9:11 UTC (permalink / raw) On Tue, 30 Nov 2004 21:10:11 +0000 (UTC), Georg Bauhaus wrote: > Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> wrote: >: On Tue, 30 Nov 2004 16:07:06 +0000 (UTC), Georg Bauhaus wrote: >: >:> Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> wrote: >:>: On Mon, 29 Nov 2004 22:05:50 +0000 (UTC), Georg Bauhaus wrote: >:>:>:> See also Frank Piron's comment about implicit cursors in >:>:>:> PL/SQL. >:>:> >:>:> Wrong abstractions in PL/SQL too? >:>: >:>: Is in your opinion PL/SQL better than Ada? >:> >:> PL/SQL has a specific purpose, and a rich set of facilities for handling >:> relations. >: >: 1. Why relations should be handled? >: 2. Why Ada cannot handle them? > > One reaon that Ada, as is, cannot handle the same set of problems > as PL/SQL with the same ease is, I think, that PL/SQL is a programming > language with built in support for database operations. You'd have to > define at least everything that has been defined (or not) for PL/SQL, > taking into account all Ada features and requirements. Sorry, but I cannot follow you. Is it about handling relations? From your previous posts I understood that in your view "database operations" = "operations on relations". If true => the question 2, if false => 1. >:> I don't see why anyone using an Oracle DB would want to write >:> stored procedures in Ada? >: >: Fair enough. Compare: "I don't see why anybody using C would want to switch >: to Ada". Indeed, they don't. > > Some do switch from C to Ada, because Ada solves a problem. > If the task at hand is to write a conditionally triggered > procedure that processes a value before it is inserted into > a table, and hides this fact away from a client, that's fairly > easy in PL/SQL. Writing triggered procedure is not an objective, it is a solution. > It's just not there in Ada, AFAIKT. > What is your estimate of the effort it takes to merge this > into Ada packages at a nice level of abstraction? For comparison, > have a look at APQ, then at GNADE. I do not see it as necessary for Ada.Databases. At some remote stage the question: "how can I write and deploy a remote agent in Ada" may arise, but in a more wide context of distributed systems support. From Ada.Databases perspective, triggers, stored procedures etc are just gears to implement abstract data base interface, whatever it will be. If your point is that Ada's ADT is presently unsuitable for any good support for agents, then I definitely agree. This is the main reason, why triggered procedures *cannot* be exposed in the abstract interface. > Have a look at Microsoft's WinFS plans. Consider how long it takes > for the biggest and richest software company to come up with something > working. Huh, what about Windows (known to some as MS-DOS), it still does not work! So the problem is elsewhere! (:-)) >: From my experience, there was no single case, when our customer didn't >: ask for an extensible data model [and was told that he/she cannot afford >: it]. Sooner or later they will break the wall. > > Yes, sounds familiar, but first, hitting the wall is not equal to ruin > as the technicians like to think ;-) and second, you'd have to demonstrate > that an extended data model can be realized by just extending types. Come on. When I keep on proposing for Ada a type model richer than just extension, everybody tells that nobody would need that. Now you wish to convince me that DB application area is wider than one of the most universal programming language? (:-)) > It might be necessary to add or change change types and add or change > relations between types etc. Between objects, you mean? Because the only type relation the whole OO is based on is just base<->derived. I do not believe, that DB would need anything more advanced than that, really. >:>: The same way we program concurrent distributed applications in Ada! >:> >:> And you know what people say about task switching? Rendevous has >:> its temporal aspects, how do you abstract them away? >: >: I wouldn't. But it is perfectly possible. In C, which has no tasks, an >: entry is replaced by a procedure with an additional parameter TimeOut. > > So adding a TimeOut parameter is an abstraction of a task entry? It is an abstraction of a timed entry call [we are talking about interfaces.] >: Basically I am unable to see any crucial difference between a data base >: engine or embedded controller or JVM. Tell me >: >: 1. Why Ada cannot be targeted there? > > Who said so? > >: 2. Why Ada will be less efficient than SQL? > > Again, Ada /= SQL, see above. Efficiency here is not necessarily > a matter of PLs, but of how an operation can be performed regardless > of implementation language at either end of the communication. Should it mean that the language is irrelevant here? What is the point then? > If the program is blocking resources due to generalized expectations > about cursors in some nice DB abstraction there is an efficiency > problem. Again, the above is not about concrete languages Ada vs. SQL. It is rather about if either Ada or SQL may define some "nice DB abstraction", which won't cause efficiency problems. Surely any abstraction may cause them, yet people are doomed to use them. After all SQL itself is also that sort of abstraction. > I was trying to explain that a program (being written in Ada or not) > needs to be able to release database resources when proper working of > the database software requires that this be done. Fully agree. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 96+ messages in thread
* Re: Windows Ada database support. 2004-11-26 9:15 ` Dmitry A. Kazakov 2004-11-26 18:36 ` David Botton 2004-11-29 1:28 ` Georg Bauhaus @ 2004-11-29 12:56 ` Marius Amado Alves 2004-11-29 13:26 ` Dmitry A. Kazakov 2004-11-29 15:02 ` Frank Piron 2004-12-06 14:48 ` Warren W. Gay VE3WWG 4 siblings, 1 reply; 96+ messages in thread From: Marius Amado Alves @ 2004-11-29 12:56 UTC (permalink / raw) To: comp.lang.ada Dmitry A. Kazakov wrote: > .. I would like > to see a high level Ada.Database[.Relational?] package ... There was a brief Ada Commentary on this early this year http://www.ada-auth.org/cgi-bin/cvsweb.cgi/AIs/AC-00097.TXT which has overflowed to comp.lang.ada eventually as thread "Yet another XML and Ada issue" ^ permalink raw reply [flat|nested] 96+ messages in thread
* Re: Windows Ada database support. 2004-11-29 12:56 ` Marius Amado Alves @ 2004-11-29 13:26 ` Dmitry A. Kazakov 0 siblings, 0 replies; 96+ messages in thread From: Dmitry A. Kazakov @ 2004-11-29 13:26 UTC (permalink / raw) On Mon, 29 Nov 2004 12:56:12 +0000, Marius Amado Alves wrote: > Dmitry A. Kazakov wrote: >> .. I would like >> to see a high level Ada.Database[.Relational?] package ... > > There was a brief Ada Commentary on this early this year > > http://www.ada-auth.org/cgi-bin/cvsweb.cgi/AIs/AC-00097.TXT > > which has overflowed to comp.lang.ada eventually as thread "Yet another > XML and Ada issue" Yes, and should be by "Annex E: Distributed Systems" instead... -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 96+ messages in thread
* Re: Windows Ada database support. 2004-11-26 9:15 ` Dmitry A. Kazakov ` (2 preceding siblings ...) 2004-11-29 12:56 ` Marius Amado Alves @ 2004-11-29 15:02 ` Frank Piron 2004-11-29 15:58 ` Marius Amado Alves 2004-11-29 18:16 ` Dmitry A. Kazakov 2004-12-06 14:48 ` Warren W. Gay VE3WWG 4 siblings, 2 replies; 96+ messages in thread From: Frank Piron @ 2004-11-29 15:02 UTC (permalink / raw) Fri, 26 Nov 2004 10:15:06 +0100 Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> wrote: > And more importantly why that crappy SQL over and over again? I would > like > to see a high level Ada.Database[.Relational?] package totally > independent > on what happens beneath. > But what language for querying and manipulating data would you suggest? IMO it should - be declarative - boolean closed - allow restricted quantification Some LQL (Logical query language based on Predicate Calculus) would be nice. Example: (Database for Genealogical data) Base Predicates(Tables): Person(x,s), Parent(x,y) |(s = sex) Show all Fathers: LQL: Father(x):=E(y)[Person(x,s) and s='MALE' and Parent(x,y) ] SQL: select Person.x from Person, Parent where Person.s='MALE' and Person.x = Parent.x (inner join for the E-Quantifier) Similar to Prolog. Other implementations would use only persistent types and their methods in a distributed environment (like Cachᅵ). -- Frank Piron, defrankatkonaddot (leftrotate two) ^ permalink raw reply [flat|nested] 96+ messages in thread
* Re: Windows Ada database support. 2004-11-29 15:02 ` Frank Piron @ 2004-11-29 15:58 ` Marius Amado Alves 2004-11-29 18:16 ` Dmitry A. Kazakov 1 sibling, 0 replies; 96+ messages in thread From: Marius Amado Alves @ 2004-11-29 15:58 UTC (permalink / raw) To: comp.lang.ada Frank Piron wrote: > Base Predicates(Tables): Person(x,s), Parent(x,y) |(s = sex) > Show all Fathers: > > LQL: > Father(x):=E(y)[Person(x,s) and > s='MALE' and > Parent(x,y) > ] > > SQL: > select Person.x > from Person, Parent > where Person.s='MALE' and > Person.x = Parent.x (inner join for the E-Quantifier) In Mneson you would represent the parent, or child, relation simply as an attribute of a person, and then write something like targets (Person) ^ having (s, MALE) ^ having_any (child) For robust validation of query languages I found two data sets: - the ones included in XQuery published by w3c.org - the benchmarks published by tpc.org Maybe there are others; I'd like to know. ^ permalink raw reply [flat|nested] 96+ messages in thread
* Re: Windows Ada database support. 2004-11-29 15:02 ` Frank Piron 2004-11-29 15:58 ` Marius Amado Alves @ 2004-11-29 18:16 ` Dmitry A. Kazakov 2004-11-30 7:14 ` Frank Piron 1 sibling, 1 reply; 96+ messages in thread From: Dmitry A. Kazakov @ 2004-11-29 18:16 UTC (permalink / raw) On Mon, 29 Nov 2004 16:02:44 +0100, Frank Piron wrote: > Fri, 26 Nov 2004 10:15:06 +0100 Dmitry A. Kazakov > <mailbox@dmitry-kazakov.de> wrote: > >> And more importantly why that crappy SQL over and over again? I would >> like >> to see a high level Ada.Database[.Relational?] package totally >> independent >> on what happens beneath. >> > But what language for querying and manipulating data would you > suggest? > IMO it should > > - be declarative > - boolean closed > - allow restricted quantification Yes. > Some LQL (Logical query language based on Predicate Calculus) > would be nice. > Example: (Database for Genealogical data) > > Base Predicates(Tables): Person(x,s), Parent(x,y) |(s = sex) > Show all Fathers: > > LQL: > Father(x):=E(y)[Person(x,s) and > s='MALE' and > Parent(x,y) > ] > > SQL: > select Person.x > from Person, Parent > where Person.s='MALE' and > Person.x = Parent.x (inner join for the E-Quantifier) > > Similar to Prolog. > > Other implementations would use only persistent types and their methods > in a distributed environment (like Cach�). Ideally it should be a direct use of Ada's ADT. It should be true ADT, not just a data representation, also stored procedures (are they Turing complete, BTW? (:-)) I don't know how realistic it will be in 2010, but sooner or later a new generation of OO data bases will support ADT. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 96+ messages in thread
* Re: Windows Ada database support. 2004-11-29 18:16 ` Dmitry A. Kazakov @ 2004-11-30 7:14 ` Frank Piron 0 siblings, 0 replies; 96+ messages in thread From: Frank Piron @ 2004-11-30 7:14 UTC (permalink / raw) Mon, 29 Nov 2004 19:16:18 +0100 Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> wrote: > Ideally it should be a direct use of Ada's ADT. It should be true ADT, > not > just a data representation, also stored procedures (are they Turing > complete, BTW? (:-)) In Oracle PL/SQL there are explicit restrictions on the size of variables. But you may simulate a half-side Turing tape easily with a suitable table (persistent or PL/SQL) and thus PL/SQL-Stored Procedures are Turing complete with the usual assumption that tables are as large as you want. > I don't know how realistic it will be in 2010, but > sooner or later a new generation of OO data bases will support ADT. > -- Frank Piron, defrankatkonaddot (leftrotate two) ^ permalink raw reply [flat|nested] 96+ messages in thread
* Re: Windows Ada database support. 2004-11-26 9:15 ` Dmitry A. Kazakov ` (3 preceding siblings ...) 2004-11-29 15:02 ` Frank Piron @ 2004-12-06 14:48 ` Warren W. Gay VE3WWG 2004-12-06 16:29 ` Dmitry A. Kazakov 4 siblings, 1 reply; 96+ messages in thread From: Warren W. Gay VE3WWG @ 2004-12-06 14:48 UTC (permalink / raw) Dmitry A. Kazakov wrote: > On Thu, 25 Nov 2004 12:50:07 -0500, Warren W. Gay VE3WWG wrote: ... >>APQ Plug: >> >>The good news is that you do have "choice". I have been dragging my feet >>in getting the latest version of APQ out, but the published version >>supports PostgreSQL and MySQL in OO form. The version to be released >>(pending install scripts), supports PostgreSQL, MySQL and SYBASE >>(I have been distracted with another fun and absorbing project lately). >> >>The OO level support is database neutral in most places, so that you >>can write portable database code. Differences do exist however, but >>this can be accomodated in the code if the programmer does a little >>planning (avoid certain database features). >> >>Good for Linux/Windows/*NIX, local or remote databases. The same >>database code should compile to all platforms. >> >>And... no *ODBC required. Totally native, no preprocessing of source >>code. Also includes comprehensive manual with examples. > > What about support for MS-Access, MS-SQL server, Oracle? When I get the time to put APQ up on Source Forge, then these shouldn't be hard to add to APQ, but volunteers. > And more importantly why that crappy SQL over and over again? I would like > to see a high level Ada.Database[.Relational?] package totally independent > on what happens beneath. On the relational side, it is currently near impossible to be "totally independent on what happens beneath". However, I believe APQ comes close (this was one of its design goals). I don't really understand your criticism "why that crappy SQL over and over again?". I do recognize that SQL as implemented by the various vendors could use more uniformity, and even then is less than perfect. However, most people find that the current crop of relational databases are far superior to the old days of updating files without atomic transactions and referencial integrity. So I would tend to agree with the general feeling that the SQL products today, are "good enough". Keep in mind that you cannot use a relational database without using SQL (at least no examples come to my mind). So if you don't like SQL, then you have to either forget relational, or build a higher level "protocol" that compiles/translates to SQL underneath. -- Warren W. Gay VE3WWG http://home.cogeco.ca/~ve3wwg ^ permalink raw reply [flat|nested] 96+ messages in thread
* Re: Windows Ada database support. 2004-12-06 14:48 ` Warren W. Gay VE3WWG @ 2004-12-06 16:29 ` Dmitry A. Kazakov 2004-12-06 17:52 ` Warren W. Gay VE3WWG 0 siblings, 1 reply; 96+ messages in thread From: Dmitry A. Kazakov @ 2004-12-06 16:29 UTC (permalink / raw) On Mon, 06 Dec 2004 09:48:09 -0500, Warren W. Gay VE3WWG wrote: > Dmitry A. Kazakov wrote: >> On Thu, 25 Nov 2004 12:50:07 -0500, Warren W. Gay VE3WWG wrote: > ... >>>APQ Plug: >>> >>>The good news is that you do have "choice". I have been dragging my feet >>>in getting the latest version of APQ out, but the published version >>>supports PostgreSQL and MySQL in OO form. The version to be released >>>(pending install scripts), supports PostgreSQL, MySQL and SYBASE >>>(I have been distracted with another fun and absorbing project lately). >>> >>>The OO level support is database neutral in most places, so that you >>>can write portable database code. Differences do exist however, but >>>this can be accomodated in the code if the programmer does a little >>>planning (avoid certain database features). >>> >>>Good for Linux/Windows/*NIX, local or remote databases. The same >>>database code should compile to all platforms. >>> >>>And... no *ODBC required. Totally native, no preprocessing of source >>>code. Also includes comprehensive manual with examples. >> >> What about support for MS-Access, MS-SQL server, Oracle? > > When I get the time to put APQ up on Source Forge, then these > shouldn't be hard to add to APQ, but volunteers. > >> And more importantly why that crappy SQL over and over again? I would like >> to see a high level Ada.Database[.Relational?] package totally independent >> on what happens beneath. > > On the relational side, it is currently near impossible to be > "totally independent on what happens beneath". However, I believe > APQ comes close (this was one of its design goals). > > I don't really understand your criticism "why that crappy SQL over > and over again?". I do recognize that SQL as implemented by the > various vendors could use more uniformity, and even then is less > than perfect. However, most people find that the current crop > of relational databases are far superior to the old days of > updating files without atomic transactions and referencial > integrity. So I would tend to agree with the general feeling > that the SQL products today, are "good enough". > > Keep in mind that you cannot use a relational database without > using SQL (at least no examples come to my mind). So if you > don't like SQL, then you have to either forget relational, > or build a higher level "protocol" that compiles/translates > to SQL underneath. Yes, this is exactly what I meant. In short, Ada bindings should have Create_Table (...) instead of Execute ("CREATE TABLE ..."). Let SQL be perfect, firmly standardized, validated etc. Even so to have a language within another language is a bad idea. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 96+ messages in thread
* Re: Windows Ada database support. 2004-12-06 16:29 ` Dmitry A. Kazakov @ 2004-12-06 17:52 ` Warren W. Gay VE3WWG 2004-12-06 19:44 ` Georg Bauhaus 2004-12-06 20:49 ` Dmitry A. Kazakov 0 siblings, 2 replies; 96+ messages in thread From: Warren W. Gay VE3WWG @ 2004-12-06 17:52 UTC (permalink / raw) Dmitry A. Kazakov wrote: > On Mon, 06 Dec 2004 09:48:09 -0500, Warren W. Gay VE3WWG wrote: ... >>Keep in mind that you cannot use a relational database without >>using SQL (at least no examples come to my mind). So if you >>don't like SQL, then you have to either forget relational, >>or build a higher level "protocol" that compiles/translates >>to SQL underneath. > > Yes, this is exactly what I meant. In short, Ada bindings should have > Create_Table (...) instead of Execute ("CREATE TABLE ..."). Let SQL be > perfect, firmly standardized, validated etc. Even so to have a language > within another language is a bad idea. This problem is virtually unsolvable with the existing products that people out there use. Some database products (PostgreSQL for example) promote the use of Object IDs (basically Row IDs). Still others don't support the concept at all (MySQL). A grey area exists in a 3rd area (like Informix), which allows you to use them at your own peril (Row IDs are unique, if you keep within certain database design restrictions). Related to this same issue is how to identify rows that lack a natural primary key. Some databases support an identity type for the purpose (Sybase), while others use sequences. Still others like MySQL use some weird idea of an auto increment integer field (I am too lazy to look up the specifics for this, but this is documented in the APQ manual). Here's another good one: Some databases allow you to declare a VARCHAR(256). Others are restricted to VARCHAR(255), and you must switch to a different type (TEXT I think), if you need longer fields. Some support boolean types, and others do not. Some support arrays, others do not. If they both support arrays, they are guaranteed to work with different rules and syntax. There seems to be virtually no agreement on how blobs are handled and managed, between the different products. The list of incompatibilities and differences are many more. For example, there are differences in the way the client libraries work (ability to fetch one row at a time, randomly or not (PostgreSQL), must fetch them all into client memory for random access, or use one-at-a-time sequential access (MySQL), etc.) The challenges for a "unified Ada access" layer are so numerous, that I consider it unachievable. I took a stab at providing a "portable" binding in APQ, but had to make various compromises along the way (these are documented in the manual). I support the concept, but unless dramatic changes in product lines emerge, you cannot arrive at the "I don't want to know what is beneath" solution. APQ takes a stab at this problem, and does reduce or eliminate many of the differences. Truly portable code will still need to test which database product is being used, and adjust the SQL to suit in some cases. There is just no way to avoid it. -- Warren W. Gay VE3WWG http://home.cogeco.ca/~ve3wwg ^ permalink raw reply [flat|nested] 96+ messages in thread
* Re: Windows Ada database support. 2004-12-06 17:52 ` Warren W. Gay VE3WWG @ 2004-12-06 19:44 ` Georg Bauhaus 2004-12-06 20:49 ` Dmitry A. Kazakov 1 sibling, 0 replies; 96+ messages in thread From: Georg Bauhaus @ 2004-12-06 19:44 UTC (permalink / raw) Warren W. Gay VE3WWG <ve3wwg@nospam.cogeco.ca> wrote: : Still others like MySQL use some weird idea of an auto : increment integer field (I am too lazy to look up the : specifics for this, but this is documented in the APQ : manual). In fact the MySQL auto increment ids are no more than a convenience, you can actually overwrite the keys at will, with interesting side effects. (A customer has asked us to change internal auto inc keys, because they had told another company the internal ids and had assumed auto inc ids would be the same on different computers running different DB instances at differnt times... At another installation site, the DB is Oracle. They have been warned...) : Here's another good one: Some databases allow you to declare : a VARCHAR(256). Others are restricted to VARCHAR(255), and you : must switch to a different type (TEXT I think), if you need : longer fields. In addition, depending on database version and driver, Oracle might give you quite a variety of types for each of text fields, floats, and others. -- Georg ^ permalink raw reply [flat|nested] 96+ messages in thread
* Re: Windows Ada database support. 2004-12-06 17:52 ` Warren W. Gay VE3WWG 2004-12-06 19:44 ` Georg Bauhaus @ 2004-12-06 20:49 ` Dmitry A. Kazakov 2004-12-07 5:16 ` Warren W. Gay VE3WWG 2004-12-07 15:49 ` Georg Bauhaus 1 sibling, 2 replies; 96+ messages in thread From: Dmitry A. Kazakov @ 2004-12-06 20:49 UTC (permalink / raw) On Mon, 06 Dec 2004 12:52:40 -0500, Warren W. Gay VE3WWG wrote: > Dmitry A. Kazakov wrote: >> On Mon, 06 Dec 2004 09:48:09 -0500, Warren W. Gay VE3WWG wrote: > ... >>>Keep in mind that you cannot use a relational database without >>>using SQL (at least no examples come to my mind). So if you >>>don't like SQL, then you have to either forget relational, >>>or build a higher level "protocol" that compiles/translates >>>to SQL underneath. >> >> Yes, this is exactly what I meant. In short, Ada bindings should have >> Create_Table (...) instead of Execute ("CREATE TABLE ..."). Let SQL be >> perfect, firmly standardized, validated etc. Even so to have a language >> within another language is a bad idea. > > This problem is virtually unsolvable with the existing products (SQL products) > that people out there use. Some database products (PostgreSQL > for example) promote the use of Object IDs (basically Row IDs). > Still others don't support the concept at all (MySQL). A grey > area exists in a 3rd area (like Informix), which allows you to > use them at your own peril (Row IDs are unique, if you keep > within certain database design restrictions). I think that this is a shortcoming of the very concept of a relational view. Relation is not an array. Period. So IF it should be Ada.Database.Relational, then there will be no such think as row ID. [ But it is a good sign. Database vendors start to conceive shortcomings of the existing models. This will erode SQL dominance. ] Also we should distinguish two cases: A. Some Ada application stores its data in a database. The way the data are organized there is free. B. Accessing existing (but unknown at design time) data base. The data structure is fixed and the application must adapt to it. A is much easier than B. Not everybody needs B. Further B is often bound to some concrete data base, in which case data base specific bindings make much sense. So we could ignore B for a while. At least until it will be clear how to provide at least A. > Related to this same issue is how to identify rows that lack > a natural primary key. Some databases support an identity > type for the purpose (Sybase), while others use sequences. > Still others like MySQL use some weird idea of an auto > increment integer field (I am too lazy to look up the > specifics for this, but this is documented in the APQ > manual). > > Here's another good one: Some databases allow you to declare > a VARCHAR(256). Others are restricted to VARCHAR(255), and you > must switch to a different type (TEXT I think), if you need > longer fields. > > Some support boolean types, and others do not. Some support > arrays, others do not. If they both support arrays, they > are guaranteed to work with different rules and syntax. > > There seems to be virtually no agreement on how blobs are > handled and managed, between the different products. This is the case B. I think that it could still be possible to solve it in an OO way. All database types should be derived from one base. Factory can be used to create values "like in the column". Differences between VARCHAR, TEXT, LONGCHAR etc are uninteresting for the application. It should have some string type derived from the base. That may have constrained subtypes or derived types according to the database constraints. In general I do not think that primitive data types are the greatest problem. The problem is that the semantics of "what and how" slips away. It is too low level. > The list of incompatibilities and differences are many > more. For example, there are differences in the way the > client libraries work (ability to fetch one row at a time, > randomly or not (PostgreSQL), must fetch them all into > client memory for random access, or use one-at-a-time > sequential access (MySQL), etc.) > > The challenges for a "unified Ada access" layer are so > numerous, that I consider it unachievable. I took a stab > at providing a "portable" binding in APQ, but had to > make various compromises along the way (these are documented > in the manual). I think that APQ could become an alternative to ODBC. ODBC tries to swallow documents and spreadsheets (like Excel), things that are too far from a "normal" data base. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 96+ messages in thread
* Re: Windows Ada database support. 2004-12-06 20:49 ` Dmitry A. Kazakov @ 2004-12-07 5:16 ` Warren W. Gay VE3WWG 2004-12-07 10:29 ` Dmitry A. Kazakov 2004-12-07 15:49 ` Georg Bauhaus 1 sibling, 1 reply; 96+ messages in thread From: Warren W. Gay VE3WWG @ 2004-12-07 5:16 UTC (permalink / raw) Dmitry A. Kazakov wrote: > On Mon, 06 Dec 2004 12:52:40 -0500, Warren W. Gay VE3WWG wrote: >>that people out there use. Some database products (PostgreSQL >>for example) promote the use of Object IDs (basically Row IDs). >>Still others don't support the concept at all (MySQL). A grey >>area exists in a 3rd area (like Informix), which allows you to >>use them at your own peril (Row IDs are unique, if you keep >>within certain database design restrictions). > > I think that this is a shortcoming of the very concept of a relational > view. Relation is not an array. Period. So IF it should be > Ada.Database.Relational, then there will be no such think as row ID. [ But > it is a good sign. Database vendors start to conceive shortcomings of the > existing models. This will erode SQL dominance. ] Well, database theory experts rage wars over issues like this in other newsgroups. All I would personally like to see on a practical level (theory aside) is AGREEMENT and CONSISTENCY. I could live with or without row IDs, as long as all vendors did so uniformly. As soon as one supports the idea, then any Ada package that binds to it must provide access to it (existing database schemas are not going to change to suit the Ada package writer). OTOH, I have no problem WITH row ids, as long as they are unique. The whole row ID problem AFAIK, only really started to be a problem when vendors started permitting other disk configurations that caused the row ids to be "parallel" in some way, and thus non-unique. > Also we should distinguish two cases: > > A. Some Ada application stores its data in a database. The way the data are > organized there is free. Its not clear to me what you mean by "free" here. > B. Accessing existing (but unknown at design time) data base. The data > structure is fixed and the application must adapt to it. I think I know the two points you are raising, but it isn't clear which is A or B. > A is much easier than B. Not everybody needs B. Further B is often bound to > some concrete data base, in which case data base specific bindings make > much sense. So we could ignore B for a while. At least until it will be > clear how to provide at least A. If in one case you mean a package capable of being used in a GUI tool, where it can connect to the database and discover tables, keys, indexes, views, triggers and the like, and allow dynamic operations without any foreknowledge, then agreed, this is much more difficult. This is even more of a nightmare approach wise, because the standard(s) never addressed this need - hence every vendor implements this functionality they way they see fit. While the above is import (for tools), application needs are usually much simpler. Written to do fixed operations, on a fixed set of tables, views and stored procedures. But as I've pointed out, even this simpler case is complex in a multi-vendor world. >>Related to this same issue is how to identify rows that lack >>a natural primary key. Some databases support an identity >>type for the purpose (Sybase), while others use sequences. >>Still others like MySQL use some weird idea of an auto >>increment integer field (I am too lazy to look up the >>specifics for this, but this is documented in the APQ >>manual). >> >>Here's another good one: Some databases allow you to declare >>a VARCHAR(256). Others are restricted to VARCHAR(255), and you >>must switch to a different type (TEXT I think), if you need >>longer fields. >> >>Some support boolean types, and others do not. Some support >>arrays, others do not. If they both support arrays, they >>are guaranteed to work with different rules and syntax. >> >>There seems to be virtually no agreement on how blobs are >>handled and managed, between the different products. > > This is the case B. Blobs? >I think that it could still be possible to solve it in > an OO way. I beg to differ on this one, though I've not tried very hard on this one ;-) Consider some of the challenges: 1) PostgreSQL uses an API that opens/creates etc. and returns an OID. 2) PostgreSQL blobs are referenced by saving a OID in a column of a row. 3) ALL PostgreSQL blob operations must occur within the confines of a transaction (otherwise the operation fails!) 4) MySQL (IIRC), wants you to put the entire blob into a row. 5) MySQL, IIRC, wants you to perform the blob I/O in one operation and IIRC, doesn't care about transactions (optional). 6) PostgreSQL blobs can be operated on like files, with seeks, partial writes, reads etc. I seem to recall there were more problems, but when I started with this list, I decided to leave it for a rainy day!!! ;-) > All database types should be derived from one base. Factory can > be used to create values "like in the column". Differences between VARCHAR, > TEXT, LONGCHAR etc are uninteresting for the application. You might expect so, but the Boolean case and Dates have created a lot of problem. Since you have to work with SQL, how do you satisfy databases that want 0 and 1 for Booleans (or bit?), and the more nomal ones that that True and False? I sheltered the application to some degree from this in APQ, but allowing the fields to be encoded for you (APQ knows in the MySQL case it wants 0 and 1 - I think it was MySQL). But this problem still pokes out in places like hardcoded WHERE clauses : ... WHERE MARRIED = False and ... or WHERE MARRIED = 0 and ... So if MARRIED is BOOLEAN, I think you have to test if you are using MySQL (I think it was them), and then use the 0 and 1 instead (or use APQ to encode a hardcoded False!) Dates, Timestamps and timezones get even more interesting. Versions of databases add to the problems! MySQL in one version formats the dates differently than later versions -- ugh! > In general I do not think that primitive data types are the greatest > problem. The problem is that the semantics of "what and how" slips away. It > is too low level. I think you would be surprised! Just sticking to "normal" primitive data types in APQ, has had me see enough horrors ;-) >>The list of incompatibilities and differences are many >>more. For example, there are differences in the way the >>client libraries work (ability to fetch one row at a time, >>randomly or not (PostgreSQL), must fetch them all into >>client memory for random access, or use one-at-a-time >>sequential access (MySQL), etc.) >> >>The challenges for a "unified Ada access" layer are so >>numerous, that I consider it unachievable. I took a stab >>at providing a "portable" binding in APQ, but had to >>make various compromises along the way (these are documented >>in the manual). > > I think that APQ could become an alternative to ODBC. ODBC tries to swallow > documents and spreadsheets (like Excel), things that are too far from a > "normal" data base. Well, in fairness to ODBC, some sort of generalized interface was called for, and it was "a solution" of sorts. But I never felt it was meant to be used by application programmers. IMHO, any API that has application programmers coding a whole whack of complex API calls to just do a select and return a row (for example), is not "the solution". Application programmers want to focus on the application problem - not API details (most mediochre programmers can't get it right anyway). Once coded, it becomes so complex, that no one wants to make major changes to it. Then comes the patchwork! Many people feel that code generators are the answer. I disagree there also. That is a one-time fix. Eventually, someone has to go back and change it. At this point it is unreadable and near unmaintainable. APQ tries to make it simple for the application programmer. I would much rather be thinking in SQL and Ada terms, than trying trying to remember API calls. APQ's API tries to be self intuitive, and time will tell if it is or not. This has been an interesting diversion ;-) -- Warren W. Gay VE3WWG http://home.cogeco.ca/~ve3wwg ^ permalink raw reply [flat|nested] 96+ messages in thread
* Re: Windows Ada database support. 2004-12-07 5:16 ` Warren W. Gay VE3WWG @ 2004-12-07 10:29 ` Dmitry A. Kazakov 0 siblings, 0 replies; 96+ messages in thread From: Dmitry A. Kazakov @ 2004-12-07 10:29 UTC (permalink / raw) On Tue, 07 Dec 2004 00:16:21 -0500, Warren W. Gay VE3WWG wrote: > Dmitry A. Kazakov wrote: >> On Mon, 06 Dec 2004 12:52:40 -0500, Warren W. Gay VE3WWG wrote: >> Also we should distinguish two cases: >> >> A. Some Ada application stores its data in a database. The way the data are >> organized there is free. > > Its not clear to me what you mean by "free" here. It means that bindings (the driver) are free to choose the most suitable implementation. The application describes what it needs and the driver implements it using available gears. It is not guaranteed that the schemata, types etc will be same for other data bases or on other platforms. >> B. Accessing existing (but unknown at design time) data base. The data >> structure is fixed and the application must adapt to it. > > I think I know the two points you are raising, but it isn't > clear which is A or B. > >> A is much easier than B. Not everybody needs B. Further B is often bound to >> some concrete data base, in which case data base specific bindings make >> much sense. So we could ignore B for a while. At least until it will be >> clear how to provide at least A. > > If in one case you mean a package capable of being used in a GUI > tool, where it can connect to the database and discover tables, > keys, indexes, views, triggers and the like, and allow dynamic > operations without any foreknowledge, then agreed, this is much > more difficult. This is even more of a nightmare approach wise, > because the standard(s) never addressed this need - hence every > vendor implements this functionality they way they see fit. Yes, this would be B. > While the above is import (for tools), application needs are usually > much simpler. Written to do fixed operations, on a fixed set of > tables, views and stored procedures. But as I've pointed out, > even this simpler case is complex in a multi-vendor world. I think that static vs. dynamic difference is rather marginal. Essential is who must adapt to whom, i.e. A vs. B. >>>Related to this same issue is how to identify rows that lack >>>a natural primary key. Some databases support an identity >>>type for the purpose (Sybase), while others use sequences. >>>Still others like MySQL use some weird idea of an auto >>>increment integer field (I am too lazy to look up the >>>specifics for this, but this is documented in the APQ >>>manual). >>> >>>Here's another good one: Some databases allow you to declare >>>a VARCHAR(256). Others are restricted to VARCHAR(255), and you >>>must switch to a different type (TEXT I think), if you need >>>longer fields. >>> >>>Some support boolean types, and others do not. Some support >>>arrays, others do not. If they both support arrays, they >>>are guaranteed to work with different rules and syntax. >>> >>>There seems to be virtually no agreement on how blobs are >>>handled and managed, between the different products. >> >> This is the case B. > > Blobs? > >>I think that it could still be possible to solve it in >> an OO way. > > I beg to differ on this one, though I've not tried very > hard on this one ;-) Consider some of the challenges: > > 1) PostgreSQL uses an API that opens/creates etc. and returns > an OID. > 2) PostgreSQL blobs are referenced by saving a OID in a column > of a row. > 3) ALL PostgreSQL blob operations must occur within the confines > of a transaction (otherwise the operation fails!) > 4) MySQL (IIRC), wants you to put the entire blob into a > row. > 5) MySQL, IIRC, wants you to perform the blob I/O in one > operation and IIRC, doesn't care about transactions (optional). > 6) PostgreSQL blobs can be operated on like files, with seeks, > partial writes, reads etc. In the case A it is up to the driver what (and if) it would use for some given type. The driver of a database X knows how to deal with large objects. If, say, a Postres driver decides that the type Baz should be stored as a blob, then it should add all necessary bells and whistles transparent to the application. Compare: in 99.9% cases I do not care if and how the Ada compiler creates dopes for my arrays. Also I wouldn't be much surprised if users of the A-bindings will never store giant indigestible objects into a data base. It is not the Ada's way, after all. What is stored as blobs, usually has some finer internal structure, which appears too complex to map it into data base things. Provided that this need to be made manually. Being automated via A-bindings it might turn very different. > I seem to recall there were more problems, but when I started > with this list, I decided to leave it for a rainy day!!! ;-) > >> All database types should be derived from one base. Factory can >> be used to create values "like in the column". Differences between VARCHAR, >> TEXT, LONGCHAR etc are uninteresting for the application. > > You might expect so, but the Boolean case and Dates have created > a lot of problem. Since you have to work with SQL, how do you > satisfy databases that want 0 and 1 for Booleans (or bit?), > and the more nomal ones that that True and False? That would be the case B! For A, the application will just use say Ada.Database.Relational.Boolean, which the driver will translate into the most appropriate type for the data base it supports: SMALLINT, CHAR, BIT, whatsoever available. > I sheltered the application to some degree from this in APQ, > but allowing the fields to be encoded for you (APQ knows > in the MySQL case it wants 0 and 1 - I think it was MySQL). > But this problem still pokes out in places like hardcoded WHERE > clauses : > > ... > WHERE MARRIED = False and ... > > or > > WHERE MARRIED = 0 and ... > > So if MARRIED is BOOLEAN, I think you have to test if you > are using MySQL (I think it was them), and then use the 0 > and 1 instead (or use APQ to encode a hardcoded False!) > > Dates, Timestamps and timezones get even more interesting. > Versions of databases add to the problems! MySQL in one > version formats the dates differently than later versions > -- ugh! This is exactly why I would like to get rid of any traces of SQL in the bindings. The interface should provide an iterator. The iteration filter will be an object describing the filtering condition. That will be translated by the driver into SQL's WHERE ... with all literals selected as required. ODBC does it well for ?-parameters in prepared statements. (SQL is the evil! (:-)) >> In general I do not think that primitive data types are the greatest >> problem. The problem is that the semantics of "what and how" slips away. It >> is too low level. > > I think you would be surprised! Just sticking to "normal" > primitive data types in APQ, has had me see enough horrors ;-) I am not. For example with ODBC, you have to ask the driver what it has today for say GUID. Let it answers: sorry. What would your application do? Emulate GUID using BIGINT, TIMESTAMP? ODBC is just irreparably wrong! >>>The list of incompatibilities and differences are many >>>more. For example, there are differences in the way the >>>client libraries work (ability to fetch one row at a time, >>>randomly or not (PostgreSQL), must fetch them all into >>>client memory for random access, or use one-at-a-time >>>sequential access (MySQL), etc.) >>> >>>The challenges for a "unified Ada access" layer are so >>>numerous, that I consider it unachievable. I took a stab >>>at providing a "portable" binding in APQ, but had to >>>make various compromises along the way (these are documented >>>in the manual). >> >> I think that APQ could become an alternative to ODBC. ODBC tries to swallow >> documents and spreadsheets (like Excel), things that are too far from a >> "normal" data base. > > Well, in fairness to ODBC, some sort of generalized interface > was called for, and it was "a solution" of sorts. But I never > felt it was meant to be used by application programmers. My impression is that ODBC tried to be both A and B, and failed both. > IMHO, > any API that has application programmers coding a whole whack > of complex API calls to just do a select and return a row (for > example), is not "the solution". Application programmers want > to focus on the application problem - not API details (most > mediochre programmers can't get it right anyway). Once coded, > it becomes so complex, that no one wants to make major changes > to it. Then comes the patchwork! Yes > Many people feel that code generators are the answer. I disagree > there also. That is a one-time fix. Eventually, someone has to > go back and change it. At this point it is unreadable and near > unmaintainable. Yes > APQ tries to make it simple for the application programmer. I > would much rather be thinking in SQL and Ada terms, than trying > trying to remember API calls. APQ's API tries to be self > intuitive, and time will tell if it is or not. > > This has been an interesting diversion ;-) Yes! -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 96+ messages in thread
* Re: Windows Ada database support. 2004-12-06 20:49 ` Dmitry A. Kazakov 2004-12-07 5:16 ` Warren W. Gay VE3WWG @ 2004-12-07 15:49 ` Georg Bauhaus 2004-12-07 21:29 ` Dmitry A. Kazakov 1 sibling, 1 reply; 96+ messages in thread From: Georg Bauhaus @ 2004-12-07 15:49 UTC (permalink / raw) Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> wrote: : I think that this is a shortcoming of the very concept of a relational : view. Relation is not an array. Period. Who says that a relation is an array? : Also we should distinguish two cases: : : A. Some Ada application stores its data in a database. The way the data are : organized there is free. : : B. Accessing existing (but unknown at design time) data base. The data : structure is fixed and the application must adapt to it. : : A is much easier than B. Wow. I wonder what kind of trivial or specialized applications you have in mind. General purpose databases, of whatever flavor, are complex beasts, no matter what. A lot has been written about databases, many solutions have been tried, a lot of research is going on. No use ignoring all of it. So far I think you are just repeating the *questions* that have accompanied the huge database efforts. -- Georg ^ permalink raw reply [flat|nested] 96+ messages in thread
* Re: Windows Ada database support. 2004-12-07 15:49 ` Georg Bauhaus @ 2004-12-07 21:29 ` Dmitry A. Kazakov 2004-12-08 2:24 ` Georg Bauhaus 2004-12-10 20:47 ` Simon Wright 0 siblings, 2 replies; 96+ messages in thread From: Dmitry A. Kazakov @ 2004-12-07 21:29 UTC (permalink / raw) On Tue, 7 Dec 2004 15:49:36 +0000 (UTC), Georg Bauhaus wrote: > Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> wrote: > >: I think that this is a shortcoming of the very concept of a relational >: view. Relation is not an array. Period. > > Who says that a relation is an array? Nobody. The problem is that we need arrays, or more generally, ordered containers. This is the way the most people think about tables. They do not think about them in terms of relations. Yes, a relational view is complete and you can express everything in it. But it is too low level. This is why people keep on inventing ways to mark that damned rows. Nothing is wrong with that, but the result is, as Warren has pointed out, utter chaos. >: Also we should distinguish two cases: >: >: A. Some Ada application stores its data in a database. The way the data are >: organized there is free. >: >: B. Accessing existing (but unknown at design time) data base. The data >: structure is fixed and the application must adapt to it. >: >: A is much easier than B. > > Wow. I wonder what kind of trivial or specialized applications you have in > mind. Very trivial. I have data, I need to organize and store them. > General purpose databases, of whatever flavor, are complex beasts, > no matter what. Why an application that need to store data, should care about that? Sorry, I still cannot understand it. Do you care much about ferromagnetism when you write a file onto the hard drive? > A lot has been written about databases, many solutions > have been tried, a lot of research is going on. No use ignoring all of > it. Oh, I welcome research, but yes, I keep on trying to ignore that. (:-)) > So far I think you are just repeating the *questions* that have > accompanied the huge database efforts. Maybe. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 96+ messages in thread
* Re: Windows Ada database support. 2004-12-07 21:29 ` Dmitry A. Kazakov @ 2004-12-08 2:24 ` Georg Bauhaus 2004-12-08 9:05 ` Dmitry A. Kazakov 2004-12-10 20:47 ` Simon Wright 1 sibling, 1 reply; 96+ messages in thread From: Georg Bauhaus @ 2004-12-08 2:24 UTC (permalink / raw) Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> wrote: : On Tue, 7 Dec 2004 15:49:36 +0000 (UTC), Georg Bauhaus wrote: : :> Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> wrote: :> :>: I think that this is a shortcoming of the very concept of a relational :>: view. Relation is not an array. Period. :> :> Who says that a relation is an array? : : Nobody. The problem is that we need arrays, or more generally, ordered : containers. This is the way the most people think about tables. Hm. If at the DB level you ask, SELECT S.key, T.foo, T.bar from S, T WHERE (S.key BETWEEN 100 AND 200) AND T.foo = S.key ORDER BY S.key Then you have in Ada.Container terms, function Floor (Container : Map; Key : Key_Type) return Cursor; function Ceiling (Container : Map; Key : Key_Type) return Cursor; where S.key >= 100 can be made the floor and S.key <= 200 can be made the ceiling. : They do not : think about them in terms of relations. You mean they do not think about the relations between records, for example? Well, yes, but how could this be overcome using another language? A fair amount of referential integrity can be "extracted" from an ER diagram using standard means. If this way of defining tables in a database is not standard, do you think that another standard, Ada, is going to help? : Why an application that need to store data, should care about that? Sorry, : I still cannot understand it. 1/ other applications may (have to) modify your data without notice. 3/ storing data might take time. RDB or not, I need to know this 2/ you might need backups and secure storage. This is provided by good RDBMSs. : Do you care much about ferromagnetism when : you write a file onto the hard drive? I certainly do. In particular when the disks are 5 years old and not part of a well maintained RAID. ;-) -- Georg ^ permalink raw reply [flat|nested] 96+ messages in thread
* Re: Windows Ada database support. 2004-12-08 2:24 ` Georg Bauhaus @ 2004-12-08 9:05 ` Dmitry A. Kazakov 2004-12-08 10:03 ` Ole-Hjalmar Kristensen 0 siblings, 1 reply; 96+ messages in thread From: Dmitry A. Kazakov @ 2004-12-08 9:05 UTC (permalink / raw) On Wed, 8 Dec 2004 02:24:25 +0000 (UTC), Georg Bauhaus wrote: > Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> wrote: >: On Tue, 7 Dec 2004 15:49:36 +0000 (UTC), Georg Bauhaus wrote: >: >:> Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> wrote: >:> >:>: I think that this is a shortcoming of the very concept of a relational >:>: view. Relation is not an array. Period. >:> >:> Who says that a relation is an array? >: >: Nobody. The problem is that we need arrays, or more generally, ordered >: containers. This is the way the most people think about tables. > > Hm. If at the DB level you ask, > > SELECT S.key, T.foo, T.bar from S, T > WHERE (S.key BETWEEN 100 AND 200) > AND T.foo = S.key > ORDER BY S.key This is the source of the problems in my view. What does SELECT in application terms? A developer would like to be two storeys above that. > Then you have in Ada.Container terms, > function Floor (Container : Map; > Key : Key_Type) return Cursor; > > function Ceiling (Container : Map; > Key : Key_Type) return Cursor; > where > S.key >= 100 can be made the floor > and > S.key <= 200 can be made the ceiling. You are thinking in terms of SQL. From this point of view nothing or very little could be done. And after all, GNADE provides embedded SQL for that stuff. >: They do not >: think about them in terms of relations. > > You mean they do not think about the relations between records, > for example? Well, yes, but how could this be overcome using > another language? A fair amount of referential integrity can > be "extracted" from an ER diagram using standard means. If this > way of defining tables in a database is not standard, do you think > that another standard, Ada, is going to help? It should be an Ada standard, not a DB standard. Does Ada influence any hardware standards? >: Why an application that need to store data, should care about that? Sorry, >: I still cannot understand it. > > 1/ other applications may (have to) modify your data without notice. These should either use the same bindings or be conform. That's the requirement of the case A in my classification. When you store a BMP image, you do not expect to be able to read it as JPEG, right? > 3/ storing data might take time. RDB or not, I need to know this If you mean performance, then that's the case with programming in general. User of any feature should know what is cheap and what is expensive. When you pass 2MB object by value, you know what to expect. No difference here. If you mean shared access then the standard should provide mutual exclusion for critical sections. The implementation may use transactions, file locks, whatsoever available to achieve exclusion. It is responsibility of the application to express the exclusion constraints, it is no different from how we do it when we program tasks. > 2/ you might need backups and secure storage. This is provided by > good RDBMSs. Same as above. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 96+ messages in thread
* Re: Windows Ada database support. 2004-12-08 9:05 ` Dmitry A. Kazakov @ 2004-12-08 10:03 ` Ole-Hjalmar Kristensen 2004-12-08 10:56 ` Dmitry A. Kazakov 2004-12-08 15:52 ` Georg Bauhaus 0 siblings, 2 replies; 96+ messages in thread From: Ole-Hjalmar Kristensen @ 2004-12-08 10:03 UTC (permalink / raw) >>>>> "DAK" == Dmitry A Kazakov <mailbox@dmitry-kazakov.de> writes: DAK> On Wed, 8 Dec 2004 02:24:25 +0000 (UTC), Georg Bauhaus wrote: >> Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> wrote: >> : On Tue, 7 Dec 2004 15:49:36 +0000 (UTC), Georg Bauhaus wrote: >> : >> :> Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> wrote: >> :> >> :>: I think that this is a shortcoming of the very concept of a relational >> :>: view. Relation is not an array. Period. >> :> >> :> Who says that a relation is an array? >> : >> : Nobody. The problem is that we need arrays, or more generally, ordered >> : containers. This is the way the most people think about tables. >> >> Hm. If at the DB level you ask, >> >> SELECT S.key, T.foo, T.bar from S, T >> WHERE (S.key BETWEEN 100 AND 200) >> AND T.foo = S.key >> ORDER BY S.key DAK> This is the source of the problems in my view. What does SELECT in DAK> application terms? A developer would like to be two storeys above that. A good question. But isn't the goal of the application programmer precisely to select an implementation of the domain-specific concepts? So the application programmer cannot really be "two storeys above that", he has to choose how to do the mapping to some more general representation, be it DB schema or programming language. An even better question is what do you want to accomplish, in terms of your *problem* domain? It isn't obvious to me that using another interface to the DB (object-oriented, navigational, ER-like, etc) in general will make the mapping from the problem domain any easier. For many application domains, thinking in terms of sets and relations are perfectly fine, and going to an object-oriented / navigational model and effectively doing your own joins isn't going to help you much. You have to implement the relations between your problem-domain objects in some way, and the relational model and the use of normailzation has proven itself to be a very robust and flexible way of doing this, although not necessarily the most efficient. If you have a better model for describing the problem domain in mind, I'm more than willing to listen. Btw., many years ago I worked on a project where the main goal was to develop a rapid prototyping tool for DB applications. The project started because a fellow analyst found out that lots of customers did not really understand the implications of the ER models he created, so he felt the need to rapidly create a set of example applications which could illustrate the possibilities of his ER model. Our approach was to first create the ER model, then to create an "application" or form, we would select some entity as the root. By following the relations from this root entity we could reach other entities, and so on, effectively creating a hierarchical structure from the ER network. The tool also allowed you to select a subset of the attributes for each entity. The DB schema was automatically created from the ER model, and the prototyping tool also generated descriptions of the logic (in terms of interpreted code and SQL) and a graphical user interface for each application. The actual execution of the application was done by an interpreter, in order to give us rapid turnaround time (just seconds to make changes to your application or schema and try it again), but of course you could just as well have created data type definitions and access functions in a compiled language to allow an application writer easy access to the ER model/DB schema through a set of application-specific interfaces. >> Then you have in Ada.Container terms, >> function Floor (Container : Map; >> Key : Key_Type) return Cursor; >> >> function Ceiling (Container : Map; >> Key : Key_Type) return Cursor; >> where >> S.key >= 100 can be made the floor >> and >> S.key <= 200 can be made the ceiling. DAK> You are thinking in terms of SQL. From this point of view nothing or very DAK> little could be done. And after all, GNADE provides embedded SQL for that DAK> stuff. He may just as well be thinking in terms of sets and relations. SQL is just a slightly clumsy way of conveying those thoughts to the DB engine :-) <snip> -- C++: The power, elegance and simplicity of a hand grenade. ^ permalink raw reply [flat|nested] 96+ messages in thread
* Re: Windows Ada database support. 2004-12-08 10:03 ` Ole-Hjalmar Kristensen @ 2004-12-08 10:56 ` Dmitry A. Kazakov 2004-12-08 11:19 ` Marius Amado Alves 2004-12-08 15:58 ` Georg Bauhaus 2004-12-08 15:52 ` Georg Bauhaus 1 sibling, 2 replies; 96+ messages in thread From: Dmitry A. Kazakov @ 2004-12-08 10:56 UTC (permalink / raw) On 08 Dec 2004 11:03:44 +0100, Ole-Hjalmar Kristensen wrote: >>>>>> "DAK" == Dmitry A Kazakov <mailbox@dmitry-kazakov.de> writes: > > DAK> On Wed, 8 Dec 2004 02:24:25 +0000 (UTC), Georg Bauhaus wrote: > >> Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> wrote: > >> : On Tue, 7 Dec 2004 15:49:36 +0000 (UTC), Georg Bauhaus wrote: > >> : > >> :> Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> wrote: > >> :> > >> :>: I think that this is a shortcoming of the very concept of a relational > >> :>: view. Relation is not an array. Period. > >> :> > >> :> Who says that a relation is an array? > >> : > >> : Nobody. The problem is that we need arrays, or more generally, ordered > >> : containers. This is the way the most people think about tables. > >> > >> Hm. If at the DB level you ask, > >> > >> SELECT S.key, T.foo, T.bar from S, T > >> WHERE (S.key BETWEEN 100 AND 200) > >> AND T.foo = S.key > >> ORDER BY S.key > > DAK> This is the source of the problems in my view. What does SELECT in > DAK> application terms? A developer would like to be two storeys above that. > > A good question. But isn't the goal of the application programmer > precisely to select an implementation of the domain-specific concepts? Yes, but from one storey below! (:-)) It is essential not to sink in details. > So the application programmer cannot really be "two storeys above > that", he has to choose how to do the mapping to some more general > representation, be it DB schema or programming language. > An even better question is what do you want to accomplish, in terms of > your *problem* domain? It isn't obvious to me that using another > interface to the DB (object-oriented, navigational, ER-like, etc) in > general will make the mapping from the problem domain any easier. So the point is that SQL is the best thing one can imagine? George's point was, in my interpretation: SQL is an inevitable evil (mostly because of performance requirements), higher abstraction is impossible. Your point seems to be: Higher abstraction isn't even needed because SQL is the ultimate optimum. > For > many application domains, thinking in terms of sets and relations are > perfectly fine, and going to an object-oriented / navigational model > and effectively doing your own joins isn't going to help you much. Again, there are two different questions. I have already formulated them in another post: 1. Why relations should be handled? 2. Why Ada cannot handle them? To dismiss Ada.Database.Relational, we have to answer 1=yes, 2=no, because... Note I do not argue that 1=no. I only suspect that there might be better ways. But let's agree for a moment that 1=*YES*. Then, what about 2? > You > have to implement the relations between your problem-domain objects in > some way, and the relational model and the use of normailzation has > proven itself to be a very robust and flexible way of doing this, > although not necessarily the most efficient. > > If you have a better model for describing the problem domain in mind, > I'm more than willing to listen. OK, you wished that! (:-)) I would like to view it as a distributed system and get rid of the notion of DB altogether. Only persistent objects. No I/O, just memory-mappings. [ Clearly, in any short term perspective it is an utopia. ] > Btw., many years ago I worked on a project where the main goal was to > develop a rapid prototyping tool for DB applications. The project > started because a fellow analyst found out that lots of customers did > not really understand the implications of the ER models he created, so > he felt the need to rapidly create a set of example applications which > could illustrate the possibilities of his ER model. Our approach was > to first create the ER model, then to create an "application" or form, > we would select some entity as the root. By following the relations > from this root entity we could reach other entities, and so on, > effectively creating a hierarchical structure from the ER network. The > tool also allowed you to select a subset of the attributes for each > entity. Nice. > The DB schema was automatically created from the ER model, > and the prototyping tool also generated descriptions of the logic (in > terms of interpreted code and SQL) and a graphical user interface for > each application. The actual execution of the application was done by > an interpreter, in order to give us rapid turnaround time (just > seconds to make changes to your application or schema and try it > again), but of course you could just as well have created data type > definitions and access functions in a compiled language to allow an > application writer easy access to the ER model/DB schema through a set > of application-specific interfaces. Excellent. Why something like that cannot become Ada.Databases? -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 96+ messages in thread
* Re: Windows Ada database support. 2004-12-08 10:56 ` Dmitry A. Kazakov @ 2004-12-08 11:19 ` Marius Amado Alves 2004-12-08 12:51 ` Frank Piron 2004-12-08 13:41 ` Dmitry A. Kazakov 2004-12-08 15:58 ` Georg Bauhaus 1 sibling, 2 replies; 96+ messages in thread From: Marius Amado Alves @ 2004-12-08 11:19 UTC (permalink / raw) To: comp.lang.ada > ... I would like to view it as a distributed system > and get rid of the notion of DB altogether. Only persistent objects. No > I/O, just memory-mappings. [ Clearly, in any short term perspective it is > an utopia. ] (Kasakov) Utopia? There are currently persistent and prevalent object systems for Ada and Java and probably other languages. I recall Prevayler for Java, and at least one persistent system for Ada (isn't that actually by yourself?). The problem is they force an object oriented model which as has been argued does not always fit the application domain well. ^ permalink raw reply [flat|nested] 96+ messages in thread
* Re: Windows Ada database support. 2004-12-08 11:19 ` Marius Amado Alves @ 2004-12-08 12:51 ` Frank Piron 2004-12-08 13:43 ` Dmitry A. Kazakov 2004-12-08 13:41 ` Dmitry A. Kazakov 1 sibling, 1 reply; 96+ messages in thread From: Frank Piron @ 2004-12-08 12:51 UTC (permalink / raw) Am Wed, 08 Dec 2004 11:19:02 +0000 schrieb Marius Amado Alves <amado.alves@netcabo.pt>: >> ... I would like to view it as a distributed system >> and get rid of the notion of DB altogether. Only persistent objects. No >> I/O, just memory-mappings. [ Clearly, in any short term perspective it >> is >> an utopia. ] (Kasakov) > > Utopia? There are currently persistent and prevalent object systems for > Ada and Java and probably other languages. I recall Prevayler for Java, > and at least one persistent system for Ada (isn't that actually by > yourself?). The problem is they force an object oriented model which as > has been argued does not always fit the application domain well. > In a past project i considered Cachᅵ as an alternative to pure relational databases (see http://www.intersystems.com/cache/technology/index.html). I discussed the possibility of writing an Ada Binding to Cachᅵ with consultants from Intersystems. They seemed to be interested, but then on a customer demand we were forced to choose big O. -- Frank Piron, defrankatkonaddot (leftrotate two) ^ permalink raw reply [flat|nested] 96+ messages in thread
* Re: Windows Ada database support. 2004-12-08 12:51 ` Frank Piron @ 2004-12-08 13:43 ` Dmitry A. Kazakov 0 siblings, 0 replies; 96+ messages in thread From: Dmitry A. Kazakov @ 2004-12-08 13:43 UTC (permalink / raw) On Wed, 08 Dec 2004 13:51:12 +0100, Frank Piron wrote: > In a past project i considered Cach� as an alternative to pure relational > databases (see http://www.intersystems.com/cache/technology/index.html). Interesting. Thanks for the link! -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 96+ messages in thread
* Re: Windows Ada database support. 2004-12-08 11:19 ` Marius Amado Alves 2004-12-08 12:51 ` Frank Piron @ 2004-12-08 13:41 ` Dmitry A. Kazakov 2004-12-08 16:09 ` Georg Bauhaus 1 sibling, 1 reply; 96+ messages in thread From: Dmitry A. Kazakov @ 2004-12-08 13:41 UTC (permalink / raw) On Wed, 08 Dec 2004 11:19:02 +0000, Marius Amado Alves wrote: >> ... I would like to view it as a distributed system >> and get rid of the notion of DB altogether. Only persistent objects. No >> I/O, just memory-mappings. [ Clearly, in any short term perspective it is >> an utopia. ] (Kasakov) > > Utopia? There are currently persistent and prevalent object systems for > Ada and Java and probably other languages. I recall Prevayler for Java, > and at least one persistent system for Ada (isn't that actually by > yourself?). Yes. But I meant a distributed system. Object persistence alone is not enough for a great number of applications. Translated into DB terms: a distributed system is when you have stored procedures. Just persistence means that you read object(s), process them locally and then store back. > The problem is they force an object oriented model which as > has been argued does not always fit the application domain well. Why should it be any problem? Considering OO as an advanced ADT, I see no clear alternative. If you mean that established OO religion, well, that is not a technical issue. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 96+ messages in thread
* Re: Windows Ada database support. 2004-12-08 13:41 ` Dmitry A. Kazakov @ 2004-12-08 16:09 ` Georg Bauhaus 2004-12-08 19:46 ` Dmitry A. Kazakov 0 siblings, 1 reply; 96+ messages in thread From: Georg Bauhaus @ 2004-12-08 16:09 UTC (permalink / raw) Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> wrote: : Yes. But I meant a distributed system. Object persistence alone is not : enough for a great number of applications. Translated into DB terms: a : distributed system is when you have stored procedures. I think few people will agree here. A DBMS is usually serving your distributed program, and also several different, possibly unrelated distributed programs. Stored procedures need not even be present. There might be good organisational reasons to use a common DB for the different programs. I think that "coordinating I/O" in the way of a DBMS is rather tricky. Do you have an idea of a protocol that might extend Ada's rudimentary distribution support to achieve at least as much data coordination as contemporary DBMSs? -- Georg ^ permalink raw reply [flat|nested] 96+ messages in thread
* Re: Windows Ada database support. 2004-12-08 16:09 ` Georg Bauhaus @ 2004-12-08 19:46 ` Dmitry A. Kazakov 2004-12-09 12:20 ` Georg Bauhaus 0 siblings, 1 reply; 96+ messages in thread From: Dmitry A. Kazakov @ 2004-12-08 19:46 UTC (permalink / raw) On Wed, 8 Dec 2004 16:09:01 +0000 (UTC), Georg Bauhaus wrote: > Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> wrote: > >: Yes. But I meant a distributed system. Object persistence alone is not >: enough for a great number of applications. Translated into DB terms: a >: distributed system is when you have stored procedures. > > I think few people will agree here. A DBMS is usually serving your > distributed program, and also several different, possibly unrelated > distributed programs. > > Stored procedures need not even be present. > There might be good organisational reasons to use a common DB for > the different programs. Yes of course. Programs coupled via DB can be viewed as a primitive distributed application. Stored procedures were a more shiny example. > I think that "coordinating I/O" in the way of a DBMS is rather tricky. > Do you have an idea of a protocol that might extend Ada's rudimentary > distribution support to achieve at least as much data coordination > as contemporary DBMSs? We have tasks and protected objects. Add here marshaling parameters. So you will need by-value semantics for types of those. Hence, allow T'Class for everything. You will then need interface inheritance from concrete types (to have automatic user-defined type conversions between local and remote types). That drags MI. Do not forget to make tasks and protected objects OO. Something like COM/DCOM will be also very useful... -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 96+ messages in thread
* Re: Windows Ada database support. 2004-12-08 19:46 ` Dmitry A. Kazakov @ 2004-12-09 12:20 ` Georg Bauhaus 2004-12-09 12:59 ` Dmitry A. Kazakov 0 siblings, 1 reply; 96+ messages in thread From: Georg Bauhaus @ 2004-12-09 12:20 UTC (permalink / raw) Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> wrote: : We have tasks and protected objects. Add here marshaling parameters. So you : will need by-value semantics for types of those. Hence, allow T'Class for : everything. You will then need interface inheritance from concrete types : (to have automatic user-defined type conversions between local and remote : types). That drags MI. Do not forget to make tasks and protected objects : OO. Something like COM/DCOM will be also very useful... And you end up with the problems of value copying (and externally stored data). Have a lookt at purely functional programs. :-) Time, memory, updates, and concurrent updates, are not your friend when you prefer good abstractions :-) -- Georg ^ permalink raw reply [flat|nested] 96+ messages in thread
* Re: Windows Ada database support. 2004-12-09 12:20 ` Georg Bauhaus @ 2004-12-09 12:59 ` Dmitry A. Kazakov 0 siblings, 0 replies; 96+ messages in thread From: Dmitry A. Kazakov @ 2004-12-09 12:59 UTC (permalink / raw) On Thu, 9 Dec 2004 12:20:38 +0000 (UTC), Georg Bauhaus wrote: > Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> wrote: >: We have tasks and protected objects. Add here marshaling parameters. So you >: will need by-value semantics for types of those. Hence, allow T'Class for >: everything. You will then need interface inheritance from concrete types >: (to have automatic user-defined type conversions between local and remote >: types). That drags MI. Do not forget to make tasks and protected objects >: OO. Something like COM/DCOM will be also very useful... > > And you end up with the problems of value copying (and externally stored > data). First, they are *not* stored. They exist. Second, it is impossible to have referential semantics for everything, just because reference itself has to be by-copy. > Have a lookt at purely functional programs. :-) Time, memory, > updates, and concurrent updates, are not your friend when you prefer > good abstractions :-) I didn't mean that. Yes we have to marshal the parameters. But it by no means imply that we should marshal everything. It is up to the application to decide what should be passed by-copy and what by-reference (handle). It is no different from what happens when you compile a procedure call in Ada. Protected objects are by-reference in Ada. The difference though is that in a distributed application physical location of an object may change. So the run-time should be able to move an object from one place to another, to make a replica of it etc. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 96+ messages in thread
* Re: Windows Ada database support. 2004-12-08 10:56 ` Dmitry A. Kazakov 2004-12-08 11:19 ` Marius Amado Alves @ 2004-12-08 15:58 ` Georg Bauhaus 2004-12-08 19:43 ` Dmitry A. Kazakov 1 sibling, 1 reply; 96+ messages in thread From: Georg Bauhaus @ 2004-12-08 15:58 UTC (permalink / raw) Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> wrote: : Again, there are two different questions. I have already formulated them in : another post: : : 1. Why relations should be handled? : 2. Why Ada cannot handle them? : : To dismiss Ada.Database.Relational, we have to answer 1=yes, 2=no, : because... Ada the language does not have what SQL processors do have. You would have to build some sort of DKQL processor in your Ada.Databases.Relational. Go ahead :-) : I would like to view it as a distributed system : and get rid of the notion of DB altogether. Only persistent objects. No : I/O, just memory-mappings. [ Clearly, in any short term perspective it is : an utopia. ] Say all you have is persistent objects. What kind of query do you have if you want to know about 2 or more objects? ^ permalink raw reply [flat|nested] 96+ messages in thread
* Re: Windows Ada database support. 2004-12-08 15:58 ` Georg Bauhaus @ 2004-12-08 19:43 ` Dmitry A. Kazakov 2004-12-09 11:58 ` Georg Bauhaus 0 siblings, 1 reply; 96+ messages in thread From: Dmitry A. Kazakov @ 2004-12-08 19:43 UTC (permalink / raw) On Wed, 8 Dec 2004 15:58:44 +0000 (UTC), Georg Bauhaus wrote: > Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> wrote: >: Again, there are two different questions. I have already formulated them in >: another post: >: >: 1. Why relations should be handled? >: 2. Why Ada cannot handle them? >: >: To dismiss Ada.Database.Relational, we have to answer 1=yes, 2=no, >: because... > > Ada the language does not have what SQL processors do have. But you can translate into SQL. Why Ada.Database.Relational.Foo cannot call My_ Fancy_DB.Execute ("BAZ ...")? I do not propose to write a new DB engine. > You would have to build some sort of DKQL processor in your > Ada.Databases.Relational. Go ahead :-) >: I would like to view it as a distributed system >: and get rid of the notion of DB altogether. Only persistent objects. No >: I/O, just memory-mappings. [ Clearly, in any short term perspective it is >: an utopia. ] > > Say all you have is persistent objects. What kind of query do you > have if you want to know about 2 or more objects? Why should I query? It is for untyped tables. If I have an object at hand then I know its type and so everything I can do with it. If I don't, then I have another object, a container that refers to my object. That container again has a type and that provides operations to access its elements. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 96+ messages in thread
* Re: Windows Ada database support. 2004-12-08 19:43 ` Dmitry A. Kazakov @ 2004-12-09 11:58 ` Georg Bauhaus 2004-12-09 13:27 ` Dmitry A. Kazakov 0 siblings, 1 reply; 96+ messages in thread From: Georg Bauhaus @ 2004-12-09 11:58 UTC (permalink / raw) Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> wrote: : : But you can translate into SQL. Why Ada.Database.Relational.Foo cannot call : My_ Fancy_DB.Execute ("BAZ ...")? I do not propose to write a new DB : engine. This brings us back to the original questions :-) : Why should I query? It is for untyped tables. If I have an object at hand : then I know its type and so everything I can do with it. If I don't, then I : have another object, a container that refers to my object. That container : again has a type and that provides operations to access its elements. Relations. Records In DB system, as well as records in Ada have components which can be updated. Relations between 2 or more objects may thus depend on time. However, an object's type cannot reflect this, because types are static. You could associate one different type with each possible combination of component values in your program... ^ permalink raw reply [flat|nested] 96+ messages in thread
* Re: Windows Ada database support. 2004-12-09 11:58 ` Georg Bauhaus @ 2004-12-09 13:27 ` Dmitry A. Kazakov 2004-12-09 18:58 ` Georg Bauhaus 0 siblings, 1 reply; 96+ messages in thread From: Dmitry A. Kazakov @ 2004-12-09 13:27 UTC (permalink / raw) On Thu, 9 Dec 2004 11:58:06 +0000 (UTC), Georg Bauhaus wrote: > Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> wrote: >: >: But you can translate into SQL. Why Ada.Database.Relational.Foo cannot call >: My_ Fancy_DB.Execute ("BAZ ...")? I do not propose to write a new DB >: engine. > > This brings us back to the original questions :-) > >: Why should I query? It is for untyped tables. If I have an object at hand >: then I know its type and so everything I can do with it. If I don't, then I >: have another object, a container that refers to my object. That container >: again has a type and that provides operations to access its elements. > > Relations. Records In DB system, as well as records in Ada have components > which can be updated. Relations between 2 or more objects may thus depend > on time. = bad design, if you are you talking about changes unknown during design. In that case you are in trouble anyway! You have to modify all UPDATE statements if just a new column is added. Consider a memory snapshot made before changing the CPU from Intel to PowerPC. This is what your DB is worth. You can still read and write it. But data without semantics is a garbage. But if my language supports interface inheritance I can still deal with reasonable changes. I could derive new types from old bases and throw out old representations: type X is record Foo : Integer; Bar : String (...) end record; type Y is new X without Foo -- (:-)) with record Baz : Float; end record; Of course the compiler will force me to define getter and setter for Y.Foo, otherwise all class-wide methods will be lost. > However, an object's type cannot reflect this, because types > are static. You could associate one different type with each possible > combination of component values in your program... 1. No application uses all possible combinations. They have very concrete things to do. 2. Types are static but values are not. This is why T'Class works so nicely! 3. Remember, I always campaigned for MI and MD in comp.lang.ada! (:-)) -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 96+ messages in thread
* Re: Windows Ada database support. 2004-12-09 13:27 ` Dmitry A. Kazakov @ 2004-12-09 18:58 ` Georg Bauhaus 2004-12-10 10:22 ` Dmitry A. Kazakov 0 siblings, 1 reply; 96+ messages in thread From: Georg Bauhaus @ 2004-12-09 18:58 UTC (permalink / raw) Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> wrote: : You have to modify all UPDATE : statements if just a new column is added. Nope. : But data without semantics is a : garbage. Data with fixed semantics is inflexible :-) : : I could derive new types from old bases and throw out : old representations: unless they carry some important information from the old design still needed in other applications. :> However, an object's type cannot reflect this, because types :> are static. You could associate one different type with each possible :> combination of component values in your program... : : 1. No application uses all possible combinations. They have very concrete : things to do. For example, they react to different value that an object has in time? ^ permalink raw reply [flat|nested] 96+ messages in thread
* Re: Windows Ada database support. 2004-12-09 18:58 ` Georg Bauhaus @ 2004-12-10 10:22 ` Dmitry A. Kazakov 2004-12-10 14:28 ` Georg Bauhaus 0 siblings, 1 reply; 96+ messages in thread From: Dmitry A. Kazakov @ 2004-12-10 10:22 UTC (permalink / raw) On Thu, 9 Dec 2004 18:58:45 +0000 (UTC), Georg Bauhaus wrote: > Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> wrote: > >: You have to modify all UPDATE >: statements if just a new column is added. > > Nope. >: But data without semantics is a >: garbage. > > Data with fixed semantics is inflexible :-) Flexible garbage is still garbage. Honestly, I prefer rigid garbage, it is predictable. Who knows where a flexible one might leak into! (:-)) >: I could derive new types from old bases and throw out >: old representations: > > unless they carry some important information from the old design > still needed in other applications. No, I can always do it as long as the new implementation is conform to the semantics of T'Class. >:> However, an object's type cannot reflect this, because types >:> are static. You could associate one different type with each possible >:> combination of component values in your program... >: >: 1. No application uses all possible combinations. They have very concrete >: things to do. > > For example, they react to different value that an object has in time? Where is any problem? Doesn't sin(x) react to any value of x whenever it be called? -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 96+ messages in thread
* Re: Windows Ada database support. 2004-12-10 10:22 ` Dmitry A. Kazakov @ 2004-12-10 14:28 ` Georg Bauhaus 2004-12-10 15:14 ` Dmitry A. Kazakov 0 siblings, 1 reply; 96+ messages in thread From: Georg Bauhaus @ 2004-12-10 14:28 UTC (permalink / raw) Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> wrote: :>:> However, an object's type cannot reflect this, because types :>:> are static. You could associate one different type with each possible :>:> combination of component values in your program... :>: :>: 1. No application uses all possible combinations. They have very concrete :>: things to do. :> :> For example, they react to different value that an object has in time? : : Where is any problem? Doesn't sin(x) react to any value of x whenever it be : called? if sin(x) > threshold then ... That is, a program doesn't express all possible flows in the set of type declarations. Similarly, when programs construct values from standardised "garbage databases", they express some flows using query results, not necessarily a style of writing close to the type system. Moreover, future behavior of the program will be influenced by manipulating the "garbage database". This feels somewhat like symbol manipulation ;-) ^ permalink raw reply [flat|nested] 96+ messages in thread
* Re: Windows Ada database support. 2004-12-10 14:28 ` Georg Bauhaus @ 2004-12-10 15:14 ` Dmitry A. Kazakov 0 siblings, 0 replies; 96+ messages in thread From: Dmitry A. Kazakov @ 2004-12-10 15:14 UTC (permalink / raw) On Fri, 10 Dec 2004 14:28:52 +0000 (UTC), Georg Bauhaus wrote: > Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> wrote: >:>:> However, an object's type cannot reflect this, because types >:>:> are static. You could associate one different type with each possible >:>:> combination of component values in your program... >:>: >:>: 1. No application uses all possible combinations. They have very concrete >:>: things to do. >:> >:> For example, they react to different value that an object has in time? >: >: Where is any problem? Doesn't sin(x) react to any value of x whenever it be >: called? > > if sin(x) > threshold then > ... > > That is, a program doesn't express all possible flows in the set of type > declarations. > Similarly, when programs construct values from standardised "garbage > databases", they express some flows using query results, not necessarily > a style of writing close to the type system. Nobody requires to express all semantics in type relations. [Yet compare how "relationists" are trying to force semantics into relations!] The known to be stable part of the semantics should be mapped into types. That is the stand point of strongly, manifestly typed languages like Ada. Because for practically any application, there is such stable part, and it is reasonable large. If you will try to convince me that business applications cannot be programmed in that way, then well, we should agree that we disagree. > Moreover, future behavior of the program will be influenced > by manipulating the "garbage database". This feels somewhat like symbol > manipulation ;-) This is just plainly wrong design. Note that even Ada compiler need not to translate itself together with the program code. The very fact that Ada compilers were successfully written in Ada shows that strong typing is no obstacle. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 96+ messages in thread
* Re: Windows Ada database support. 2004-12-08 10:03 ` Ole-Hjalmar Kristensen 2004-12-08 10:56 ` Dmitry A. Kazakov @ 2004-12-08 15:52 ` Georg Bauhaus 2004-12-08 20:22 ` Dmitry A. Kazakov 1 sibling, 1 reply; 96+ messages in thread From: Georg Bauhaus @ 2004-12-08 15:52 UTC (permalink / raw) Ole-Hjalmar Kristensen <ole-hjalmar.kristensen@substitute_employer_here.com> wrote: : He may just as well be thinking in terms of sets and relations. SQL is : just a slightly clumsy way of conveying those thoughts to the DB : engine :-) Yes, thanks. I was thinking about one of those tiny little everyday problems, and how to solve it and how to employ Ada .Containers as "middleware". The problem: "Declare an ordered selection of objects. Make it available" Objects may be either just fetched from the DB or they may be synthesized, i.e. newly constructed from the DB (!), effectively establishing a type. If a language supports EVAL, you can even construct the types at at language level at run time. Omitting the ordering issue, a SETL2 expression demonstrates a non-SQL solution: result := { [foo, bar] : id in { R.key : R in S | R.key >= 100 and R.key <= 200 }, bar = T(foo) | foo = id }; No trace of SQL, but I'm sure you can see the relation between a SET programming language and SQL. Note the result set ;-) This is working code, S and T are sets of tuples. You may say that there are tuples and sets, iieek. But the in computer programs you will have to work with some sort of compound data at some level. If you dislike the presence of tuples, ".key" is a selector. R.key means the same as R(1). This allows you to build interfaces so you don't have to see the tuples. Dmitry, what is your plan the other way round, i.e. how do you make data related expressions for some nice higher level abstraction? -- Georg ^ permalink raw reply [flat|nested] 96+ messages in thread
* Re: Windows Ada database support. 2004-12-08 15:52 ` Georg Bauhaus @ 2004-12-08 20:22 ` Dmitry A. Kazakov 2004-12-09 12:12 ` Georg Bauhaus 2004-12-09 12:22 ` Ole-Hjalmar Kristensen 0 siblings, 2 replies; 96+ messages in thread From: Dmitry A. Kazakov @ 2004-12-08 20:22 UTC (permalink / raw) On Wed, 8 Dec 2004 15:52:17 +0000 (UTC), Georg Bauhaus wrote: > Ole-Hjalmar Kristensen <ole-hjalmar.kristensen@substitute_employer_here.com> wrote: >: He may just as well be thinking in terms of sets and relations. SQL is >: just a slightly clumsy way of conveying those thoughts to the DB >: engine :-) > > Yes, thanks. I was thinking about one of those tiny little > everyday problems, and how to solve it and how to employ Ada > .Containers as "middleware". The problem: > > "Declare an ordered selection of objects. Make it available" > > Objects may be either just fetched from the DB or they may be synthesized, > i.e. newly constructed from the DB (!), effectively establishing a type. > If a language supports EVAL, you can even construct the types at > at language level at run time. > > Omitting the ordering issue, a SETL2 expression demonstrates a > non-SQL solution: > > result := { [foo, bar] : > id in { R.key : R in S | R.key >= 100 and R.key <= 200 }, > bar = T(foo) | foo = id }; > > No trace of SQL, but I'm sure you can see the relation between > a SET programming language and SQL. Note the result set ;-) > This is working code, S and T are sets of tuples. > You may say that there are tuples and sets, iieek. But the in > computer programs you will have to work with some sort of > compound data at some level. > If you dislike the presence of tuples, ".key" is a selector. > R.key means the same as R(1). This allows you to build interfaces > so you don't have to see the tuples. > > Dmitry, what is your plan the other way round, i.e. how do you > make data related expressions for some nice higher level abstraction? You have cunningly formulated the problem so that there is no higher level! (:-)) There is either: for I in S'Range loop if S (I).Key in 100..200 then for J in T'Range loop if T (J).Foo = S (I).Key then Append (Result, S (I).Key, T (J).Foo); end if; end loop; end if; end loop; or you define "*" (product) for the type Table'Class (of S and T) + other operations to extract sets from the tables. But the question is why an application should always organize its data in a way which could require implementation these, very expensive, operations? Isn't it so that tabular view just forces global container operations? When we write in Ada we avoid global operations. How often you copy an array in Ada (except String<->Unbounded_String conversion (:-))? Merge two arrays? Isn't S and T just a two-dimensional array? -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 96+ messages in thread
* Re: Windows Ada database support. 2004-12-08 20:22 ` Dmitry A. Kazakov @ 2004-12-09 12:12 ` Georg Bauhaus 2004-12-09 12:59 ` Dmitry A. Kazakov 2004-12-09 12:22 ` Ole-Hjalmar Kristensen 1 sibling, 1 reply; 96+ messages in thread From: Georg Bauhaus @ 2004-12-09 12:12 UTC (permalink / raw) Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> wrote: : On Wed, 8 Dec 2004 15:52:17 +0000 (UTC), Georg Bauhaus wrote: :> Dmitry, what is your plan the other way round, i.e. how do you :> make data related expressions for some nice higher level abstraction? : : You have cunningly formulated the problem so that there is no higher level! : (:-)) There is either: I think you can go to a higher level. At a cost. : for I in S'Range loop : if S (I).Key in 100..200 then : for J in T'Range loop : if T (J).Foo = S (I).Key then : Append (Result, S (I).Key, T (J).Foo); : end if; : end loop; : end if; : end loop; : : or you define "*" (product) for the type Table'Class (of S and T) + other : operations to extract sets from the tables. : : But the question is why an application should always organize its data in a : way which could require implementation these, very expensive, operations? First, the operations need not be expensive, e.g. because there is an index. Second, when defining the data format, I may not be in a position to choose freely. A definition that suits my program might be a real obstacle to someone else's. : Isn't S and T just a two-dimensional array? No, S and T are selections from views. It is up to the RDBMS to organize the data to fit the SELECTion choices. Each record in S or T is part of a list of structured values, each component being of some type. Depending on the DB system, you might even have more than sequential access prior to turning the result into an Ada object. ^ permalink raw reply [flat|nested] 96+ messages in thread
* Re: Windows Ada database support. 2004-12-09 12:12 ` Georg Bauhaus @ 2004-12-09 12:59 ` Dmitry A. Kazakov 2004-12-09 18:45 ` Georg Bauhaus 0 siblings, 1 reply; 96+ messages in thread From: Dmitry A. Kazakov @ 2004-12-09 12:59 UTC (permalink / raw) On Thu, 9 Dec 2004 12:12:22 +0000 (UTC), Georg Bauhaus wrote: [...] > First, the operations need not be expensive, e.g. because there is > an index. Global operations are always expensive. > Second, when defining the data format, I may not be in a position to > choose freely. A definition that suits my program might be a real obstacle > to someone else's. It is simpler: there is no data without operations. When you define something as a table of rows and columns you also implicitly define the operations. And these are that real obstacle, in so many cases. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 96+ messages in thread
* Re: Windows Ada database support. 2004-12-09 12:59 ` Dmitry A. Kazakov @ 2004-12-09 18:45 ` Georg Bauhaus 0 siblings, 0 replies; 96+ messages in thread From: Georg Bauhaus @ 2004-12-09 18:45 UTC (permalink / raw) Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> wrote: : It is simpler: there is no data without operations. When you define : something as a table of rows and columns you also implicitly define the : operations. And these are that real obstacle, in so many cases. A relational model is also an obstacle to the building of a distributed non-standard multiple interface multiple dispatch nightmare :-) As Ole-Hjalmar has explained, a relational database is middle ground, you have something standardised with wich others can work, too. Imagine IDL and proxies as an alternative. Data exists, but which part of the ORBA application takes care maintaining its existence? Incidentally, SETL2, a set language, is said to have a tranparent database backend (proprietary), so data exists. Also between program runs. -- Georg ^ permalink raw reply [flat|nested] 96+ messages in thread
* Re: Windows Ada database support. 2004-12-08 20:22 ` Dmitry A. Kazakov 2004-12-09 12:12 ` Georg Bauhaus @ 2004-12-09 12:22 ` Ole-Hjalmar Kristensen 2004-12-09 14:03 ` Dmitry A. Kazakov 1 sibling, 1 reply; 96+ messages in thread From: Ole-Hjalmar Kristensen @ 2004-12-09 12:22 UTC (permalink / raw) >>>>> "DAK" == Dmitry A Kazakov <mailbox@dmitry-kazakov.de> writes: <snip> >> >> Dmitry, what is your plan the other way round, i.e. how do you >> make data related expressions for some nice higher level abstraction? DAK> You have cunningly formulated the problem so that there is no higher level! DAK> (:-)) There is either: DAK> for I in S'Range loop DAK> if S (I).Key in 100..200 then DAK> for J in T'Range loop DAK> if T (J).Foo = S (I).Key then DAK> Append (Result, S (I).Key, T (J).Foo); DAK> end if; DAK> end loop; DAK> end if; DAK> end loop; DAK> or you define "*" (product) for the type Table'Class (of S and T) + other DAK> operations to extract sets from the tables. DAK> But the question is why an application should always organize its data in a DAK> way which could require implementation these, very expensive, operations? DAK> Isn't it so that tabular view just forces global container operations? When DAK> we write in Ada we avoid global operations. How often you copy an array in DAK> Ada (except String<->Unbounded_String conversion (:-))? Merge two arrays? DAK> Isn't S and T just a two-dimensional array? Yes, and you have generic tools to follow relations (join). But There *are* reasons for organizing your data this way *in the database*. This organization is very flexible, but as you observe, may be expensive. SQL compilers have do do lots of optimizations to allow efficient execution of complex queries, especially since a large database is orders of magnitude bigger than the amount of available memory. The basic idea is that you organize your data in a way that captures the aspects that are inherent to the data domain itself, not specific to any particular application. This data model (the conceptual schema) can then support a very large set of different applications with no need to reorganize the data model. This is much more flexible than the old network databases, where the access paths (indices, pointers) were hard-coded into the data model, giving excellent performance for some applications, and absolutely abysmal for others, in addition to being hard to maintain. In the three-schema architecture, each different application is then supported by a different external schema, typically a subset or a transformation of the conceptual schema. The application itself need not organize its internal structures as tables, but having a sound conceptual view and a normalized structure is really a necessity if your database is going to support a multitude of applications. This line of thinking obviously originates from corporate databases and the like, where there is a need to maintain a large body of data *independently* of the applications which may happen to use them. I think you see the similarites between the three-schema architecture and the rapid prototyping tool I described earlier. It is not a coincidence :-) Now think of this: *IF* set operations were supported by the programming language, wouldn't it be a convenient way of structuring your code (efficiency considerations aside)? Example: I want to update the salaries of all employees with a specific manager, or I want to see which projects an employee has worked on in the last month, or find the sum of all hours employees working for a specific manager has worked on a specific project. These are all problems which can be trivially solved using sets. No navigation or hard-coded links necessary, no need to create objects which maintain the relation links, no need to add new classes when you want to add a new relation between objects or when your relation changes from on-to-one to one-to-many or many-to many. This is taken care of by modyfying the integrity constraints of your schema. The inherent relations in your problem remains the same whether you prefer a solution with explicit links (the most typical for object-oriented solutions, in my experience), or a tabular organization, in which case you will most likely use the DBMS engine to do the bulk of the processing. One way of looking at the difference is that with a tabular organization the application is free (via set operations) to follow or update any thinkable relation, limited only by the integrity constraints, while in an object-oriented or network system, you will typically have materialized those relations you are interested in, and the constraints are implicit in your materialization. But there clearly is a mismatch between the facilites provided by the RDBMS and your typical programming language, I am just unsure what is the best way to bridge that gap. DAK> -- DAK> Regards, DAK> Dmitry A. Kazakov DAK> http://www.dmitry-kazakov.de -- C++: The power, elegance and simplicity of a hand grenade. ^ permalink raw reply [flat|nested] 96+ messages in thread
* Re: Windows Ada database support. 2004-12-09 12:22 ` Ole-Hjalmar Kristensen @ 2004-12-09 14:03 ` Dmitry A. Kazakov 0 siblings, 0 replies; 96+ messages in thread From: Dmitry A. Kazakov @ 2004-12-09 14:03 UTC (permalink / raw) On 09 Dec 2004 13:22:15 +0100, Ole-Hjalmar Kristensen wrote: >>>>>> "DAK" == Dmitry A Kazakov <mailbox@dmitry-kazakov.de> writes: > > <snip> > >> > >> Dmitry, what is your plan the other way round, i.e. how do you > >> make data related expressions for some nice higher level abstraction? > > DAK> You have cunningly formulated the problem so that there is no higher level! > DAK> (:-)) There is either: > > DAK> for I in S'Range loop > DAK> if S (I).Key in 100..200 then > DAK> for J in T'Range loop > DAK> if T (J).Foo = S (I).Key then > DAK> Append (Result, S (I).Key, T (J).Foo); > DAK> end if; > DAK> end loop; > DAK> end if; > DAK> end loop; > > DAK> or you define "*" (product) for the type Table'Class (of S and T) + other > DAK> operations to extract sets from the tables. > > DAK> But the question is why an application should always organize its data in a > DAK> way which could require implementation these, very expensive, operations? > DAK> Isn't it so that tabular view just forces global container operations? When > DAK> we write in Ada we avoid global operations. How often you copy an array in > DAK> Ada (except String<->Unbounded_String conversion (:-))? Merge two arrays? > DAK> Isn't S and T just a two-dimensional array? > > Yes, and you have generic tools to follow relations (join). But There > *are* reasons for organizing your data this way *in the database*. > This organization is very flexible, but as you observe, may be > expensive. SQL compilers have do do lots of optimizations to allow > efficient execution of complex queries, especially since a large > database is orders of magnitude bigger than the amount of available > memory. The basic idea is that you organize your data in a way that > captures the aspects that are inherent to the data domain itself, not > specific to any particular application. This data model (the > conceptual schema) can then support a very large set of different > applications with no need to reorganize the data model. This is much > more flexible than the old network databases, where the access paths > (indices, pointers) were hard-coded into the data model, giving > excellent performance for some applications, and absolutely abysmal > for others, in addition to being hard to maintain. In the three-schema > architecture, each different application is then supported by a > different external schema, typically a subset or a transformation of > the conceptual schema. The application itself need not organize its > internal structures as tables, but having a sound conceptual view and > a normalized structure is really a necessity if your database is going > to support a multitude of applications. This line of thinking > obviously originates from corporate databases and the like, where > there is a need to maintain a large body of data *independently* of > the applications which may happen to use them. Right. They have a giant garbage container and just throw everything in. The applications have to sort out. (:-)) This approach is efficient no longer the variety of applications remains very limited. What does anything just a bit more complex than a business application? It packs everything in blobs! > I think you see the > similarites between the three-schema architecture and the rapid > prototyping tool I described earlier. It is not a coincidence :-) > > Now think of this: *IF* set operations were supported by the > programming language, wouldn't it be a convenient way of structuring > your code (efficiency considerations aside)? Example: I want to update > the salaries of all employees with a specific manager, or I want to > see which projects an employee has worked on in the last month, or > find the sum of all hours employees working for a specific manager has > worked on a specific project. These are all problems which can be > trivially solved using sets. No navigation or hard-coded links > necessary, no need to create objects which maintain the relation > links, no need to add new classes when you want to add a new relation > between objects or when your relation changes from on-to-one to > one-to-many or many-to many. This is taken care of by modyfying the > integrity constraints of your schema. The inherent relations in your > problem remains the same whether you prefer a solution with explicit > links (the most typical for object-oriented solutions, in my > experience), or a tabular organization, in which case you will most > likely use the DBMS engine to do the bulk of the processing. One way > of looking at the difference is that with a tabular organization the > application is free (via set operations) to follow or update any > thinkable relation, limited only by the integrity constraints, while > in an object-oriented or network system, you will typically have > materialized those relations you are interested in, and the > constraints are implicit in your materialization. True. But also, nothing prevents us (with MI) from providing a relational view for containers. Comparison with Ada: the major problem with Unbounded_String is that it does not implement the abstract array interface. This prevents us from writing generic applications working for both String and Unbounded_String. Probably there is no ideal interface for all cases. But OO (or ADT) design could simultaneously provide support for many views. It seems that vendors of non-relational data bases have no great problems with implementing SQL and ODBC for their products. > But there clearly is a mismatch between the facilites provided by the > RDBMS and your typical programming language, I am just unsure what is > the best way to bridge that gap. To take a look at the calendar! (:-)) -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 96+ messages in thread
* Re: Windows Ada database support. 2004-12-07 21:29 ` Dmitry A. Kazakov 2004-12-08 2:24 ` Georg Bauhaus @ 2004-12-10 20:47 ` Simon Wright 1 sibling, 0 replies; 96+ messages in thread From: Simon Wright @ 2004-12-10 20:47 UTC (permalink / raw) "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes: > Nobody. The problem is that we need arrays, or more generally, ordered > containers. This is the way the most people think about tables. They do not > think about them in terms of relations. Yes, a relational view is complete > and you can express everything in it. But it is too low level. This is why ^^^^^^^^^^^^^ too high level, I think! > people keep on inventing ways to mark that damned rows. Nothing is wrong > with that, but the result is, as Warren has pointed out, utter chaos. -- Simon Wright 100% Ada, no bugs. ^ permalink raw reply [flat|nested] 96+ messages in thread
* Re: Windows Ada database support. 2004-11-24 12:31 Windows Ada database support Mark Doherty ` (2 preceding siblings ...) 2004-11-25 1:03 ` David Botton @ 2004-11-25 2:18 ` bubble 3 siblings, 0 replies; 96+ messages in thread From: bubble @ 2004-11-25 2:18 UTC (permalink / raw) I have tryed GNade and GWindows.Database package before. they are also easy to use. I prefer GWindows.Database package because of small and easy. if you want running on Linux. maybe you can try APQ. it seem very powerful.(I have no chance to try it.) I not sure you can use gwindows.database package in linux environment. GWindows sample code link: http://en.wikibooks.org/wiki/Programming:Ada:Libraries:Database:GWindows APQ link. http://www.adapower.com/launch.php?URL=http%3A%2F%2Fgnade.sourceforge.net%2F "Mark Doherty" <mark_doherty@yahoo.co.uk> ??? news:5e3e03a7.0411240431.7e037a4e@posting.google.com ???... > I am developing a (GNAT 3.15p) ADA web (AWS) / Database (???) > application that will run on LINUX but developed on windows (xp). > > What is the current best advice. GNADE / CLAW / GWINDOWS.Database > GNAVI, or something else? > > Thanx Mark. ^ permalink raw reply [flat|nested] 96+ messages in thread
end of thread, other threads:[~2004-12-10 20:47 UTC | newest] Thread overview: 96+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2004-11-24 12:31 Windows Ada database support Mark Doherty 2004-11-24 15:04 ` Marius Amado Alves 2004-11-24 18:35 ` Pascal Obry 2004-11-24 19:17 ` Alex R. Mosteo 2004-11-24 19:30 ` Dmitry A. Kazakov 2004-11-24 22:32 ` Ching Bon Lam 2004-11-25 1:03 ` David Botton 2004-11-25 17:50 ` Warren W. Gay VE3WWG 2004-11-26 9:15 ` Dmitry A. Kazakov 2004-11-26 18:36 ` David Botton 2004-11-27 8:59 ` Dmitry A. Kazakov 2004-11-28 0:46 ` David Botton 2004-11-28 9:51 ` Dmitry A. Kazakov 2004-11-28 10:23 ` Pascal Obry 2004-11-28 11:03 ` Dmitry A. Kazakov 2004-11-28 14:38 ` Martin Dowie 2004-11-28 16:51 ` Marius Amado Alves 2004-11-28 19:50 ` Martin Dowie 2004-11-28 20:49 ` Christopher Browne 2004-11-28 17:29 ` Dmitry A. Kazakov 2004-11-28 17:47 ` Marius Amado Alves 2004-11-28 18:56 ` Dmitry A. Kazakov 2004-12-06 14:57 ` Warren W. Gay VE3WWG 2004-11-28 18:45 ` Pascal Obry 2004-11-28 19:13 ` Dmitry A. Kazakov 2004-11-28 20:04 ` Pascal Obry 2004-11-29 9:04 ` Dmitry A. Kazakov 2004-11-29 10:07 ` Adrien Plisson 2004-11-29 11:00 ` Alex R. Mosteo 2004-11-29 13:12 ` Frank Piron 2004-12-01 16:19 ` Pascal Obry 2004-12-02 10:37 ` Marius Amado Alves 2004-12-02 10:58 ` Frank Piron 2004-12-03 2:50 ` John B. Matthews 2004-11-28 20:36 ` Marius Amado Alves 2004-11-29 1:40 ` Georg Bauhaus 2004-11-29 10:30 ` Marius Amado Alves 2004-11-29 1:28 ` Georg Bauhaus 2004-11-29 8:53 ` Dmitry A. Kazakov 2004-11-29 11:09 ` Georg Bauhaus 2004-11-29 12:01 ` Dmitry A. Kazakov 2004-11-29 14:07 ` Georg Bauhaus 2004-11-29 18:04 ` Dmitry A. Kazakov 2004-11-29 22:05 ` Georg Bauhaus 2004-11-30 11:00 ` Dmitry A. Kazakov 2004-11-30 13:46 ` Ole-Hjalmar Kristensen 2004-11-30 15:04 ` Dmitry A. Kazakov 2004-11-30 16:09 ` Georg Bauhaus 2004-11-30 16:07 ` Georg Bauhaus 2004-11-30 18:52 ` Dmitry A. Kazakov 2004-11-30 21:10 ` Georg Bauhaus 2004-12-01 9:11 ` Dmitry A. Kazakov 2004-11-29 12:56 ` Marius Amado Alves 2004-11-29 13:26 ` Dmitry A. Kazakov 2004-11-29 15:02 ` Frank Piron 2004-11-29 15:58 ` Marius Amado Alves 2004-11-29 18:16 ` Dmitry A. Kazakov 2004-11-30 7:14 ` Frank Piron 2004-12-06 14:48 ` Warren W. Gay VE3WWG 2004-12-06 16:29 ` Dmitry A. Kazakov 2004-12-06 17:52 ` Warren W. Gay VE3WWG 2004-12-06 19:44 ` Georg Bauhaus 2004-12-06 20:49 ` Dmitry A. Kazakov 2004-12-07 5:16 ` Warren W. Gay VE3WWG 2004-12-07 10:29 ` Dmitry A. Kazakov 2004-12-07 15:49 ` Georg Bauhaus 2004-12-07 21:29 ` Dmitry A. Kazakov 2004-12-08 2:24 ` Georg Bauhaus 2004-12-08 9:05 ` Dmitry A. Kazakov 2004-12-08 10:03 ` Ole-Hjalmar Kristensen 2004-12-08 10:56 ` Dmitry A. Kazakov 2004-12-08 11:19 ` Marius Amado Alves 2004-12-08 12:51 ` Frank Piron 2004-12-08 13:43 ` Dmitry A. Kazakov 2004-12-08 13:41 ` Dmitry A. Kazakov 2004-12-08 16:09 ` Georg Bauhaus 2004-12-08 19:46 ` Dmitry A. Kazakov 2004-12-09 12:20 ` Georg Bauhaus 2004-12-09 12:59 ` Dmitry A. Kazakov 2004-12-08 15:58 ` Georg Bauhaus 2004-12-08 19:43 ` Dmitry A. Kazakov 2004-12-09 11:58 ` Georg Bauhaus 2004-12-09 13:27 ` Dmitry A. Kazakov 2004-12-09 18:58 ` Georg Bauhaus 2004-12-10 10:22 ` Dmitry A. Kazakov 2004-12-10 14:28 ` Georg Bauhaus 2004-12-10 15:14 ` Dmitry A. Kazakov 2004-12-08 15:52 ` Georg Bauhaus 2004-12-08 20:22 ` Dmitry A. Kazakov 2004-12-09 12:12 ` Georg Bauhaus 2004-12-09 12:59 ` Dmitry A. Kazakov 2004-12-09 18:45 ` Georg Bauhaus 2004-12-09 12:22 ` Ole-Hjalmar Kristensen 2004-12-09 14:03 ` Dmitry A. Kazakov 2004-12-10 20:47 ` Simon Wright 2004-11-25 2:18 ` bubble
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox