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.
_______________________________________________
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

Reply via email to