[fpc-pascal] Re: RE : RE : Re: SQLDB GetSchemaInfoSQL for indexesetc?

[michael.vancanneyt at wisa.be]

On Thu, 19 Apr 2012, Ludo Brands wrote:

>
>>> Has anybody used this functionality in sqldb at all?
>>
>> No. For a simple reason:
>>
>> I implemented all this information in fpdatadict;
>> I think it belongs more there, and definitely not in the
>> basic data API.
>>
>
> Some of the metadata are necessary in the basic data API (tables, columns,
> indices) and are a partial overlap with the TFPDDEngine descendants. >From an
> abstraction perspective, I think it is better to have database specifics as
> much as possible in one location and use standards as much as possible when
> specifying metadata.
>
> To be honest, I just discovered fpdatadict. Probably the missing
> implementation of a lot of the databases is one of the reasons why I haven't
> noticed it before.
> First impression is that the fpdatadict implementation makes sense but
> unfortunately the properties used are perhaps close to one particular
> database but are insufficient or confusing for other databases (no reference
> to schema or catalog, NUMERIC_SCALE, length vs. octet_length,
> collation,...).

The data dictionary is an extension of what existed in the BDE times in
Borland. It also featured a data dictionary but for some reason, Borland
abandonded it (never understood why, as it is a good idea).

This explains why it uses in large part that terminology. 
Other parts are based on firebird terminology for the simple reason that I 
use that database for all my projects. Even the database diff is in
production use.

As for re-using existing terminology (schema data etc.), this is dangerous 
as it creates the expectation that the implementation conforms to a certain 
standard, which is what I want to avoid.

(I don't believe I've ever used the word schema in connection to a database.
I think of an electrical wiring blueprint if I hear that word ;) )

But adding some aliases and add new features such as octet_length should 
not be a problem (NUMERIC_SCALE exists in precision).

Michael.