--On Montag, 7. Oktober 2002 08:48 -0400 Andrew Arensburger <arensb+koha-devel@ooblick.com> wrote:
The current version in CVS already allows you to do this: use db_scheme = Pg say "db_scheme = PostgreSQL".)
Just in passing: does anyone have any better suggestions for this configuration option than "db_scheme"? Perhaps "db_driver"? It depends on what this option should affect...
Another possibility would be to move all dbs code in one modul and change this modul by selecting the dbs... Then the above option would discribe Database System and the KohaDataHandlingModule: datahandling = [MySQL|PostgrSQL|...] What sorts of things should go into this low-level module, though? What should the interface look like, to be useful? I thougt extracting the datacollection and dataupdating of the webinterface-scripts and the put it in a seperate Module. I can imagine the following:
use KDB; # Koha database interface module.
($author, $title) = KDB->get_fields_by_key( "biblio", # Table "biblionumber", # Field to search 12345, # Value to search for "author", "title"); # Fields to return yes, it's a bit more generic than I thought of, I first would took the data collection and data manipulation and put in in seperate functions. Then I seperate it to a module, and look if I can generalize it by looking what similar functions are needed by other scripts. That would divide data presentation from datacollection and datamanipulating and allow to 'optimize' Datahandling for every Database System, e.g. also makes it possible to use plain textfiles or ODBC / Access on Windows Systems... It also makes it possible to change the Datastructures, e.g. by create views instead of tables in normalisation...
@branches = KDB->list_fields( "branches" # Table "branchname"); # Field to return The meaning of 'list_fields' goes more: 'Please, would you show me which fields are available at this table?' This would be nice to have generic Tableviews... It should be better:
The question is, what should the KDB API look like? It should contain the data functions of any Script and could contain the datacreation and updating funktions. In more specific form or (not XOR) more generalized form. It should be useful, I think it could be. and it ought to be more convenient than the SQL calls that are currently in the code. no, it wouldn't be more convenient since the database structure still has to be created, and the author still has to create the queryconstructs. The benefit would be that we avoid if (dbs==... elseif ...elseif ... or switch dbs...case codeblocks in every script. Should there be STL-like iterators, so that you can write $iterator = KDB->list_rows("biblio"); while (%record = KDB->next($iterator)) { print "$record{title} by $record{author}\n"; }
@branches = KDB->ShowData( "branches", "branchname", "condition" ); or more specialized: @branches = KDB->ShowBranchNames( "condition" ); this would be fine.
? Should it try to be generic enough that the scripts don't have to assume SQL? yes. The Userinterface(scripts) only need data in one desired form, that consist of perl-datatypes. Should it use AUTOLOAD what does that mean? so that it can figure out what to do from the function name, so that you can write %borrower = KDB->find_borrower_by_cardnumber("V10000008"); # find_<table>_by_<field> The name 'find_borrower_by_cardnumber' would implizize that there are borrowers which have an cardnumber. If it is a table 'borrowers' or a view containing data from 'Persons', 'feetsizes' and 'has a card from biblio' should be invisible, it is not necessary to create the webinterfacescripts...
greets ervin
-- Andrew Arensburger This message *does* represent the arensb@ooblick.com views of ooblick.com <PROGRAM> ::= Do What I Want