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

[Reinier Olislagers]

On 19-4-2012 16:07, michael.vancanneyt-0Is9KJ9Sb0A at public.gmane.org wrote:
> 
> It's a historic issue:
> 
> I think fpdatadict was historically implemented first. It was
> implemented separately because I do not believe this belongs in sqldb.
> For instance, the data dictionary also supports DBF files.
> 
> Obviously Joost thought otherwise, and started a parallel implementation in
> sqldb. I cannot undo that (unless Joost agrees, of course).
Yes; at first look, the datadict approach seems more object oriented and
polished to me.

> Now, supposing it must remain in sqldb:
> 
> I do not know if the calls for schema information will provide all info
> that
> datadict needs. If they do not, then I must re-implement them in datadict.
Or... part in datadict and part in sqldb. Either case is of course messy.

> If they do, then the default fpdatadict information retrieval routines
> can use the new schema calls.
> Unfortunately, it would take some time to investigate how much it overlaps.
Understood.

> The bottom line is that I still think that this kind of info belongs in
> fpdatadict, which is broader in scope than sqldb (you could use it in zeos,
> for instance). But if it is available from sqldb, then fpdatadict can of
> course reuse that.
Datadict seems a nice object oriented wrapper; having some lower level
functions in sqldb that datadict calls might not be as bad as it
sounds... of course, if you want to be able to plug in other database
drivers then the picture changes.
I would agree with you though that the functionality would be more or
less duplicated AFAICT.... without any obvious benefit.

The downside could be that people that are used to other drivers might
expect the sqldb way of doing things. However, the apparent lack of
users up to now (and lacklustre implementation in the drivers
themselves) seems to suggest that would not be a big problem.


Proposal
========
1. As I'm interested in getting support for MS SQL Server and Sybase ASE
into lazdatadesktop, I propose I'll go on with trying to make that work
using the current sqldb structure. This will mean that a lot of code
will go into new datadict fpddmssql.pp and fpddsybase.pp modules.
I'll submit patches when done.
2. With that experience, I might have a better idea whether
extending/changing sqldb with ISO information_schema could easily work
for datadict.... however, I must say your argument re other db adapters
does make a lot of sense.

If so, I'll convert lazdatadesktop and the mssqlconn sqldb connector,
breaking compatibility.
Next, I'll convert Firebird sqldb to use the new approach.
If those work and are acceptable, I can submit a patch for the other
connectors (Oracle, PostgreSQL, mysql)... but will probably need some
support for that.

If not, I can try and adapt fpdatadict.pp and their dependents to use
information_schema calls in e.g. ImportIndexes in order to make a
default implementation for ISO compatible RDBMS... which non-compatible
sqldb/dbf/zeos/whatever dbs will override...
I will just ignore sqldb; perhaps provide a patch for mssqlconn to at
least let it spit out similar info as Firebird.

What do you guys think?

Reinier

Regards,
Reinier