koha-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Koha-devel] Re: [Koha] latest on PostgreSQL


From: Ervin Peters
Subject: Re: [Koha-devel] Re: [Koha] latest on PostgreSQL
Date: Mon Oct 7 09:00:03 2002

--On Montag, 7. Oktober 2002 08:48 -0400 Andrew Arensburger <address@hidden> 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:

        @branches = KDB->ShowData( "branches", "branchname", "condition" );

or more specialized:

        @branches = KDB->ShowBranchNames( "condition" );

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";
        }
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
address@hidden                      views of ooblick.com
                     <PROGRAM> ::= Do What I Want




reply via email to

[Prev in Thread] Current Thread [Next in Thread]