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

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

[Georg Bauhaus]

hi,

some time ago when discussion APQ or Ada and databases,
Brian May suggested URL-like strings describing database
connections. A parser library for such strings (data
source names) is now available at
 http://home.arcor.de/bauhaus/Ada/dsn.html

The library is at version 0b.2, that is, it has bugs.
Some are known, some are fun. The distribution contains
a small sample program that allows interactive checking
of DSNs.

Documentation is available in source, and as
 http://home.arcor.de/bauhaus/Ada/dsn.pdf

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.


Georg Bauhaus

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

[Nick Roberts]

Georg Bauhaus <bauhaus@futureapps.de> wrote:

> some time ago when discussion APQ or Ada and databases, Brian May
> suggested URL-like strings describing database connections. A parser
> library for such strings (data source names) is now available at
>  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.

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? And surely instantiating a generic is too elaborate, as well? Surely
only one derivation needs to be returned (if there is a legal derivation)? I
think you only need a simple function, e.g.:

   package Database_IO.DSN is

      type Data_Source_Descriptor is private;

      function Parse (Name: in String) return Data_Source_Descriptor;

      function Server_Name (Descriptor: in Data_Source_Descriptor)
            return String;

      function User_Name (Descriptor: in Data_Source_Descriptor)
            return String;

      function User_Password (Descriptor: in Data_Source_Descriptor)
            return String;

      ...

      Syntax_Error: exception;

      type Parsing_Diagnosis (Max: Positive) is private;

      function Diagnose (Name: in String) return Parsing_Diagnosis;

      function Error_Count (Diagnosis: in Parsing_Diagnosis)
            return Natural;

      function Error_Message (Diagnosis: in Parsing_Diagnosis;
                              Number:    in Positive)
            return String;
      ...

      Use_Error: exception renames IO_Exceptions.Use_Error;

   private
      ...
   end;

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.

The function Diagnose parses the given DSN (in Name) and returns any errors
in a composite value (type Parsing_Diagnosis).

Functions allow the interrogation of the composite values. The discriminant
Max sets a maximum on the number of different errors to be stored in
diagnosis.

The idea is that typical user code will have a nice, easy declaration like
this:

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

followed by interrogation of Source to open up the appropriate database, log
on, open a schema, table, etc.

For quick and dirty applications, this enough. If the parsing fails, an
exception is raised.

For proper applications, the exception can be caught and handled, something
like this:

   exception
      when Syntax_Error =>
         declare
            Errors: constant Parsing_Diagnosis(20) := Diagnose(...);
         begin
            for i in Error_Count(Errors) loop
               Put_Line( Standard_Error, Error_Message(Errors,i) );
            end loop;
         end;
         ...

The exception Use_Error is raised if anything else goes wrong.

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

-- 
Nick Roberts

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

[Georg Bauhaus]

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