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

[Ervin Peters]

--On Montag, 7. Oktober 2002 08:48 -0400 Andrew Arensburger 
<arensb+koha-devel at 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:

	@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
> arensb at ooblick.com                      views of ooblick.com
> 		     <PROGRAM> ::= Do What I Want