Re: [ANN] Data Source Name parser (ODBC etc.)

[Georg Bauhaus <sb463ba@user1.uni-duisburg.de>]

Nick Roberts wrote:
> Georg Bauhaus <bauhaus@futureapps.de> wrote:
> 

>> http://home.arcor.de/bauhaus/Ada/dsn.html
>>...
>>I have tried to make the interface simple, any comments as to whether it
>>is usable or whether it should go down the drain will affect following
>>versions.

> I like the idea. I think the syntax you propose is great (it needs to be
> completed). I'd like the query syntax to be defined and parsed, using the
> familiar field=value form and & for conjunction.

Thanks for the close examination!


There are two reasons why the query string syntax is not (yet)
present in the grammar (apart from lazyness, third reason).
The first reason is that
I wasn't sure it is the way to go. Are we indepentent of pre-existing
ways to communicate additional information to database drivers?
(I think we are, but I am not sure.)

Second, parsers for query strings do already exist (in CGI packages),
so I thought you just pick your favourite query string parser
and pass the query string part of the DSN to that parser. Or should
the DSN packages incorporate one of the offerings?

> I like the good error diagnostics, but I feel the Messages interface is too
> elaborate. Surely an enumerated type is not required, but just a message
> string?

The Messages interface is a bit elaborate, the reason was "compiler
checked  internationalization". I want a compiler to check the
completeness of the set of error messages in some chosen natural
language.
This also leaves Messages' client packages untouched when messages are
changed. I've done this before, it works nicely. (This technique
also allows you to automaticalls produce a plain text file from the
Messages package, or any file format that a translator prefers. :-)
  The Messages package eventuall becomes a unit that just renames
a package of message constants in some national language, during
software configuration.

Another raison d'etre of the enumerated type of error messages is
that you can use its values much in like you can use SQL error
numbers. Also it's probalby easier to react to specific errors
specified by number than specified by string values
(in several national languages ;-).

> And surely instantiating a generic is too elaborate, as well?

Given your suggestion of separating the production of a parse results
object from the production of a diagnosis object in case of syntax
errors, I see that the generic/callback solution can be replaced.
Though in this case we'll parse twice. Perhaps using error rules
only the second time? I'll try.

> Surely
> only one derivation needs to be returned (if there is a legal derivation)?

I have no proof yet, but right, it's almost sure that, absent error
rules, the grammar isn't ambigous or erroneous at the level of
detail given in the DSN spec.


>       type Data_Source_Descriptor is private;

I like this type name better than my Data_Source_Details.
If no one has any objections to using Data_Source_Descriptor
instead, I'll raplace it.

>       Syntax_Error: exception;

Hm. Yes if we use the two-subprograms approach.


> The function Parse either successfully parses the given DSN (in Name) and
> returns a broken down composite value (type Data_Source_Descriptor), or it
> raises the exception Syntax_Error.

 >       Source: constant Data_Source_Descriptor := Parse(...);

A small design issue: Should the broken down Data_Source_Descriptor
composite be allocated at the client side, that is, in code under the
control of the library user? Or should the parse function create one?
Similarly for the Diagnose function (which also needs to somehow
know the capacity).

> I'm interested in participating in the development of some kind of open
> Database I/O interface package.

Will
http://gnade.sourceforge.net/
do?

-- Georg