<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=Content-Type content="text/html; charset=iso-8859-1">
<META content="MSHTML 6.00.2800.1126" name=GENERATOR></HEAD>
<BODY style="MARGIN-TOP: 2px; FONT: 8pt Tahoma; MARGIN-LEFT: 2px">
<DIV><FONT size=2>This goes along with my other email about modularizing
authentication. My feeling is that most of koha is sort of embedded, like auth
the storage should be modularized, like this</FONT></DIV>
<DIV><FONT size=2></FONT> </DIV>
<DIV><FONT size=2>there should be a wrapper with default methods that do
something a default way, one of those would be search. the mysql search would
use mysql features (ie: full text search), a postgres search would do whatever
they do. basically you'd have custom queries for each DBM since each method that
does the querying would be DBM specific. Only the parent class would hold static
variables and things that would be consistant across all the DBM's. If done this
way storage is trivial, one could store everything in flat text files if they
wanted!. </FONT></DIV>
<DIV><FONT size=2></FONT> </DIV>
<DIV><FONT size=2>I must emphasize that this is the *correct* way to program
things like this, and if we (my university) decides to use Koha I will certainly
help wherever i can.</FONT></DIV>
<DIV> </DIV>
<DIV> </DIV>
<DIV>Joshua Brindle<BR>UNIX Administrator<BR>Southern Nazarene
University<BR><BR>>>> Chris Cormack <CHRIS@KATIPO.CO.NZ>01/16/03
04:10AM >>> <BR>On Thu, Jan 16, 2003 at 11:02:43AM +0100, paul POULAIN
said: <BR>> Chris Cormack a ?crit: <BR>> <BR>> >Hi There <BR>>
> <BR>> >Just to throw in my 2 cents worth, i dont see using mysql
fulltext <BR>> >searching <BR>> >as ruling out db independence.
<BR>> >It just forces us to code more carefully, perhaps setting a value
in <BR>> >/etc/koha.conf usefulltext=yes or the like. Which we can then
use to <BR>> >decide <BR>> >whether to make a standard like search,
or to use a fulltext index. <BR>> > <BR>> BUT : the standard like
search is UNUSEABLE on a 50 000+ biblio DB, as <BR>> every search means a
full parsing of the table. <BR>> If you add the same thing for the thesaurus
table, which is widely used <BR>> in marc cataloguing, and some other place
where full text indexing will <BR>> be usefull... <BR>> <BR>Hi Again paul
:) <BR><BR>Well maybe not 50,000 .. but 500,000+ ... its working ok for HLT's
78709 <BR>biblios. <BR>But I take your point, and agree wholeheartedly the
current search code <BR>badly needs a rewrite and lots of optimisation. <BR>And
im sure HLT wouldnt say no to any speed increase :-) <BR><BR>I think what i was
trying to say (bear in mind its getting late here, and my <BR>mind is probably
muddled :-)) was that we should be able to provide the <BR>option for other
people to use a database of their choice. Without <BR>restricting those who want
to from using mysql fulltext indexing. <BR><BR>On the topic of fulltext
searching we had a discussion about it on irc today. <BR>I cant currently get to
the irc logs but when i can, ill mark the discussion <BR>and post the url to the
devel list. <BR><BR>Chris <BR>-- <BR>Chris Cormack Programmer <BR>025 500 789
Katipo Communications Ltd <BR><U><A
href="mailto:chris@katipo.co.nz">chris@katipo.co.nz</A></U> <U><A
href="http://www.katipo.co.nz/">www.katipo.co.nz</A></U>
<BR>_______________________________________________ <BR>Koha mailing list
<BR><U><A href="mailto:Koha@lists.katipo.co.nz">Koha@lists.katipo.co.nz</A></U>
<BR><U><A
href="http://lists.katipo.co.nz/mailman/listinfo/koha">http://lists.katipo.co.nz/mailman/listinfo/koha</A></U>
<BR></DIV></BODY></HTML>