Hiya Nathan Nathan Gray wrote:
I've been watching Koha for a little while now, and finally my wife told me to just install it, because she wants to use it. As she reads books, she wants to keep track of which ones she likes, so she can check them out when our two-year old gets to that reading level.
So now we've got a working Koha system on her computer. I've noticed already a few things I'd like to tweak, so I can use it more comfortably.
Excellent
I am downloading from CVS right now. Is there a way to run Koha directly from the CVS tree? Any quick start pointers? I figure I can leave plain Koha on my wife's machine, and put the CVS version on mine, both running off her database.
There is a little tutorial on the wiki about running Koha from cvs. http://www.saas.nsw.edu.au/koha_wiki/index.php?page=CVSSymLinkInstallation
I'm a Perl programmer by trade, with a lot of my time spent re-writing modules to increase stability, efficiency, and readability (at least, I understand it better when I'm done). That's mostly what I'd like to do here.
Sounds good to me. Code cleanup is always appreciated. What would also be highly useful is, while you tidy modules. Write some unit tests for them.
First off, I'd like to get Z39.50 searching a little nicer. Part of that might just be clearer documentation. (I'm having problems finding some ISBN numbers in the Library of Congress, even when they have a LC call number, so it would be nice to be able to search on that as well, or know which other servers I should be looking at.) And so when I search by title and get lots of records with the same title, it would be nice to have a few more columns to differentiate between them, like date published, or LC call number if there is no ISBN.
Sounds like a good plan to me.
I would also like to allow the use of Net::SMTP, rather than Mail::Sendmail, and perhaps the DateTime suite rather than Date::Manip. I would also like to be able to use DBD::Pg, rather than DBD::mysql, though I am not volunteering for that quite yet.
How should I go about getting changes back into CVS? Is there a contact person I need to go through?
The thing to bear in mind, is that in CVS there is the HEAD where development for 2.2.x is going on. Paul Polain is the release manager for 2.2 so talking to him about what you plan to work on is a good idea. Just to remove duplicated effort etc. Then there is the rel_2_0 branch, which is where the 2.0.x releases are drawn from. So bugfixing etc should be done in that branch, new features added in the HEAD. M J Ray is looking after the 2.0.x releases. So he's your best contact for work in that branch. When you've had a chat with them, (im sure they will see this message and reply). You can let myself or Pat Eyler know your sourceforge username and we'll give you write access to the cvs repository. Chris -- Chris Cormack Programmer 027 4500 789 Katipo Communications Ltd chris@katipo.co.nz www.katipo.co.nz
Chris Cormack a écrit :
Nathan Gray wrote:
So now we've got a working Koha system on her computer. I've noticed already a few things I'd like to tweak, so I can use it more comfortably.
Excellent
Yes, excellent. Welcome on board.
The thing to bear in mind, is that in CVS there is the HEAD where development for 2.2.x is going on. Paul Polain is the release manager for 2.2 so talking to him about what you plan to work on is a good idea. Just to remove duplicated effort etc.
yes : look in the wiki (www.koha.org/wiki) the "roadmap for 2.2" you'll see where we are going. At the moment, 2 devs are working at full time on Koha : * Jean Baron, hired by ENSMP (Mines de Paris) * Me, payed by ENSMP & EMN (Mines de Nantes) I think I haven't forgotten anything in the roadmap. Pls don't work on circulation & Biblio related stuff, as JB is working on circ & I'm working on cataloguing. You can clean any other module (acquisition has a lot of things to clean. I already did some work on borrowers modules, but it's not ended) -- Paul POULAIN Consultant indépendant en logiciels libres responsable francophone de koha (SIGB libre http://www.koha-fr.org)
paul POULAIN wrote: [...] Hi all, I just want to add a cent from me and to humbly remind that I would love to see the z39.50 search modified so non iso8859-1 charsets are displayed and stored correctly. I've uploaded a modified biblio.pm and search.pl to the z39.50 directory both in 2.0 and the HEAD branch in hope that someone with sufficient knowledge would have a starting point for it. The fix was provided by Zbigniew Bomert, a polish volunteer with no cvs write access at this time. Can you please take care of it? thanks a lot.
Paul et al, I've been trying to figure out how best to solve our ' and , problem with the marc searching and I've got a few comments to make about the way that the searches are currently done (using marc_word) and the problems with how marc_word stores data. So here's a classic example of an author that fails currently: o'brian, patrick right now the search seperates the 'o' and the 'brian' and the 'patrick' and the resulting query looks like this: select distinct m1.bibid from biblio,biblioitems,marc_biblio,marc_word as m1,marc_word as m2,marc_word as m3,marc_word as m4 where biblio.biblionumber=marc_biblio.biblionumber and biblio.biblionumber=biblioitems.biblionumber and m1.bibid=marc_biblio.bibid and (m1.bibid=m2.bibid and m1.bibid=m3.bibid and m1.bibid=m4.bibid) and ((m1.word like 'o%' and m1.tag+m1.subfieldid in ('100a','110a', '700a', '710a'))and (m2.word like '\'%' and m2.tag+m2.subfieldid in('100a','110a', '700a', '710a'))and (m3.word like 'brian%' and m3.tag+m3.subfieldid in('100a','110a', '700a', '710a'))and (m4.word like 'patrick%' and m4.tag+m4.subfieldid in('100a','110a', '700a', '710a'))) order by biblio.title So there is at least one major problem with this query which does not return any results): marc_word does not store values as small as ' or o. So of course there are no results ... Even if I strip out the ' and , from the query and search on something like (I add the following after line 117 in SearchMarc.pm): @$value[$i] =~ s/'/ /g; @$value[$i] =~ s/,/ /g; which turns out like: 'o brian patrick' it fails ('o' is too small for marc_word); and of course @$value[$i] =~ s/'//g; @$value[$i] =~ s/,//g; resulting in: 'obrian patrick' fails too--the data simply isn't stored right for this kind of search. So I see two ways to fix this problem: 1) stop using marc_word for these kinds of searches and use marc_subfield_table (which has the whole 'o'brian, patrick' in subfield_value) or 2) fix the way that marc_word stores small values (it should store everything including , ' and single letters like 'a', 'o', etc. Any comments? Further suggestions? Joshua
At what point does marc_word become so big and clunky that it becomes a liability instead of an asset? NPL's marc-word file is full of 'junk' entries like "(pa." (picked up when an ISBN number has "(pa.)" after it to denote paperback) and other such MARC oddities. Our stopword file should ideally be expanded to catch all of this junk, but I haven't done that yet. Now we're talking about adding punctuation marks and single letters! I agree with Joshua that this is what should be done if we're going to depend on using marc_word and expect to get any meaningful search results. My question is: maybe it would be more efficient to just use marc_subfield_table for these searches and forget about marc_word? Stephen Joshua Ferraro said:
Paul et al,
I've been trying to figure out how best to solve our ' and , problem with the marc searching and I've got a few comments to make about the way that the searches are currently done (using marc_word) and the problems with how marc_word stores data.
So here's a classic example of an author that fails currently: o'brian, patrick
right now the search seperates the 'o' and the 'brian' and the 'patrick' and the resulting query looks like this:
select distinct m1.bibid from biblio,biblioitems,marc_biblio,marc_word as m1,marc_word as m2,marc_word as m3,marc_word as m4 where biblio.biblionumber=marc_biblio.biblionumber and biblio.biblionumber=biblioitems.biblionumber and m1.bibid=marc_biblio.bibid and (m1.bibid=m2.bibid and m1.bibid=m3.bibid and m1.bibid=m4.bibid) and ((m1.word like 'o%' and m1.tag+m1.subfieldid in ('100a','110a', '700a', '710a'))and (m2.word like '\'%' and m2.tag+m2.subfieldid in('100a','110a', '700a', '710a'))and (m3.word like 'brian%' and m3.tag+m3.subfieldid in('100a','110a', '700a', '710a'))and (m4.word like 'patrick%' and m4.tag+m4.subfieldid in('100a','110a', '700a', '710a'))) order by biblio.title
So there is at least one major problem with this query which does not return any results): marc_word does not store values as small as ' or o. So of course there are no results ...
Even if I strip out the ' and , from the query and search on something like (I add the following after line 117 in SearchMarc.pm):
@$value[$i] =~ s/'/ /g; @$value[$i] =~ s/,/ /g;
which turns out like:
'o brian patrick'
it fails ('o' is too small for marc_word); and of course
@$value[$i] =~ s/'//g; @$value[$i] =~ s/,//g;
resulting in:
'obrian patrick'
fails too--the data simply isn't stored right for this kind of search.
So I see two ways to fix this problem: 1) stop using marc_word for these kinds of searches and use marc_subfield_table (which has the whole 'o'brian, patrick' in subfield_value) or 2) fix the way that marc_word stores small values (it should store everything including , ' and single letters like 'a', 'o', etc.
Any comments? Further suggestions?
Joshua
------------------------------------------------------- This SF.Net email is sponsored by: Oracle 10g Get certified on the hottest thing ever to hit the market... Oracle 10g. Take an Oracle 10g class now, and we'll give you the exam FREE. http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click _______________________________________________ Koha-devel mailing list Koha-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/koha-devel
-- Stephen Hedges Skemotah Solutions, USA www.skemotah.com -- shedges@skemotah.com
Stephen Hedges a écrit :
At what point does marc_word become so big and clunky that it becomes a liability instead of an asset? NPL's marc-word file is full of 'junk' entries like "(pa." (picked up when an ISBN number has "(pa.)" after it to denote paperback) and other such MARC oddities. Our stopword file should ideally be expanded to catch all of this junk, but I haven't done that yet. Now we're talking about adding punctuation marks and single letters! I agree with Joshua that this is what should be done if we're going to depend on using marc_word and expect to get any meaningful search results. My question is: maybe it would be more efficient to just use marc_subfield_table for these searches and forget about marc_word?
you're right stephen... I have an other idea that could be coded quickly : in the MARC framework, we could add a checkbox called "do NOT index this subfield". If checked, the subfield wouldn't be stored in marc_word (but stored in marc_subfield_table) (Needs a script to clean the DB too, should be quite easy : foreach subfield in marc_subfield_structure { if checkbox checked { delete from marc_word where subfield= this one } } ...) -- Paul POULAIN Consultant indépendant en logiciels libres responsable francophone de koha (SIGB libre http://www.koha-fr.org)
Paul a écrit: NPL had a tech meeting today focusing on the opac searching and we have reached some tentative conclusions about how to proceed. Running some test searches using marc_subfield_table we realized that a search model based on that table is inadequate for our needs. For example, a search on 'patrick o'brian' using the 'like' syntax produces no results if the database entry is stored as 'o'brian, patrick' (when author is stored in the 100a that is the format). On the other hand, a search using the current marc_word model fails for reasons we have already talked about (marc_word does not keep track of single characters, &c.). But if the marc_word table did index single charcters, a search model based on marc_word would work very well. For example, a search on 'o'brian, patrick' or 'patrick o'brian' would both return the correct records. So our idea is to re-create our marc_word table so that it indexes all characters from the tags and subfields that we want to use for searches (we don't need all of them as you pointed out; for instance, we will never use 300 for a search). So we have three basic tasks: 1.) write a script to re-create marc_word using the parameters we choose for searching and including all characters. 2.) fix Biblio.pm so that it will include all characters when it adds records to marc_word (currently we add to our holdings using a modified version of bulkmarcimport.pl that relies on Biblio.pm) 3.) write a clean-up script to delete all the tags and subfields from marc_word that we will never use (like 300) Does that sound like a sound plan to you Paul? Do you have any scripts that will speed up the process of re-building our marc_word table--if not we will write one ourselves. Can you make the changes to Biblio.pm that will force it to index single characters? One final point about search results. Currently the marc searching does not pass all the variables to the template so that we can choose what values to display (for example, Lord of the Rings: The Two Towers currently displays as 'Lord of the Rings:' without the subtitle). I suggest that we setup a method of easily making marc fields available to the template so that each library can decide exactly what marc fields they want to display for the initial search results. Comments? Suggestions? Joshua On Wed, May 26, 2004 at 04:38:37PM +0200, paul POULAIN wrote:
Stephen Hedges a écrit :
At what point does marc_word become so big and clunky that it becomes a liability instead of an asset? NPL's marc-word file is full of 'junk' entries like "(pa." (picked up when an ISBN number has "(pa.)" after it to denote paperback) and other such MARC oddities. Our stopword file should ideally be expanded to catch all of this junk, but I haven't done that yet. Now we're talking about adding punctuation marks and single letters! I agree with Joshua that this is what should be done if we're going to depend on using marc_word and expect to get any meaningful search results. My question is: maybe it would be more efficient to just use marc_subfield_table for these searches and forget about marc_word?
you're right stephen... I have an other idea that could be coded quickly : in the MARC framework, we could add a checkbox called "do NOT index this subfield". If checked, the subfield wouldn't be stored in marc_word (but stored in marc_subfield_table) (Needs a script to clean the DB too, should be quite easy : foreach subfield in marc_subfield_structure { if checkbox checked { delete from marc_word where subfield= this one } } ...)
-- Paul POULAIN Consultant indépendant en logiciels libres responsable francophone de koha (SIGB libre http://www.koha-fr.org)
------------------------------------------------------- This SF.Net email is sponsored by: Oracle 10g Get certified on the hottest thing ever to hit the market... Oracle 10g. Take an Oracle 10g class now, and we'll give you the exam FREE. http://ads.osdn.com/?ad_id149&alloc_id66&opÌk _______________________________________________ Koha-devel mailing list Koha-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/koha-devel
Joshua Ferraro a écrit :
Paul a écrit:
NPL had a tech meeting today focusing on the opac searching and we have reached some tentative conclusions about how to proceed. Running some test searches using marc_subfield_table we realized that a search model based on that table is inadequate for our needs. For example, a search on 'patrick o'brian' using the 'like' syntax produces no results if the database entry is stored as 'o'brian, patrick' (when author is stored in the 100a that is the format). On the other hand, a search using the current marc_word model fails for reasons we have already talked about (marc_word does not keep track of single characters, &c.). But if the marc_word table did index single charcters, a search model based on marc_word would work very well. For example, a search on 'o'brian, patrick' or 'patrick o'brian' would both return the correct records. So our idea is to re-create our marc_word table so that it indexes all characters from the tags and subfields that we want to use for searches (we don't need all of them as you pointed out; for instance, we will never use 300 for a search). So we have three basic tasks:
another idea, that would be better maybe : replace ' by _. Thus, o'brian searches o_brian, that will be stored in the DB. The only limit is that a search on brian won't be successful. Tell me if it's a problem. Otherwise, we could add a 'index also 1 letter words', but, imho, ONLY with the 'do not index this subfield feature'. Everybody can give it's opinion here. Both solutions are easy to code.
1.) write a script to re-create marc_word using the parameters we choose for searching and including all characters.
2.) fix Biblio.pm so that it will include all characters when it adds records to marc_word (currently we add to our holdings using a modified version of bulkmarcimport.pl that relies on Biblio.pm)
3.) write a clean-up script to delete all the tags and subfields from marc_word that we will never use (like 300)
Does that sound like a sound plan to you Paul? Do you have any scripts that will speed up the process of re-building our marc_word table--if not we will write one ourselves. Can you make the changes to Biblio.pm that will force it to index single characters?
yep, if we decide to do it. I've no speedy script to rebuild marc_word table :-(
One final point about search results. Currently the marc searching does not pass all the variables to the template so that we can choose what values to display (for example, Lord of the Rings: The Two Towers currently displays as 'Lord of the Rings:' without the subtitle). I suggest that we setup a method of easily making marc fields available to the template so that each library can decide exactly what marc fields they want to display for the initial search results.
already planned. I'll try to commit some code on CVS ASAP. "MARC view" is ready (in OPAC). we plan to add a systempreference called 'ISBD' where the library could define it's own biblio presentation. Something like : [200a;][200b/][(100c)] The ; means a ; is added AFTER the 200a, the ( means a ( is added BEFORE the 100c. Not exactly a ISBD view, but not too far either.
Comments? Suggestions?
you're right stephen... I have an other idea that could be coded quickly : in the MARC framework, we could add a checkbox called "do NOT index this subfield". If checked, the subfield wouldn't be stored in marc_word (but stored in marc_subfield_table) (Needs a script to clean the DB too, should be quite easy : foreach subfield in marc_subfield_structure { if checkbox checked { delete from marc_word where subfield= this one } } ...)
-- Paul POULAIN Consultant indépendant en logiciels libres responsable francophone de koha (SIGB libre http://www.koha-fr.org)
On Fri, May 28, 2004 at 09:27:05AM +0200, paul POULAIN wrote:
Joshua Ferraro a écrit :
Paul a écrit:
NPL had a tech meeting today focusing on the opac searching and we have reached some tentative conclusions about how to proceed. Running some test searches using marc_subfield_table we realized that a search model based on that table is inadequate for our needs. For example, a search on 'patrick o'brian' using the 'like' syntax produces no results if the database entry is stored as 'o'brian, patrick' (when author is stored in the 100a that is the format). On the other hand, a search using the current marc_word model fails for reasons we have already talked about (marc_word does not keep track of single characters, &c.). But if the marc_word table did index single charcters, a search model based on marc_word would work very well. For example, a search on 'o'brian, patrick' or 'patrick o'brian' would both return the correct records. So our idea is to re-create our marc_word table so that it indexes all characters from the tags and subfields that we want to use for searches (we don't need all of them as you pointed out; for instance, we will never use 300 for a search). So we have three basic tasks:
another idea, that would be better maybe : replace ' by _. Thus, o'brian searches o_brian, that will be stored in the DB. The only limit is that a search on brian won't be successful. Tell me if it's a problem.
Otherwise, we could add a 'index also 1 letter words', but, imho, ONLY with the 'do not index this subfield feature'. It seems to me like indexing on single-character words will lead to a more accurate search--though the marc_word table will be a bit bloated. I suppose we should also think about other punctuation marks too--do we change them all to _ or do we leave them in the database?
Everybody can give it's opinion here. Both solutions are easy to code.
1.) write a script to re-create marc_word using the parameters we choose for searching and including all characters.
2.) fix Biblio.pm so that it will include all characters when it adds records to marc_word (currently we add to our holdings using a modified version of bulkmarcimport.pl that relies on Biblio.pm)
3.) write a clean-up script to delete all the tags and subfields from marc_word that we will never use (like 300)
Does that sound like a sound plan to you Paul? Do you have any scripts that will speed up the process of re-building our marc_word table--if not we will write one ourselves. Can you make the changes to Biblio.pm that will force it to index single characters?
yep, if we decide to do it. I've no speedy script to rebuild marc_word table :-(
One final point about search results. Currently the marc searching does not pass all the variables to the template so that we can choose what values to display (for example, Lord of the Rings: The Two Towers currently displays as 'Lord of the Rings:' without the subtitle). I suggest that we setup a method of easily making marc fields available to the template so that each library can decide exactly what marc fields they want to display for the initial search results.
already planned. I'll try to commit some code on CVS ASAP. "MARC view" is ready (in OPAC). we plan to add a systempreference called 'ISBD' where the library could define it's own biblio presentation. Something like : [200a;][200b/][(100c)]
The ; means a ; is added AFTER the 200a, the ( means a ( is added BEFORE the 100c. Not exactly a ISBD view, but not too far either. Thanks Paul.
Joshua
Joshua Ferraro a écrit :
that we want to use for searches (we don't need all of them as you pointed out; for instance, we will never use 300 for a search). So we have three basic tasks:
another idea, that would be better maybe : replace ' by _. Thus, o'brian searches o_brian, that will be stored in the DB. The only limit is that a search on brian won't be successful. Tell me if it's a problem.
Otherwise, we could add a 'index also 1 letter words', but, imho, ONLY with the 'do not index this subfield feature'.
It seems to me like indexing on single-character words will lead to a more accurate search--though the marc_word table will be a bit bloated. I suppose we should also think about other punctuation marks too--do we change them all to _ or do we leave them in the database?
So... what do we decide here ? Joshua seems to prefer 1 letter indexing. Is there anyone having an opinion on this topic ? -- Paul POULAIN Consultant indépendant en logiciels libres responsable francophone de koha (SIGB libre http://www.koha-fr.org)
Paul, Joshua has convinced me that 1 letter indexing produces better results than anything else we've discussed so far. Stephen Paul POULAIN said:
Joshua Ferraro a écrit :
that we want to use for searches (we don't need all of them as you pointed out; for instance, we will never use 300 for a search). So we have three basic tasks:
another idea, that would be better maybe : replace ' by _. Thus, o'brian searches o_brian, that will be stored in the DB. The only limit is that a search on brian won't be successful. Tell me if it's a problem.
Otherwise, we could add a 'index also 1 letter words', but, imho, ONLY with the 'do not index this subfield feature'.
It seems to me like indexing on single-character words will lead to a more accurate search--though the marc_word table will be a bit bloated. I suppose we should also think about other punctuation marks too--do we change them all to _ or do we leave them in the database?
So... what do we decide here ? Joshua seems to prefer 1 letter indexing. Is there anyone having an opinion on this topic ?
-- Paul POULAIN Consultant indépendant en logiciels libres responsable francophone de koha (SIGB libre http://www.koha-fr.org)
------------------------------------------------------- This SF.Net email is sponsored by the new InstallShield X. From Windows to Linux, servers to mobile, InstallShield X is the one installation-authoring solution that does it all. Learn more and evaluate today! http://www.installshield.com/Dev2Dev/0504 _______________________________________________ Koha-devel mailing list Koha-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/koha-devel
-- Stephen Hedges Skemotah Solutions, USA www.skemotah.com -- shedges@skemotah.com
Stephen Hedges a écrit :
Paul, Joshua has convinced me that 1 letter indexing produces better results than anything else we've discussed so far.
OK, I note it unless otherwise stated. PS : I also note to add to framework management a checkbox "do not index this field". That's the main stuff... -- Paul POULAIN Consultant indépendant en logiciels libres responsable francophone de koha (SIGB libre http://www.koha-fr.org)
Bonjour, I've had a letter & invitation from the Bibliotheque nationale de France that I thought someone might be able to go to (sorry I'm not doing proper spelling- but I'm happy to fax the originals to if anyone can go). LETTER La bibliotheque nationale de france a elabore une nouvelle offre de services bibliographiques a destination des professionnels de la documenation et de metiers du livre. C'est dans ce cadre qu'elle souhaite systematiser sone dialogure avec les fournisseurs de systemes logiciels et de services aux biliotheques. La bibliotheque nationale de France a donc le plaisir de vous convier a une matinee d'information et de dailogure sur l'utilisation des produits bibliographiques, le jeudi 24 juin 2004 de 9h 30a 12h, dans le petit auditorium de la BnF Quai Francoi-Mauriac - 750013 Paris Vour trouverez ci-join l'ordre du jour de cette reunion. En attendant de vous accueillir a la BnF, recevez, Madame, Monsier, l'expression de me salutations distinguees. Christian Lupovici Directeur de l'Agence Bibliographique National. THE PROGRAMME REUNION FOURNISSEURS DES BIBLIOTHEQUES/ BNF Jeudi 24 juin 2004 Petit auditorium entree Est Bibliotheque nationale de France Quai Francios-Maurice 75013 Paris M Bibliotheque (Ligne 14 et RER C) 9h 30 - 10h Accueil 10h - 10h 30 Presentation de l'bjectif et du deroulement de la matinee. 10h 30 - 11 h La gamme de produits bibliographiques en ligne et sur commande Les protocols de tranfert propses 11 h - 12 h Discussion sur les formats, les protocols, les services. Les attentes des utilisateurs, les modes de concertation. CONTACT INFORMATION Christian Lupovici christian.lupovici@bnf.fr tel: 01 53 79 59 00 Fax: 01 53 79 50 45 I'll e-mail them to let them know I got the letter, and have passed it on. Can you let me know if you're able to go Cheers Rachel. _____________________________________________________________ Rachel Hamilton-Williams Katipo Communications WEBMISTRESS ph 021 389 128 or +64 04 934 1285 mailto:rachel@katipo.co.nz PO Box 12487, Wellington http://www.katipo.co.nz New Zealand Koha Open Source Library System http://www.koha.org
On 2004-06-05 00:02:45 +0100 Rachel Hamilton-Williams <rachel@katipo.co.nz> wrote:
I'll e-mail them to let them know I got the letter, and have passed it on. Can you let me know if you're able to go
I think I'd like to, but I've spent the conferences budget and this probably would cost me over GBP 100 (70 LHR/LGW-CDG, probably 35-40 to get to London), unless anyone has a brainwave. Who put it during midsummer anyway? Too damn hot to travel much today (over 30C here...) ;-) Paul, if you and yours can't go, shall we send respectful apologies? -- MJR/slef My Opinion Only and possibly not of any group I know. http://www.ttllp.co.uk/ for creative copyleft computing Help hack the EuroParl! http://mjr.towers.org.uk/proj/eurovote/
MJ Ray a écrit :
On 2004-06-05 00:02:45 +0100 Rachel Hamilton-Williams <rachel@katipo.co.nz> wrote:
I'll e-mail them to let them know I got the letter, and have passed it on. Can you let me know if you're able to go
I think I'd like to, but I've spent the conferences budget and this probably would cost me over GBP 100 (70 LHR/LGW-CDG, probably 35-40 to get to London), unless anyone has a brainwave. Who put it during midsummer anyway? Too damn hot to travel much today (over 30C here...) ;-)
Paul, if you and yours can't go, shall we send respectful apologies?
I already had been contacted by someone & have a paper on my desktop. Helas, I can't go to this presentation. Neither Linagora. I've asked ENSMP to see it they could send the developper they hired for a few months. He is only a few sub-station far from the meeting place (easier than for a kiwi ;-) ) -- Paul POULAIN Consultant indépendant en logiciels libres responsable francophone de koha (SIGB libre http://www.koha-fr.org)
Paul a écrit, I'm trying to put together this script to rebuild our marc_word table and I'd like to get some feedback ... I get the following error when I run the script: Use of uninitialized value in substitution (s///) at /usr/local/koha/intranet/modules//C4/Biblio.pm line 947. Use of uninitialized value in split at /usr/local/koha/intranet/modules//C4/Biblio.pm line 948. Is this a bug in Biblio.pm or am I not using this MARCaddword sub correctly? Here's my script (any suggestions?): #!/usr/bin/perl -w #----------------------------------- # Script Name: build_marc_word.pl # Script Version: 0.1.0 # Date: 2004/06/05 # Author: Joshua Ferraro [jmf at kados dot org] # Description: builds a new marc_word table that # allows for increased searching # accuracy. # Usage: build_marc_word.pl # Revision History: # 0.1.0 2004/06/05: original version; only uses # tag 100 #----------------------------------- use lib '/usr/local/koha/intranet/modules/'; use strict; use C4::Context; use C4::Biblio; my $dbh=C4::Context->dbh; #FIXME: for now tag 100 is hardcoded; eventually I plan #to derive a list of tags (and subfields?) from an outfile my $tag="100"; #get the required data from marc_subfield_table ordered by tag,subfield? not #sure if that's right ... my $query="SELECT bibid,tag,tagorder,subfieldid,subfieldorder,subfieldvalue FROM marc_subfield_table WHERE tag=? ORDER BY tag, subfieldid"; my $sth=$dbh->prepare($query); #Store the data in array @stuff for manipulation and (later) insertion my @stuff=$sth->execute($tag); #for each row ... while (my ($data)=$sth->fetchrow_array) { #define the variables to prepare for insertion my $bibid=$stuff[0]; my $tag=$stuff[1]; my $tagorder=$stuff[2]; my $subfieldid=$stuff[3]; my $subfieldorder=$stuff[4]; my $sentence=$stuff[5]; #insert the row into marc_word using Biblio.pm's MARCaddword sub MARCaddword($dbh,$bibid,$tag,$tagorder,$subfieldid,$subfieldorder,$sentence); } #that's all folks ... $dbh->disconnect(); On Fri, Jun 04, 2004 at 04:03:50PM +0200, Paul POULAIN wrote:
Stephen Hedges a écrit :
Paul, Joshua has convinced me that 1 letter indexing produces better results than anything else we've discussed so far.
OK, I note it unless otherwise stated. PS : I also note to add to framework management a checkbox "do not index this field". That's the main stuff...
-- Paul POULAIN Consultant indépendant en logiciels libres responsable francophone de koha (SIGB libre http://www.koha-fr.org)
------------------------------------------------------- This SF.Net email is sponsored by the new InstallShield X.
From Windows to Linux, servers to mobile, InstallShield X is the one installation-authoring solution that does it all. Learn more and evaluate today! http://www.installshield.com/Dev2Dev/0504
Koha-devel mailing list Koha-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/koha-devel
sorry I forgot to include the error message: Use of uninitialized value in substitution (s///) at /usr/local/koha/intranet/modules//C4/Biblio.pm line 947. Use of uninitialized value in split at /usr/local/koha/intranet/modules//C4/Biblio.pm line 948. Joshua
On 2004-05-18 03:21:33 +0100 Chris Cormack <chris@katipo.co.nz> wrote:
Then there is the rel_2_0 branch, which is where the 2.0.x releases are drawn from.
If the arch import is successful, I may stop using the 2.0.x branch. It seems unhelpful for bugfixing to have everything in different directories to the released system, but moving things in CVS is painful. More on this very soon, I hope. I have a couple of other things I need to work on, but it should not be long. -- MJR/slef My Opinion Only and possibly not of any group I know. http://mjr.towers.org.uk/ http://www.ttllp.co.uk/ for creative copyleft computing
participants (8)
-
Benedict P. Barszcz -
Chris Cormack -
Joshua Ferraro -
MJ Ray -
Paul POULAIN -
paul POULAIN
-
Rachel Hamilton-Williams -
Stephen Hedges