| Time |
Nick |
Message |
| 02:00 |
|
zerick joined #evergreen |
| 04:39 |
|
BigRig joined #evergreen |
| 04:39 |
|
Callender joined #evergreen |
| 04:39 |
|
tfaile joined #evergreen |
| 04:46 |
|
BigRig joined #evergreen |
| 04:46 |
|
Callender joined #evergreen |
| 06:19 |
|
kmlussier joined #evergreen |
| 06:47 |
|
timf joined #evergreen |
| 07:04 |
|
kmlussier left #evergreen |
| 07:04 |
|
kmlussier joined #evergreen |
| 07:42 |
|
jboyer-isl joined #evergreen |
| 08:11 |
|
akilsdonk joined #evergreen |
| 08:15 |
|
remingtron joined #evergreen |
| 08:28 |
|
rjackson-isl joined #evergreen |
| 08:31 |
kmlussier |
hmmm |
| 08:32 |
kmlussier |
I'm looking at two 2.6ish catalogs (MVLC and Bibliomation). If I'm on the advanced search tab, select the group format and editions options, and search two fields (title/author), I am consistently getting internal server errors. |
| 08:33 |
kmlussier |
Has anyone else had trouble with these group format and edition searches? |
| 08:33 |
|
collum joined #evergreen |
| 08:34 |
|
Shae joined #evergreen |
| 08:35 |
bshum |
I haven't tried combining fields. Only used keyword to test. Sigh. |
| 08:36 |
csharp |
well, that should at least be obvious in the osrferror.log |
| 08:37 |
bshum |
One side thought is whether we should be adding the new qtype selector choices on that advanced search page too |
| 08:37 |
bshum |
Unrelated |
| 08:37 |
bshum |
Just musing |
| 08:40 |
|
mmorgan joined #evergreen |
| 08:41 |
|
mrpeters joined #evergreen |
| 08:45 |
|
ericar joined #evergreen |
| 08:46 |
bshum |
Can't call method "source_records" on an undefined value at /usr/local/share/perl/5.14.2/OpenILS/Application/Storage/Publisher/action.pm line 1306. |
| 08:46 |
bshum |
Among other things |
| 08:46 |
kmlussier |
bshum: Should I file a bug report then? |
| 08:47 |
bshum |
Seems like it would be appropriate |
| 08:47 |
bshum |
You can also create the problem by launching the search without it |
| 08:48 |
bshum |
And then clicking the group formats/editions toggle too |
| 08:48 |
kmlussier |
Fun! |
| 08:49 |
csharp |
that's not a new 2.6 feature is it? |
| 08:49 |
kmlussier |
Yes, it is |
| 08:50 |
bshum |
Oh it is |
| 08:50 |
csharp |
was it a JSPAC feature? |
| 08:50 |
bshum |
It used to be yes. |
| 08:50 |
csharp |
okay, that's what I'm thinking about |
| 08:50 |
bshum |
So, author search by itself, no problem |
| 08:50 |
bshum |
Title search by itself, no problem |
| 08:50 |
bshum |
Any combined search? Problem |
| 08:51 |
bshum |
Any time it's an && search |
| 08:51 |
bshum |
Doesn't matter the combination, it seems. Keyword + author, keyword + title, whatnot |
| 08:51 |
* bshum |
is tempted to remove the toggle until this is fixed... |
| 08:52 |
bshum |
*big sigh* |
| 08:53 |
csharp |
yay TT2 for making that kind of thing easy! |
| 08:53 |
bshum |
Indeed! |
| 08:54 |
bshum |
There's a config.tt2 option for quick disablement it seems |
| 08:54 |
bshum |
metarecords.disabled = 1 |
| 08:54 |
csharp |
rock and roll |
| 08:54 |
dbwells |
We upgraded to 2.6 over the weekend in production and can confirm the behavior. |
| 08:54 |
bshum |
And poof, gone |
| 08:55 |
csharp |
dbwells: congrats on the hopefully smooth upgrade! |
| 08:55 |
dbwells |
Also, it isn't tied to advanced search, but to any use of and operator (e.g. '&&') in conjunction with the 'Group Formats'. |
| 08:56 |
dbwells |
That should say 'an operator'. '||' breaks, too. |
| 08:56 |
dbwells |
csharp: Thanks, it was pretty smooth. |
| 08:56 |
kmlussier |
https://bugs.launchpad.net/evergreen/+bug/1323639 |
| 08:56 |
pinesol_green |
Launchpad bug 1323639 in Evergreen "Multi-field metarecord searching causes internal server error" (affected: 1, heat: 6) [Medium,Confirmed] |
| 08:56 |
csharp |
awesome |
| 08:58 |
bshum |
dbwells: Yeah I hadn't gotten to the OR operator yet, but suspected :\ |
| 08:59 |
dbwells |
It doesn't even need to be two fields. Just putting 'one && two' in the basic search box will trigger the bug when adding 'Group formats'. |
| 09:00 |
bshum |
Yeesh |
| 09:00 |
bshum |
Nothing quite like live testing bugs in production :) |
| 09:00 |
kmlussier |
It's too bad I didn't start preparing for my new features demo before you all upgraded. :) |
| 09:02 |
dbwells |
@blame kmlussier |
| 09:02 |
pinesol_green |
dbwells: kmlussier is why we can never have nice things! |
| 09:02 |
dbwells |
;) |
| 09:03 |
kmlussier |
My kids certainly with agree with that statement. ;) |
| 09:03 |
kmlussier |
s/with/would |
| 09:03 |
bshum |
Ugh, errors in offline session creating |
| 09:04 |
bshum |
Today should be fun! |
| 09:04 |
* bshum |
is getting details |
| 09:05 |
|
jwoodard joined #evergreen |
| 09:07 |
bshum |
Oh fun |
| 09:08 |
|
Dyrcona joined #evergreen |
| 09:08 |
bshum |
Going to the console gives us an "Error retrieving offline sessions" skull/crossbones |
| 09:08 |
bshum |
That's pretty awesome... |
| 09:08 |
kmlussier |
bshum: I think your definition of awesome is a little different than mine. |
| 09:08 |
bshum |
*Everything* is awesome. |
| 09:09 |
Dyrcona |
I think he means awesome in the sense of inspiring awe, awe in the form of fear of the unknown. |
| 09:09 |
Dyrcona |
I thought "Everything is broken." |
| 09:10 |
Dyrcona |
It is a Tuesday after a Monday holiday, so I'll try to stay optimistic for 5 more minutes! |
| 09:13 |
* kmlussier |
will strive for optimism in the later part of the week after our local conference is done. |
| 09:16 |
|
akilsdonk_ joined #evergreen |
| 09:17 |
Dyrcona |
"Awesomer, and awesomer," said bshum. ;) |
| 09:17 |
bshum |
Sounds about right |
| 09:18 |
eeevil |
kmlussier / bshum / dbwells: https://bugs.launchpad.net/evergreen/+bug/1310751 addresses metarecord searching |
| 09:18 |
pinesol_green |
Launchpad bug 1310751 in Evergreen "certain queries can break Group by Formats and Editions feature" (affected: 1, heat: 6) [Undecided,New] |
| 09:18 |
* eeevil |
targets 2.6.1 |
| 09:19 |
eeevil |
(working in production, btw) |
| 09:19 |
kmlussier |
eeevil: Sorry, I did a quick LP search, but missed that one. |
| 09:21 |
eeevil |
kmlussier: I'll mark the new one as a duplicate |
| 09:21 |
kmlussier |
eeevil: Beat you to it. |
| 09:21 |
eeevil |
oh, cool. thanks |
| 09:22 |
kmlussier |
Is bug 1254918 a new feature or backportable bug fix? |
| 09:22 |
pinesol_green |
Launchpad bug 1254918 in Evergreen "rendering the fund drop-down in the line batch update controls can be slow" (affected: 6, heat: 30) [Medium,Confirmed] https://launchpad.net/bugs/1254918 |
| 09:24 |
eeevil |
kmlussier: the front-end stuff could probably be applied as a patch. I wouldn't suggest the pcrud work for backporting, though. its effect in broader, but deeper |
| 09:24 |
kmlussier |
eeevil: OK, thanks! |
| 09:29 |
csharp |
@quote add < bshum> *Everything* is awesome. |
| 09:29 |
pinesol_green |
csharp: The operation succeeded. Quote #85 added. |
| 09:30 |
|
tspindler joined #evergreen |
| 09:31 |
bshum |
GAH |
| 09:31 |
bshum |
I think I figured it out |
| 09:32 |
bshum |
offline.pl hasn't been updated with our new DB server address |
| 09:33 |
Dyrcona |
bshum++ |
| 09:33 |
bshum |
And that's actually offline-config.pl |
| 09:33 |
bshum |
But anywho |
| 09:36 |
dbwells |
eeevil: for the metarecord bug fix, the code had the comment "we add these to the end of the query (last-wins) because ... the user should not be able to cause a change in, say, superpage size by adjusting the query string". Has that problem gone away, or are we just designating it as a lower concern right now? |
| 09:37 |
|
kbeswick joined #evergreen |
| 09:38 |
eeevil |
dbwells: I'll doublecheck, but I believe it became a lie at some point. sec |
| 09:44 |
eeevil |
dbwells: for modifiers, last-wins is still true. The floating subquery syntax can address that, though, by mechanically putting that at the end (see bug 1281280). for filters, it's no longer true, and filters are merged |
| 09:44 |
pinesol_green |
Launchpad bug 1281280 in Evergreen "Optimize adjacent same-boolean-op searches" (affected: 1, heat: 6) [Low,New] https://launchpad.net/bugs/1281280 |
| 09:44 |
eeevil |
er, no, don't see that |
| 09:44 |
eeevil |
just see the comment in 1310751 ;) |
| 09:45 |
eeevil |
dbwells: however, 1281280 addresses the recursion issue from 2.5 (makes chained ||s (or &&s) fast and safe) |
| 09:49 |
|
yboston joined #evergreen |
| 10:13 |
|
remingtron joined #evergreen |
| 10:22 |
dbwells |
eeevil: I am still getting 500 errors in at least one case when applying the branch in 1310751. I have commented there. I don't have time to troubleshoot, and in fact will be in meetings much of the day today, so sorry to be unhelpful. If you get a chance, see if you think the issue is something obvious (to you). |
| 10:22 |
Dyrcona |
Now that MVF is in, is there a better way to get a bib record's item_type in a JSON query than going through metabib.record_attr? |
| 10:25 |
eeevil |
dbwells: OTTOMH, a restart of storage (and maybe waiting for search cache clearing) is all that should be needed. phasefx, can you comment? IIRC, you applied this with success... |
| 10:25 |
eeevil |
Dyrcona: programatic, or hand-constructed (one-off)? |
| 10:26 |
Dyrcona |
eeevil: It's hand-constructed but will run repeatedly. |
| 10:26 |
eeevil |
Dyrcona: well, in either case, yes (with a small pre-query to grab the item_type id that you want to look for) |
| 10:27 |
pastebot |
"Dyrcona" at 64.57.241.14 pasted "Circulation JSON Query" (13 lines) at http://paste.evergreen-ils.org/42 |
| 10:28 |
dbwells |
eeevil: To be clear, I have the fix in place, and it works fine for the generated advanced queries which included outer parens (e.g. '(one && two)'), but if you remove the parens, the error is back. |
| 10:28 |
Dyrcona |
Basically, the above, so I kinda fibbed about the JSON query, but it gets turned into one. |
| 10:29 |
* dbwells |
heads off to meeting #1 |
| 10:29 |
eeevil |
dbwells: ah, thanks |
| 10:30 |
eeevil |
Dyrcona: is the goal to get back the value of the item_type attr, a la the bre->attrs fleshing? |
| 10:31 |
pastebot |
"gsams" at 64.57.241.14 pasted "Getting an odd error when trying to clear holds shelf" (20 lines) at http://paste.evergreen-ils.org/43 |
| 10:31 |
Dyrcona |
eeevil: I prefetch ccvm for item_type and make a hash out of it, then use the item_type attr as a key lookup on the hash. |
| 10:32 |
gsams |
One of my libraries is getting this error when trying to clear their holds shelf, I noticed an open issue for this here: |
| 10:32 |
gsams |
https://bugs.launchpad.net/evergreen/+bug/1167979 |
| 10:32 |
pinesol_green |
Launchpad bug 1167979 in Evergreen "Circulation > Clear Shelf-Expired Holds fails " (affected: 5, heat: 24) [Medium,Confirmed] |
| 10:33 |
gsams |
is there a work around I might be able to implement? I imagine there isn't or it might not be a bug anymore... |
| 10:37 |
eeevil |
Dyrcona: you might want to the bib ids in a secondary search of mraf instead of the in-line fleshing in cstore call you pasted, ( id => \@bibs, attr => 'item_type' ), as it may be faster. otherwise, it's mostly the same as before MVF for reading back the values |
| 10:38 |
Dyrcona |
eeevil: I'll try that and see what I get. Thanks! |
| 10:39 |
eeevil |
that view also gets you the M in MVF, but that doesn't apply to item_type (ldr/06) |
| 10:47 |
Dyrcona |
eeevil: Thanks for the suggestions. Given the structure of my code, it looks more efficient to continue what I am doing. |
| 10:47 |
Dyrcona |
I'm using a streaming result on the circulation query, so I'd need to build up the list of bib ids and then run your query after the results have all been processed. |
| 10:51 |
|
ericar joined #evergreen |
| 10:56 |
|
remingtron joined #evergreen |
| 11:02 |
Dyrcona |
eeevil++ tsbere++ |
| 11:03 |
Dyrcona |
'Cause tsbere suggested another way of doing what I'm doing that will use mraf, and I can get more meaningful information than just the item_type. |
| 11:04 |
Dyrcona |
One additional question: Why is there no link to mraf from bre in the IDL? Is that an oversight, or is that on purpose? |
| 11:06 |
eeevil |
Dyrcona: mildly on purpose, but adding wouldn't hurt beyond adding an often-empty field to the bre object. replacing bre->mra might make existing code mad, though (differing assumptions about data structure and constraints) |
| 11:07 |
Dyrcona |
eeevil: Right. I wasn't thinking of replacing the existing link, just adding a new one, maybe called multi_attrs... I think I'll switch to a JSON query and join out right for now. |
| 11:12 |
|
ldw joined #evergreen |
| 11:17 |
eeevil |
cool |
| 11:41 |
|
ldw joined #evergreen |
| 11:47 |
|
kmlussier joined #evergreen |
| 12:01 |
DPearl |
I'm getting "Can't use an undefined value as an ARRAY reference at /usr/local/share/perl/5.10.1/OpenILS/Utils/Configure.pm line 238." from the Updating Search Groups steps of autoconf. Is this innocuous? |
| 12:03 |
DPearl |
s/autoconf/autogen |
| 12:06 |
Dyrcona |
DPearl: Probably not if it appears in the console. |
| 12:14 |
|
PSM joined #evergreen |
| 12:15 |
|
jihpringle joined #evergreen |
| 12:19 |
PSM |
hi, my staff client is still having some difficulty to connect to the database, it's giving me error event 2002: database query failed after I reinstalled evergreen server. I sent an e-mail yesterday with all the details to open-ils I would be grateful if you can help me solve this problem |
| 12:29 |
Dyrcona |
PSM: Are you still trying to enter records directly via acquisitions? |
| 12:30 |
PSM |
Dyrcona, I tried Cataloging, then new marc record, but I am unable to type in the fields where I am supposed to |
| 12:31 |
PSM |
I am glad you are here, so we can follow up where we started, thanks so much for responding |
| 12:31 |
Dyrcona |
PSM: Acquisitions doesn't work for what you want to do. It is meant to be used to create orders that get sent to a vendor, and then the vendor sends records. |
| 12:31 |
PSM |
ok |
| 12:32 |
DPearl |
Dyrcona: My problem is fixed. Seems there was a runaway opensrf C process that was grabbing most CPU, likely causing timeouts. Restarted all osrf and problem fixed. |
| 12:32 |
Dyrcona |
DPearl: Good to hear. |
| 12:34 |
Dyrcona |
PSM: Your best best is to try importing records via Z39.50. You should be able to make new records via Create New Record from the Cataloging menu, but you really need to know what you're doing there. |
| 12:34 |
eeevil |
apropos of nothing: OMG FILTER! (or, "die CASE, die!") http://www.databasesoup.com/2014/05/94-theme-contest-analyzed-by-94.html |
| 12:37 |
PSM |
Dyrcona: I never did that before, but I can try. btw in the e-mail I sent yesterday I attached the configuration files I have hoping they can give some light, would you be able to take a look at them see if I made any mistakes in the setup |
| 12:37 |
Dyrcona |
PSM: Your problem, from what you pasted before, has nothing to do with your overall configuration. |
| 12:38 |
Dyrcona |
PSM: You simply are not using acquisitions correctly. You have to setup an order or invoice first. The error you get happens because there is no line item entry in the database for your new record, more or less. |
| 12:39 |
Dyrcona |
eeevil: The code isn't that much different between the two, though FILTER is neater. |
| 12:40 |
Dyrcona |
I find it more interesting who won, rather than how it was determined. :) |
| 12:40 |
eeevil |
Dyrcona: and easier to turn into json_query (or cstore) syntax! :) |
| 12:41 |
Dyrcona |
eeevil: Ah yes. Didn't think of that.... |
| 12:41 |
eeevil |
simple addition to the aggregate syntax there now |
| 12:41 |
* eeevil |
leaves the future and returns to the now |
| 12:53 |
csharp |
okay - Acq question... is "fiscal year" able to be customized so that (for example) it starts on July 1 of year 1 and ends on June 30 of year 2? |
| 12:54 |
csharp |
or is it just calendar year? |
| 12:54 |
kmlussier |
csharp: Our fiscal year is July to June. |
| 12:55 |
csharp |
kmlussier: do you know where that is defined in EG? |
| 12:55 |
csharp |
(we're on 2.5.1, if that matters ;-)) |
| 12:55 |
kmlussier |
You can set a default fiscal year in that dabase somewher, but it only helps to set a default in the MARC upload form. |
| 12:55 |
kmlussier |
There are still a lot of interfaces that default to the current calendar year. Mainly in the admin area of acq. |
| 12:56 |
kmlussier |
Correction, MARC order record upload form. |
| 12:57 |
csharp |
okay, so there's not a front-end way to define start/end of FY? I do see acq.fiscal_year now. |
| 12:58 |
kmlussier |
csharp: No, nothing in the front end to define what the fiscal year is. For example, we have some new libs in MVLC who will start using acq on July 1. They're just setting up funding sources and funds with 2015 set as the fiscal year. |
| 12:59 |
kmlussier |
And then when it's time to do the fiscal year end in July of 2015, the system will automatically propogate those funds to 2016. |
| 12:59 |
kmlussier |
Correction: we aren't associating the fiscal year with a funding source. I'm typing faster than I'm thinking. |
| 13:00 |
* csharp |
just found senator's comment https://bugs.launchpad.net/evergreen/+bug/1031927/comments/3 |
| 13:00 |
pinesol_green |
Launchpad bug 1031927 in Evergreen master "MARC Order Loader uses 2012 funds instead of 2013 funds" (affected: 2, heat: 10) [Undecided,Fix released] |
| 13:09 |
csharp |
okay - so that looks like a humongous rabbit hole that I'll just leave alone for now |
| 13:18 |
|
tspindler left #evergreen |
| 13:25 |
|
rfrasur joined #evergreen |
| 13:33 |
rfrasur |
jboyer-isl: Is there something up with the catalog there? or do we need to reboot our stuff here? |
| 13:34 |
jboyer-isl |
We saw your email and have checked around, as far as we can tell things are running pretty smooth here. You might see if anyone on your publics are having a video marathon? |
| 13:34 |
* rfrasur |
checks for video marathons |
| 13:34 |
csharp |
@marc 962 |
| 13:34 |
pinesol_green |
csharp: unknown tag 962 |
| 13:35 |
bshum |
9xx tags are generally local use I think csharp. |
| 13:36 |
rfrasur |
ugh, it's definitely us. |
| 13:37 |
jboyer-isl |
Bummer. Unless that means you fixed it, in which case, yay! |
| 13:37 |
rfrasur |
No. I can't get logged in to the stupid device. |
| 13:37 |
rfrasur |
Which I think might be causing the problem. |
| 13:37 |
jboyer-isl |
Oh. Definitely bummer, then. |
| 13:38 |
jboyer-isl |
Bluesocket, or what kind of device? |
| 13:38 |
rfrasur |
meraki - nearly brand new. But you don't log directly into the device. You go through a web interface. |
| 13:40 |
jboyer-isl |
Do you have any wired connections with issuses or just wireless? |
| 13:40 |
rfrasur |
Just wireless as far as I can tell. But we only have 3 wired computers and two are public. |
| 13:41 |
jboyer-isl |
Ow. I won't keep dividing your attention since I don't have any experience with them, but good luck! |
| 13:41 |
rfrasur |
We have other devices...oh, it doesn't matter. I can't do anything about it. I guess I can still see traffic through the access points as well. |
| 13:45 |
|
tspindler joined #evergreen |
| 13:45 |
rfrasur |
I dunno. It seems to be working now (but not the device UI) |
| 13:59 |
rfrasur |
jboyer-isl: thanks :) |
| 14:00 |
jboyer-isl |
Glad to hear it worked out, even if all I could offer was moral support. |
| 14:04 |
|
zerick2 joined #evergreen |
| 14:19 |
gsams |
I've setup an automated SQL query for one of our libraries that pulls financial transactions from the previous day. They noticed that the report repeats amounts from Lost Materials under both Lost Materials Processing Fee and Overdue Materials |
| 14:21 |
gsams |
so the amount appears to be present in triplicate even though it was only processed once. |
| 14:27 |
gsams |
I suppose my question is, is there a reasonable way to avoid tripling those transactions in the query, and only showing Lost Materials without the Overdue or Processing Fee? |
| 14:28 |
bshum |
gsams: I would imagine we'd need to see the query to begin trying to answer how you came to a report like that. |
| 14:29 |
gsams |
ah! I forgot to hit paste! |
| 14:29 |
pastebot |
"gsams" at 64.57.241.14 pasted "Daily Financial SQL Query" (53 lines) at http://paste.evergreen-ils.org/46 |
| 14:29 |
gsams |
I took the SQL built by a report and modified it to fit their needs a bit. |
| 14:30 |
gsams |
hopefully it is reasonably readable |
| 14:43 |
jboyer-isl |
gsams: The issue is that there are multiple Billing Type entries for the same transaction. However many Overdue billings it takes to hit your limit, then the Lost billings get added to the same billable transaction. |
| 14:44 |
jboyer-isl |
I use max(billing_type_id) (or something similar, don't remember the field name) for similar reports here. |
| 14:45 |
jboyer-isl |
I don't have a quick suggestion for fixing your current query though, there's a lot going on there. |
| 14:45 |
tsbere |
that is the kind of thing where I would ask "what is your goal?" and start over. >_> |
| 14:46 |
gsams |
well that's a bummer |
| 14:47 |
gsams |
Their goal is pretty much exactly what this report was built for, it just has this one issue |
| 14:47 |
gsams |
they needed financial data for the previous day displayed by payment type, time, amount, billing type, staff id, and patron first and last |
| 14:48 |
gsams |
with a total on the bottom |
| 14:48 |
gsams |
even though the report includes forgiven fees. |
| 14:49 |
gsams |
jboyer-isl: Thanks for taking a look at it in any case, I appreciate it! |
| 14:49 |
tsbere |
gsams: I think the problem is that the information they want, and how they want it, isn't possible to determine. |
| 14:50 |
tsbere |
gsams: Using a string or array aggregate function (maybe with a distinct clause) to list the full set of billing types on the transaction could help reduce the number of rows you have to deal with, though |
| 14:53 |
gsams |
tsbere: thanks for the suggestion, I think I might be able to figure something up for this. |
| 14:55 |
|
_bott_ left #evergreen |
| 14:55 |
|
_bott_ joined #evergreen |
| 14:55 |
|
_bott_ left #evergreen |
| 14:57 |
Dyrcona |
I have another question about JSON queries. |
| 14:57 |
Dyrcona |
Can I use a function in a join criteria. |
| 14:59 |
bshum |
Doh |
| 14:59 |
bshum |
http://markmail.org/message/oyipnq7ape5ojrpj |
| 14:59 |
bshum |
We don't have svn anymore |
| 14:59 |
bshum |
So I can't find out what the fix in the thread was :) |
| 14:59 |
bshum |
But I got an error almost like the original poster did... |
| 15:00 |
bshum |
invalid date format, sigh |
| 15:00 |
Dyrcona |
Seems odd that something that old would come back on you, though. |
| 15:01 |
Dyrcona |
It's the extra 00 on the end of the timezone information. |
| 15:01 |
Dyrcona |
It's valid, but something doesn't like it. |
| 15:01 |
eeevil |
Dyrcona: depends how you want to use it. as a transform on a join column? yes (IIRC) ... but I'm not sure that's useful. or do you mean join to the output of a function? I don't think so (not recalling a syntax for that). however, you can use functions in subqueries in the WHERE clause |
| 15:02 |
bshum |
Dyrcona: Hmm, maybe this is weird PG 9.3 stuff biting me. Or some other missed package for our DB server? |
| 15:03 |
Dyrcona |
eeevil: I want to turn "on mravl.list # ccvm.id::INTEGER" into something like {"mravl" : {"ccvm" : { idx(mravl.list, ccvm.i)} |
| 15:03 |
berick |
bshum: not sure if it's related, but fyi https://bugs.launchpad.net/evergreen/+bug/1322303 (not really limited to offline) |
| 15:03 |
pinesol_green |
Launchpad bug 1322303 in Evergreen 2.6 "Offline checkin backdate parsing error" (affected: 3, heat: 18) [Undecided,New] |
| 15:04 |
Dyrcona |
oop missed a d, in ccvm.id, but you get it. |
| 15:04 |
bshum |
berick: Yeah I saw some of those in our offline log this morning as well. |
| 15:04 |
eeevil |
Dyrcona: you want "contains", right? |
| 15:04 |
Dyrcona |
Maybe I should do it in the where clause, rather than in the join? |
| 15:04 |
bshum |
Backdating in general then if I read the git commit right? |
| 15:04 |
Dyrcona |
Yeah, contains. |
| 15:04 |
berick |
bshum: yeah |
| 15:05 |
berick |
bshum: though, I've only seen it w/ offline (presumably it presents the dates differently) |
| 15:05 |
bshum |
berick: Yeah, the error noted in the bug is similar to what I saw today |
| 15:05 |
bshum |
In the logs |
| 15:06 |
bshum |
I couldn't get a log result for what happened for the client user though |
| 15:06 |
Dyrcona |
bshum: Explains why I didn't see the same you did. I have that branch in development. |
| 15:06 |
bshum |
Dyrcona: Oh, well :) |
| 15:06 |
bshum |
Maybe we should sign it and push it then ;) |
| 15:07 |
Dyrcona |
I should probably load it in production... Think I can restart open-ils.circ in the middle of the day and anyone will notice? |
| 15:07 |
bshum |
I can, because I can rotate our bricks to do the restarts :) |
| 15:10 |
Dyrcona |
And, after checking, I'm a liar. |
| 15:10 |
Dyrcona |
I don't have that branch, but I have equivalent code from another branch. |
| 15:11 |
bshum |
Hmm |
| 15:13 |
bshum |
So, around line 3393 of Open-ILS/src/perlmods/lib/OpenILS/Application/Circ/Circulate.pm, we get |
| 15:13 |
bshum |
$self->backdate($circ->xact_start) if $self->claims_never_checked_out; |
| 15:13 |
bshum |
Which I think means use the xact_start as the backdate if the thing is claims_never_checked_out |
| 15:14 |
bshum |
So if there is a problem with backdating, then maybe this is related |
| 15:14 |
bshum |
Maybe ? |
| 15:15 |
* berick |
concurs |
| 15:15 |
Dyrcona |
bshum: The backdate parameter is being used without going through cleanse_iso8601, so if it comes out of the db with the extra zeroes, then you'll get that problem. |
| 15:16 |
Dyrcona |
Anyway, it turns out that a branch on my dev machine has totally rearranged CircCommon.pm and moved backdating elsewhere. I'm not sure if I did or dbwells did. |
| 15:17 |
eeevil |
Dyrcona: how about something like: where => {+ccvm => { id => { '<@' => { transform => 'intset', value => {'+mravl' => 'vector' }}}}} [entirely untested] |
| 15:17 |
Dyrcona |
eeevil: That's better than what I got. I'll give it a whirl. |
| 15:22 |
|
hbrennan joined #evergreen |
| 15:27 |
bshum |
berick++ # we'll test it a bit and I'll probably sign / push it soon |
| 15:28 |
bshum |
I wonder if dbwells has cut the maintenance releases yet, or if this can be one of the last things we get in there... |
| 15:40 |
dbwells |
bshum: Since we had our upgrade scheduled for last Friday, I decided it made more sense to release afterwards in case we encountered any new bugs. If you can get this in today, please do, but I'm less comfortable stretching much beyond that. |
| 15:40 |
bshum |
dbwells++ # sounds like a plan, 2.6.1 ftw! :) |
| 15:40 |
bshum |
I don't have much else new to push through on my end at the moment. |
| 15:40 |
bshum |
Though I'm sure I'll uncover more fun as the days progress :\ |
| 15:50 |
dbwells |
I am going to push in 1310751. It's the only uncommitted bug we hit on day 1 of being live, and while I've still got questions, the code there fixes the #1 offending case. |
| 15:52 |
|
_bott_ joined #evergreen |
| 16:00 |
|
krvmga joined #evergreen |
| 16:01 |
krvmga |
http://bark.cwmars.org/eg/opac/results?query=free+spirit&fg%3Aformat_filters=7&qtype=keyword&locg=1 |
| 16:02 |
krvmga |
if you do this search in our catalog, Johnathan safran's book "Free Spirit" returns at number 338. |
| 16:03 |
krvmga |
is this really all because of record density? even though we have titles and authors weighted more heavily? |
| 16:03 |
krvmga |
it doesn't seem to make sense. |
| 16:04 |
krvmga |
is record density overriding our weighting? |
| 16:05 |
krvmga |
i'm hard put to explain why hundreds of titles that don't have "free spirit" in them show up before that one. |
| 16:06 |
jcamins |
krvmga: the snarky answer is that you shouldn't try to force a free spirit to do what you want. The non-snarky answer will have to wait until someone who knows about search weighting in EG is around. |
| 16:06 |
bshum |
krvmga: What does the metabib table tell you as far as keyword entries for that bib 3157255 (the safran one) and the rest? |
| 16:07 |
bshum |
And weighting? What's that? :D |
| 16:07 |
krvmga |
jcamins: lol |
| 16:07 |
krvmga |
bshum: weighting is what i do periodically in the morning when i want to depress myself |
| 16:07 |
bshum |
krvmga: A lot of it depends on *how* you applied weighting |
| 16:07 |
bshum |
Did you add additional keyword metabib entries? |
| 16:07 |
bshum |
How much are they weighted? |
| 16:08 |
krvmga |
bshum: i'll have to see about that. |
| 16:08 |
krvmga |
bshum: titles and authors are weighted 5, everything else is weighted 1 |
| 16:08 |
bshum |
In... what? |
| 16:08 |
bshum |
And where? |
| 16:08 |
krvmga |
brb |
| 16:08 |
bshum |
And how? :D |
| 16:11 |
krvmga |
config - metabib_field - weight |
| 16:12 |
bshum |
And I suppose these are custom metabib_field entries? |
| 16:12 |
bshum |
Or did you only raise the existing title / author ones? |
| 16:12 |
krvmga |
raised the existing title/author ones |
| 16:13 |
bshum |
So... existing title/author entries would be only if you're using title/author searches |
| 16:13 |
bshum |
The search you indicated previously was a keyword search? |
| 16:13 |
bshum |
All keywords being equal, weights have nothing to do with it |
| 16:13 |
krvmga |
the keywords are also weighted |
| 16:13 |
krvmga |
mods32:titleinfo etc. |
| 16:14 |
bshum |
By default, there's only one keyword metabib entry, so....... all of the stuff would be weighted against itself? |
| 16:14 |
bshum |
Unless these are custom keyword entries |
| 16:14 |
krvmga |
hmmm, that's the first i've heard of that. |
| 16:14 |
bshum |
In which case I'd be curious to know how they were all defined |
| 16:14 |
krvmga |
i'll have to ask kmlussier tomorrow at the evergreen conference |
| 16:14 |
krvmga |
masslnc conference |
| 16:17 |
bshum |
krvmga: What does this give you? SELECT * FROM metabib.keyword_field_entry WHERE source = 3157255; |
| 16:17 |
bshum |
vs |
| 16:18 |
bshum |
SELECT * FROM metabib.keyword_field_entry WHERE source = 500578; |
| 16:18 |
bshum |
I'm curious to see what the actual values come up with |
| 16:18 |
bshum |
The field part is the ID from config.metabib_field |
| 16:18 |
bshum |
So that ought to match up with a given field type, and then you look at the weight of that entry |
| 16:18 |
bshum |
But I'm curious if the second one has the words "free spirit" in it more or less than the first. |
| 16:19 |
bshum |
That might be part of the reason why it's not as highly ranked? |
| 16:19 |
bshum |
Any which way, it's all custom, cause by default, everything ought to be weight of 1 :) |
| 16:19 |
krvmga |
the first one has free spirit in it 3 times but is a pretty verbose record. |
| 16:20 |
krvmga |
the second one also has free spirit in it 3 times but is a less verbose record |
| 16:21 |
* bshum |
doesn't understand what you mean by "less verbose" or "pretty verbose" but okay then... |
| 16:21 |
krvmga |
lots of words in the record |
| 16:22 |
bshum |
Yeah, but how many times does the word "free" and "spirit" appear in each sets of entries. |
| 16:22 |
bshum |
Cause that's how it'll count relevance |
| 16:22 |
bshum |
well, part of how it counts |
| 16:22 |
krvmga |
3 each in each |
| 16:24 |
bshum |
3 each in each row? |
| 16:24 |
bshum |
or 3 each in each value? |
| 16:24 |
bshum |
Or one each, per three rows? |
| 16:24 |
krvmga |
once each in three separate rows |
| 16:24 |
krvmga |
for the second one |
| 16:25 |
krvmga |
for the first one, it's twice in one row and once in another row |
| 16:25 |
krvmga |
how many rows it's in matters? |
| 16:25 |
krvmga |
more than how many times in one row? |
| 16:25 |
bshum |
The point is probably figuring out which of the rows is what's higher weighted |
| 16:26 |
krvmga |
ahh, ic |
| 16:26 |
bshum |
And then finding out if the words appear more often in that higher weighted row |
| 16:26 |
bshum |
If it does, then that's why it's ahead of the other ones |
| 16:26 |
krvmga |
bshum++ |
| 16:26 |
bshum |
But you have to do this for all the rows |
| 16:26 |
bshum |
Because it'll use all of them to determine relevancy |
| 16:27 |
bshum |
So if row 1 is weighted x2, but you only get one word hit. But row 2 is weighted 1 but you get five words hit |
| 16:27 |
bshum |
Then it might still weight bib 2 with the lesser weighed row ahead of the other bib with higher weight, but less hits |
| 16:27 |
bshum |
Or something like that |
| 16:27 |
bshum |
I imagine there's a more technical answer |
| 16:27 |
krvmga |
but still, not bad. i kind of get it. |
| 16:28 |
bshum |
There's some stuff in there about words, and whether we give more weight to words that appear together in a string vs. separately. But let's not dwell on that (yet). |
| 16:28 |
bshum |
This is why I don't play too much with my relevancy and just tell librarians to be more mindful of how they use keyword search :) |
| 16:29 |
bshum |
I throw in the author and bam, single search hit :) |
| 16:29 |
bshum |
Seems to me that's the quicker solution than trying to figure out why it didn't read my brain to know that was the ONE bib I actually wanted... |
| 16:29 |
bshum |
But I digress now :) |
| 16:32 |
krvmga |
if you do the search free spirit safran, you're taken directly to the record in my catalog. but the person who did the search didn't know the author |
| 16:34 |
bshum |
krvmga: I would verify how your metabib_field is setup then. I would think you'd learn much from its architecture. |
| 16:34 |
bshum |
And as far as not knowing what to search, that seems like "too bad, so sad" to me. |
| 16:35 |
bshum |
But I'm just the guy in the corner, what do I know? :) |
| 16:39 |
bshum |
Totally unrelated fun |
| 16:39 |
bshum |
This is the book I checked out to read: http://acorn.biblio.org/eg/opac/record/2987450 |
| 16:39 |
bshum |
Shakespearean Star Wars. I'm fairly amused :) |
| 16:40 |
jcamins |
bshum: have you finished the first four volumes? |
| 16:40 |
bshum |
jcamins: I actually just skipped straight to this one. |
| 16:41 |
bshum |
I would have started with the Jedi Doth Return (my favorite), but it doesn't exist yet. |
| 16:41 |
bshum |
Or rather, none of my libs own copies yet. |
| 16:41 |
jcamins |
bshum: oh, wait, right. Star Wars started with volume 4. |
| 16:41 |
bshum |
Heh |
| 16:42 |
jcamins |
Gosh, I do love AquaBrowser. |
| 16:43 |
jcamins |
By which I mean "I will kill someone if they don't tell me whether they have this book." |
| 16:43 |
jcamins |
So annoying. |
| 16:43 |
jcamins |
Woohoo! eBooks! |
| 16:43 |
jcamins |
Unavailable. |
| 16:45 |
jcamins |
My public libraries give me a headache. |
| 16:47 |
|
tspindler left #evergreen |
| 16:53 |
jcamins |
bshum: the first line is excellent. |
| 16:56 |
pinesol_green |
[evergreen|Bill Erickson] LP#1322303 cleanse backdate for checkin overdue voiding - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=e3e264a> |
| 17:15 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 17:21 |
* eeevil |
looks up |
| 17:21 |
|
mmorgan left #evergreen |
| 17:27 |
eeevil |
@later tell krvmga this is precisely the situation where search.relevance_adjustment comes into play. In particular, the first_word bump. though, ideally, it would be a more generic "starts with" adjustment. of course, an actual title search does a LOT better in terms of ranking |
| 17:27 |
pinesol_green |
eeevil: The operation succeeded. |
| 17:28 |
eeevil |
@later tell krvmga also, searching for "ti:free spirit || kw:free spirit" suggests that the weighting you have in place may not be doing what you expect, since the ranking for that likely matches your expectations better (though not perfectly, certainly) |
| 17:28 |
pinesol_green |
eeevil: The operation succeeded. |
| 19:03 |
|
kmlussier joined #evergreen |
| 19:04 |
|
kmlussier left #evergreen |
| 19:04 |
|
kmlussier joined #evergreen |
| 19:11 |
kmlussier |
Just catching up on scrollback. C/W MARS does have custom indexes that weigh titles and authors more heavily in keyword searches. krvmga's results do seem strange since there are records with "free spirit" showing up in the publisher field ranking more highly than records with "free spirit" showing up in the title field. |
| 19:13 |
* kmlussier |
is guessing publisher was added as a custom index too since I don't think it's part of the default keyword blob. |
| 19:13 |
* kmlussier |
disappears again to plan for the MassLNC conference. |
| 19:31 |
|
dcook joined #evergreen |
| 19:47 |
|
kmlussier joined #evergreen |
| 19:50 |
kmlussier |
So much for disappearing, but I have a theory on why the relevance ranking for krvmga's searches seem so screwy that I'll put out there for fact checking. |
| 19:51 |
kmlussier |
C/W MARS added a custom index for the 260b to add publishers to the keyword index. I don't have access to their database from home, but I'm guessing the weight for this index is 1. |
| 19:52 |
kmlussier |
Nevertheless, the "free spirit" keyword search is an index match for this index. It basically is matching 100% of the terms in the index. |
| 19:53 |
kmlussier |
Even though the title index is weighted more heavily for a keyword search, the 100% match in the publisher index is enough to override the weight that comes from being in the title field. Is that plausible? |
| 19:54 |
kmlussier |
If so, I'm thinking the best approach is, instead of adding a separate publisher index, we should have configured the keyword blob to include the 260b. I don't think we did so because we didn't want to add all of the origininfo mods indexes. |
| 19:55 |
kmlussier |
But I'm wondering if there are other ways to address this problem (one that doesn't require a reingest.) Perhaps a negative weight for the publisher index? |
| 19:56 |
kmlussier |
@monologue |
| 19:56 |
pinesol_green |
kmlussier: Your current monologue is at least 10 lines long. |
| 19:57 |
kmlussier |
Heh...now that I'm done with my brain dump, I can go back to my conference planning. See you all Thursday! |
| 19:58 |
tsbere |
kmlussier: I think keyword has at least one "if it exists in the marc..." definition by default |
| 19:59 |
tsbere |
if you add more then you can make specific things count more in a keyword search, but that default would catch everything. <_< |
| 20:04 |
kmlussier |
tsbere: No, the keyword blob excludes origininfo, which includes the publisher field. |
| 20:05 |
kmlussier |
And, for the most part, we want to exclude most origin info. Imagine including the place of publication in the keyword index. It would be disastrous. |
| 20:07 |
kmlussier |
But both C/W MARS and NOBLE had reasons for wanting to include the publisher. And there are two sides to that decision too. Adding little and brown to the keyword index for everything published by Little Brown can be problematic too. But I think they saw other benefits that outweighed that potential problem. |
| 20:08 |
* kmlussier |
really disappears this time. :) |
| 22:27 |
eeevil |
@later tell kmlussier wow, I bet you're 100% correct |
| 22:27 |
pinesol_green |
eeevil: The operation succeeded. |
| 22:30 |
|
sseng_ joined #evergreen |
