← Previous day | Today | Next day → | Search | Index
All times shown according to UTC.
Time | Nick | Message |
---|---|---|
12:01 | kados | hi guys |
12:01 | hdl: an alternative to zebraqueue daemon is rebuild_zebra with the -z flag | |
12:01 | 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 | 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 | hdl: I think rebuild_zebra now checks to see if it's already running | |
12:03 | hdl: and won't run if a process is running already | |
12:04 | I thought zebraqueue damon did the same | |
12:04 | hdl: are you sure you're running the very latest zebraqueue daemon | |
12:04 | hdl | this is what they had before. |
12:04 | Yes. | |
12:04 | 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 | he shuld be around in about 2 hours | |
12:05 | hdl | had zebraqueuedeamon launched every minutes or so. |
12:06 | 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 | hi fbcit | |
12:08 | 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 | save it | |
12:25 | right after | |
12:25 | edit the same biblio (Oops, I misspelled the title) | |
12:25 | save | |
12:25 | wait for a while | |
12:25 | kohazebraqueue daemon won't pardon you. | |
12:26 | it takes over 50% CPU | |
12:26 | And overflood mysql db. | |
12:39 | kados | hdl: and what is happening behind the scenes? |
12:39 | hdl: there should only be one zebraqueue entry if I'm not mistaken | |
12:40 | hdl | there are 2 recordDelete |
12:40 | And SpecialUpdate | |
12:40 | (mm 1 recordDelete and 1 specialUpdate) | |
12:41 | And it seems to be trying to do the recordDelete Before the speciaUpdate | |
12:41 | kados | why a recordDelete? |
12:42 | 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 | 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 | hdl: Adding Recent Acquisitions page | |
12:46 | hdl: and NoZebra : Commiting things only when done | |
12:46 | hdl: what should I do with these? | |
12:47 | hdl | I think that recent acquisition pages could be added. |
12:47 | It is one of our customers that asked for that. | |
12:48 | NoZebra could also be commited I think. | |
12:48 | It justs commits elements to database once rather than committing it each time. | |
12:49 | kados : recordDelete because when you edit, you 1st delete. | |
12:52 | 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 | 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 | 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 | 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 | 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 | (in the relational database0 | |
14:39 | ) | |
14:39 | so that audience example we did yesterday for example | |
14:39 | 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 | 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 | acmoore: so maybe we could add the images at that point | |
14:43 | acmoore: it's not pretty though, because we'll have to hard-code some tag/subfields in the resulting XSL | |
14:43 | or else we could come up with a new namespace or something | |
14:43 | koha.icons or something | |
14:43 | other option would be adding columns to the biblioitems table for things like format, audience, etc. | |
14:44 | 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 | acmoore: they have rules that I think I forwarded to you and Debra | |
14:45 | 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 | 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 | 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 | I have no idea what drupal does. | |
14:51 | 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 | acmoore: is it stored in the catalog record somewhere? | |
14:52 | acmoore: the workflow for how these records are added is probably important background | |
14:52 | hdl | there ought to be 2 tables |
14:52 | 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 | am i wrong ? | |
14:54 | acmoore | hdl, I think you and I are picturing the same thing. |
14:54 | hdl | problem |
14:54 | Now with Koha for 1 bib, you have 1 record (in a join) | |
14:55 | with this system, we would have to query much more. | |
14:55 | we could add picture path to authorised_values | |
14:56 | mmm... quite a dangerous change, imho... | |
14:56 | acmoore | I don't think I understand the problem you're describing. |
14:57 | 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 | oops, on the results page | |
14:58 | 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 | you have GetAuthorisedValues and GetAuthorisedValueDesc . | |
15:00 | acmoore | what's GetAuthorisedValueDesc? |
15:00 | hdl | In Biblio.pm |
15:01 | 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 | returns the has of your framework. | |
15:04 | hash | |
15:05 | (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 | 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 | acmoore: see add_biblio.pl | |
15:12 | It details getting the whole bib. | |
15:13 | Then parsing the bib with tagslib (the result of GetMarcStructure) | |
15:13 | Then getting the results. | |
15:14 | acmoore | cataloguing/addbiblio.pl? |
15:21 | OK, thanks. I think I can embrace and extend this. | |
15:21 | 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 | 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? |
← Previous day | Today | Next day → | Search | Index