Time |
S |
Nick |
Message |
12:01 |
|
kados |
hi guys |
12:01 |
|
kados |
hdl: an alternative to zebraqueue daemon is rebuild_zebra with the -z flag |
12:01 |
|
kados |
hdl: it lets you index from zebraqueue |
12:01 |
|
hdl |
would that solve the problem ? |
12:02 |
|
kados |
hdl: I hope so ... if you run it in cron every 10 minutes or something |
12:02 |
|
hdl |
:( |
12:02 |
|
hdl |
So ppl will have to wait for 10 minutes before sbeing able to search their biblios ??? |
12:03 |
|
kados |
hdl: how about 2 minutes |
12:03 |
|
kados |
hdl: I think rebuild_zebra now checks to see if it's already running |
12:03 |
|
kados |
hdl: and won't run if a process is running already |
12:04 |
|
kados |
I thought zebraqueue damon did the same |
12:04 |
|
kados |
hdl: are you sure you're running the very latest zebraqueue daemon |
12:04 |
|
hdl |
this is what they had before. |
12:04 |
|
hdl |
Yes. |
12:04 |
|
hdl |
Install from beta2. |
12:04 |
|
kados |
hdl: what who had before? |
12:05 |
|
hdl |
IPT |
12:05 |
|
kados |
maybe galen has some other ideas |
12:05 |
|
kados |
he shuld be around in about 2 hours |
12:05 |
|
hdl |
had zebraqueuedeamon launched every minutes or so. |
12:06 |
|
hdl |
But it annoyed them not to be able to search a biblio for a minute. |
12:06 |
|
kados |
yep, it's annoying, I agree |
12:06 |
|
hdl |
Many ppl here check their catalog. when the enter a biblio. |
12:06 |
|
kados |
here too |
12:07 |
|
hdl |
the thing is that ModZebra does a del and an Add but when you save, visually check then edit back. |
12:08 |
|
fbcit |
morning everyone |
12:08 |
|
hdl |
either you would delete create the record and then delete. |
12:08 |
|
hdl |
hi fbcit |
12:08 |
|
hdl |
Or you would try to delete a ghost record and cramp the system. |
12:24 |
|
kados |
hdl: I don't quite understand the use case, could you walk through it again? |
12:24 |
|
hdl |
add a new Biblio |
12:24 |
|
hdl |
save it |
12:25 |
|
hdl |
right after |
12:25 |
|
hdl |
edit the same biblio (Oops, I misspelled the title) |
12:25 |
|
hdl |
save |
12:25 |
|
hdl |
wait for a while |
12:25 |
|
hdl |
kohazebraqueue daemon won't pardon you. |
12:26 |
|
hdl |
it takes over 50% CPU |
12:26 |
|
hdl |
And overflood mysql db. |
12:39 |
|
kados |
hdl: and what is happening behind the scenes? |
12:39 |
|
kados |
hdl: there should only be one zebraqueue entry if I'm not mistaken |
12:40 |
|
hdl |
there are 2 recordDelete |
12:40 |
|
hdl |
And SpecialUpdate |
12:40 |
|
hdl |
(mm 1 recordDelete and 1 specialUpdate) |
12:41 |
|
hdl |
And it seems to be trying to do the recordDelete Before the speciaUpdate |
12:41 |
|
kados |
why a recordDelete? |
12:42 |
|
kados |
and why two? |
12:42 |
|
nengard |
question - for OPACUserCSS - how is the data supposed to be formatted? url? css? <style> tags? |
12:42 |
|
kados |
nengard: it's CSS |
12:43 |
|
kados |
nengard: no tags, just straight css, like in the example I gave |
12:43 |
|
nengard |
k |
12:46 |
|
kados |
hdl: I have two patches from you that I'm not sure about |
12:46 |
|
kados |
hdl: Adding Recent Acquisitions page |
12:46 |
|
kados |
hdl: and NoZebra : Commiting things only when done |
12:46 |
|
kados |
hdl: what should I do with these? |
12:47 |
|
hdl |
I think that recent acquisition pages could be added. |
12:47 |
|
hdl |
It is one of our customers that asked for that. |
12:48 |
|
hdl |
NoZebra could also be commited I think. |
12:48 |
|
hdl |
It justs commits elements to database once rather than committing it each time. |
12:49 |
|
hdl |
kados : recordDelete because when you edit, you 1st delete. |
12:52 |
|
hdl |
So you end up in zebraqueue with 1 recordDelete and 1 specialUpdate (because when you edit things, you index the record only once... no checking done when you delete... maybe if one would edit a biblio and then delete it it would be even worse.) |
12:54 |
|
hdl |
Not worse but same problem |
12:54 |
|
kados |
edit should be specialUpdate, not sure why it does recordDelete |
12:56 |
|
hdl |
because ModBiblio does |
12:56 |
|
hdl |
Del and Add. |
14:12 |
|
nengard |
manual question - will biblios automatically be integrated into koha 3? or will it require additional installation steps? I'm asking so I know if I have to write a how to integrate step in the manual |
14:35 |
|
acmoore |
is there a function that will fetch the values of arbitrary authorized values for an item (ie, ones that aren't tied to database fields)? |
14:36 |
|
kados |
acmoore: GetAuthorisedValues in Koha.pm I think |
14:37 |
|
acmoore |
I thought so, too, but that doesn't seem to do what I thought it did. |
14:37 |
|
acmoore |
I think that finds which authorized values exist in a category. |
14:38 |
|
kados |
ahh, you may be right |
14:38 |
|
acmoore |
but, it doesn't seem to know anything about items. I thought that an item may have an actual value for a possible authorized value. |
14:38 |
|
acmoore |
these words are hard to use. |
14:39 |
|
kados |
acmoore: displaying authorized values in the search results pages is going to be especially hard ... extra hard if there is no koha2marc linking the marc field to a koha field |
14:39 |
|
kados |
(in the relational database0 |
14:39 |
|
kados |
) |
14:39 |
|
kados |
so that audience example we did yesterday for example |
14:39 |
|
kados |
there's no easy way to display the values for records that have a value there |
14:39 |
|
acmoore |
yep, I'm with you. the ones with actual database fields are much easier. |
14:40 |
|
kados |
for items it's easier since all of the item fields are linked to database fields and items table is authoritative for them |
14:42 |
|
kados |
acmoore: the XSl work I did does a preparse of every MARCXML record as it comes back from the index, and substitutes authorized value descriptions for codes |
14:42 |
|
kados |
acmoore: so maybe we could add the images at that point |
14:43 |
|
kados |
acmoore: it's not pretty though, because we'll have to hard-code some tag/subfields in the resulting XSL |
14:43 |
|
kados |
or else we could come up with a new namespace or something |
14:43 |
|
kados |
koha.icons or something |
14:43 |
|
kados |
other option would be adding columns to the biblioitems table for things like format, audience, etc. |
14:44 |
|
kados |
acmoore: another thing I discovered |
14:44 |
|
acmoore |
or adding a lookup table for them, so you don't have to add a column for each one. |
14:44 |
|
kados |
acmoore: is that folks like HCL actually use the call number to determin which items show up at the bib level |
14:45 |
|
kados |
acmoore: they have rules that I think I forwarded to you and Debra |
14:45 |
|
kados |
acmoore: a lookup table for what now? |
14:46 |
|
acmoore |
when you say that another option would be adding collumns to the biblioitems table, do you mean adding a column for whatever arbitrary authorized value that an installation may define? |
14:46 |
|
acmoore |
because, you can do that with another database table, instead of adding columns each time. |
14:47 |
|
kados |
can you expand on that for me? |
14:48 |
|
kados |
I'm just trying to figure out how the user would indicate that a given bib should be linked to, say 'JUV' audience |
14:49 |
|
acmoore |
let there be a table with biblionumber and authroised_value_id (and probably a few other columns). Then, if biblionumber "green eggs and ham" has a "Juvenile" set for "audience", you can make an entry in that table, instead of having a new column in the biblioitems table for "audience". |
14:50 |
|
hdl |
acmoore: would it be quite like it is done for users in drupal ? link to a bib in a table and custom names ? |
14:50 |
|
acmoore |
so, if I were to add a new authorised value for "smell", I don't add a biblioitems.smell column, I start adding rows to this table like "item #123 has value 'flowery' for authorised_value 'smell'" |
14:50 |
|
acmoore |
I have no idea what drupal does. |
14:51 |
|
acmoore |
but surely we have one of these already in our database. It's not a far out concept. I'll look. |
14:51 |
|
hdl |
(you can add custom fields to user data) |
14:51 |
|
kados |
acmoore: yes, I get how it works on the database end of things, but how about for the user ... |
14:51 |
|
kados |
acmoore: is it stored in the catalog record somewhere? |
14:52 |
|
kados |
acmoore: the workflow for how these records are added is probably important background |
14:52 |
|
hdl |
there ought to be 2 tables |
14:52 |
|
hdl |
1 describing the added fields |
14:52 |
|
kados |
acmoore: typically a library will create a MARC record for their bib data, and import it into Koha ... or create it within Koha's MARC editor |
14:52 |
|
hdl |
1 containing the values... |
14:52 |
|
hdl |
am i wrong ? |
14:54 |
|
acmoore |
hdl, I think you and I are picturing the same thing. |
14:54 |
|
hdl |
problem |
14:54 |
|
hdl |
Now with Koha for 1 bib, you have 1 record (in a join) |
14:55 |
|
hdl |
with this system, we would have to query much more. |
14:55 |
|
hdl |
we could add picture path to authorised_values |
14:56 |
|
hdl |
mmm... quite a dangerous change, imho... |
14:56 |
|
acmoore |
I don't think I understand the problem you're describing. |
14:57 |
|
acmoore |
I intend to add a path to an image to authorised_values. will that pose a problem? |
14:57 |
|
kados |
hdl: acmoore just added a picture path to authorized values |
14:57 |
|
hdl |
:P |
14:57 |
|
kados |
hdl: but we're trying to figure out how to display authorized values on the bib page |
14:57 |
|
kados |
oops, on the results page |
14:58 |
|
kados |
for records that have authorized values linked to the MARC, but that don't exist in the koha tables |
14:58 |
|
hdl |
No would not. |
14:58 |
|
kados |
it's complicated |
14:58 |
|
hdl |
Why ? |
14:59 |
|
hdl |
you have GetAuthorisedValues and GetAuthorisedValueDesc . |
15:00 |
|
acmoore |
what's GetAuthorisedValueDesc? |
15:00 |
|
hdl |
In Biblio.pm |
15:01 |
|
hdl |
In gets the lib value of an authorised value. |
15:01 |
|
kados |
hdl: suppose we create a new authorized value called 'audience' and we link it to 942 $l (which is not used), and 942 $l is not linked to the biblioitems or biblio tables ... how do we get the authorized value to display in the results page? |
15:01 |
|
acmoore |
aaah. thta's what I was looking for. |
15:02 |
|
hdl |
you just have to use the tagslib table |
15:02 |
|
acmoore |
hdl, well, not quite. So that tells me about a particular autorised_value. But, it doesn't tell me what value is set for that authorised_value for a particular biblioitem |
15:02 |
|
hdl |
and parse the record. |
15:03 |
|
acmoore |
what table was that? |
15:04 |
|
hdl |
&GetMarcStructure |
15:04 |
|
hdl |
returns the has of your framework. |
15:04 |
|
hdl |
hash |
15:05 |
|
hdl |
(Maybe it would be better if we cached it... But for now, it is not cached.) |
15:07 |
|
gmcharlt_ |
hdl: it is cached, partially, at least as far as batch jobs are concerned |
15:07 |
|
acmoore |
I'll have to look at that. It's possible that's going to do what I'm looking for. |
15:08 |
|
hdl |
gmcharlt: but we are talking of display, not batch jobs |
15:09 |
|
gmcharlt |
hdl: true; my point it is (assuming it's working properly) the DB lookup from marc_subfield_structure and marc_tag_structure is done only once during a CGI script's lifetime |
15:10 |
|
gmcharlt |
but yeah, that's a digression |
15:10 |
|
hdl |
gmcharlt++ |
15:11 |
|
acmoore |
so, the marc_subfield_structure table does tell me about the authorised values, but how do I know what authorised values are set for this biblioitem I'm looking up? |
15:12 |
|
hdl |
But It would be better if it could be cached for a session lifetime... If structure is not edited. |
15:12 |
|
hdl |
acmoore: see add_biblio.pl |
15:12 |
|
hdl |
It details getting the whole bib. |
15:13 |
|
hdl |
Then parsing the bib with tagslib (the result of GetMarcStructure) |
15:13 |
|
hdl |
Then getting the results. |
15:14 |
|
acmoore |
cataloguing/addbiblio.pl? |
15:21 |
|
acmoore |
OK, thanks. I think I can embrace and extend this. |
15:21 |
|
acmoore |
just out of curiousity, is this thing parsing the biblioitems.marcxml field? |
15:22 |
|
gmcharlt |
acmoore: it should be |
15:22 |
|
acmoore |
holy cow. |
15:22 |
|
gmcharlt |
? |
15:53 |
|
hdl |
gmcharlt acmoore : it doesnot at the moment. |
15:53 |
|
hdl |
It takes a MARC::Record |
15:54 |
|
gmcharlt |
hdl: right, but assuming that the record is being read from the database, either bibiloitems.marcxml or biblioitems.marc must be parsed |
15:55 |
|
hdl |
marcxml is parsed. But only after MARC::File::XML parsed it. |
17:32 |
|
nengard |
after I claim a serial shouldn't it's status be updated to Claimed? or do I have to do this manually? |