On 19-4-2012 16:07, michael.vancanneyt-0is9kj9s...@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 _______________________________________________ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
