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

Pat Eyler pate at eylerfamily.org
Mon Oct 7 09:04:08 CEST 2002


Just a quick request on behalf of the non-developer list.  Please make
sure we're watching our follow-ups to keep overly technical stuff of off
the koha list and on the koha-devel list.

thanks,
-pate

On Mon, 7 Oct 2002, Ervin Peters wrote:

> --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
>
> _______________________________________________
> Koha mailing list
> Koha at lists.katipo.co.nz
> http://lists.katipo.co.nz/mailman/listinfo/koha
>





More information about the Koha-devel mailing list