Re: [ANN] Data Source Name parser (ODBC etc.)
From: Nick Roberts (nick.roberts_at_acm.org)
Date: 01/15/05
- Next message: Nick Roberts: "Re: Ada equivalent for C-pointer?"
- Previous message: Jeffrey Carter: "Re: How unchecked conversion works?"
- In reply to: Georg Bauhaus: "[ANN] Data Source Name parser (ODBC etc.)"
- Next in thread: Georg Bauhaus: "Re: [ANN] Data Source Name parser (ODBC etc.)"
- Reply: Georg Bauhaus: "Re: [ANN] Data Source Name parser (ODBC etc.)"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Sat, 15 Jan 2005 18:42:06 +0000
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
- Next message: Nick Roberts: "Re: Ada equivalent for C-pointer?"
- Previous message: Jeffrey Carter: "Re: How unchecked conversion works?"
- In reply to: Georg Bauhaus: "[ANN] Data Source Name parser (ODBC etc.)"
- Next in thread: Georg Bauhaus: "Re: [ANN] Data Source Name parser (ODBC etc.)"
- Reply: Georg Bauhaus: "Re: [ANN] Data Source Name parser (ODBC etc.)"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|