| Time |
Nick |
Message |
| 00:17 |
jeffdavis |
smcalilly: hi! most folks in this channel are around on weekdays 8-5pm EST |
| 00:18 |
jeffdavis |
looking at that endpoint now... |
| 00:33 |
jeffdavis |
I believe that endpoint expects an actor::user object. The structure of Evergreen objects is defined by something called the "fieldmapper" - there's a bit of an introduction here: https://docs.evergreen-ils.org/eg/docs/3.10/development/intro_opensrf.html#_accepting_and_returning_evergreen_objects |
| 00:39 |
smcalilly |
that's very helpful, thank you jeffdavis. i had not seen that version of the docs |
| 00:41 |
jeffdavis |
I'm glad it's helpful! I'm looking around but I don't know offhand of a good introduction to writing a client that uses the Evergreen API - there's a real need for that though. Hopefully someone can suggest something more useful during "regular hours" tomorrow if you're available. |
| 07:49 |
|
BDorsey joined #evergreen |
| 08:20 |
|
mantis1 joined #evergreen |
| 08:42 |
|
mmorgan joined #evergreen |
| 08:52 |
|
kworstell-isl joined #evergreen |
| 08:59 |
|
Dyrcona joined #evergreen |
| 09:38 |
|
dguarrac joined #evergreen |
| 10:02 |
|
rfrasur joined #evergreen |
| 10:15 |
|
kworstell-isl joined #evergreen |
| 10:16 |
|
Christineb joined #evergreen |
| 10:16 |
csharp_ |
@blame process one |
| 10:16 |
pinesol |
csharp_: process one is really just another name for autogen |
| 10:17 |
Dyrcona |
Heh |
| 10:18 |
Dyrcona |
process one is just another name for systemd.... :) |
| 10:18 |
Dyrcona |
It's too bad they got the corporate registration before Lennaert. :) |
| 10:19 |
Dyrcona |
And nobody but us penguins has any idea what I'm going on about. :) |
| 10:27 |
|
smcalilly joined #evergreen |
| 10:39 |
Dyrcona |
@later tell smcalily I just saw your question from last night in the logs. You need to make sure that your patron object is formatted correctly for the version of the IDL running on the server. You can retrieve the IDL from the server. Ping me if you have questions. |
| 10:39 |
pinesol |
Dyrcona: The operation succeeded. |
| 10:39 |
Dyrcona |
Spelt the username wrong, of course.... |
| 10:40 |
Dyrcona |
@later tell smcalilly You need to make sure that your patron object is formatted correctly for the version of the IDL running on the server. You can retrieve the IDL from the server. Ping me if you have questions. |
| 10:40 |
pinesol |
Dyrcona: The operation succeeded. |
| 10:55 |
Dyrcona |
Weird. One of my development servers is returning book jackets, but not production nor any of my other development servers. Maybe that was just a fluke? |
| 11:21 |
|
WaterBoy joined #evergreen |
| 11:25 |
|
sleary joined #evergreen |
| 11:32 |
Stompro |
mmorgan, I heard back from B&T about content cafe this morning, they don't see a problem on their end, but have heard from a number of Evergreen sites about the issue. |
| 11:39 |
Stompro |
When I request cover art directly using the Jacket.aspx link I do get cover art. So maybe something is up with the xml multiple request results. |
| 11:51 |
mmorgan |
Stompro: I just received a similar response from B&T. Interesting that it's affecting a number of unrelated Evergreen systems. |
| 11:52 |
* mmorgan |
isn't clear on how all the components work. |
| 11:53 |
Dyrcona |
They've obviously changed something that affects us, but no one else. |
| 11:58 |
Dyrcona |
Also, this server is getting jackets: https://bugs.launchpad.net/evergreen/+bug/2008423/+attachment/5649868/+files/Screenshot%20from%202023-02-24%2011-56-21.png |
| 11:58 |
pinesol |
Launchpad bug 2008423 in Evergreen "Certain punctuation creates problems for search in public catalog" [Undecided,Triaged] |
| 11:58 |
Dyrcona |
None of my others seem to be. |
| 11:59 |
Dyrcona |
Oh, wait. I bet it is using OpenLibrary..... |
| 11:59 |
|
jihpringle joined #evergreen |
| 12:00 |
* mmorgan |
was going to ask if it was OpenLibrary :) |
| 12:00 |
Stompro |
Looks like the requests are http, I'll try and grab a packet capture of a request that isn't working. |
| 12:00 |
Dyrcona |
Yeah, never mind. It's using OpenLibrary. |
| 12:01 |
* Dyrcona |
is getting a headache. |
| 12:01 |
Dyrcona |
Look at that! It's lunch time! |
| 12:06 |
mmorgan |
Stompro++ |
| 12:07 |
mmorgan |
ContentCafe.pm has several occurrences of http://contentcafe2.btol.com |
| 12:07 |
* mmorgan |
will try https on our dev server. |
| 12:10 |
Stompro |
I'm seeing a strange error in some responses "Database 'Jacket' does not exist. Make sure that the name is entered" |
| 12:11 |
Stompro |
Full "<Error>Database 'Jacket' does not exist. Make sure that the name is entered correctly.</Error>" |
| 12:17 |
Dyrcona |
The flipped the case sensitivity flag in their database and didn't tell anyone? |
| 12:18 |
* Dyrcona |
should shut up for now and concentrate on lunch. |
| 12:19 |
Stompro |
Maybe it has to do with requesting multiple keys at once. I'll test if it works with just one search key. |
| 12:22 |
Stompro |
I'll see if my postman account still works and try the case sensitivity thing. |
| 12:27 |
Stompro |
Same result with just one search key. |
| 12:28 |
Stompro |
B&T support says they are reviewing the info now. |
| 12:30 |
Dyrcona |
Bmagic: What you said to me privately about PG15 search performance yesterday appears to be true. I have a Pg15 instance using default settings that's returning search results just about as fast as Pg10 that is optimized on the same hardware. That is, Pg15 and Pg10 are running on the same server. |
| 12:31 |
|
Guest397 joined #evergreen |
| 12:32 |
Bmagic |
awesome! I like faster |
| 12:36 |
Stompro |
Dyrcona, using jacketdetail or jacketDetail doesn't fix the issue in a test request. So it must be something else. Evergreen must be one of the only products that uses the XmlPost method to grab added content from them. |
| 12:56 |
Dyrcona |
Stompro++ |
| 12:57 |
Dyrcona |
Do you know if they have another method we could try? |
| 12:58 |
* Dyrcona |
looks around for where he left his glass of tea.... |
| 13:00 |
Stompro |
The docs I have say they offer a few options - XmlClass, XmlPost or XmlString, but the request itself is probably pretty similar. |
| 13:01 |
Stompro |
Hmm, here is the schema, http://contentcafe2.btol.com/ContentCafe/ContentCafe.asmx?WSDL |
| 13:02 |
Stompro |
Maybe JacketBrief instead of JacketDetail. |
| 13:02 |
Stompro |
Nope, that doesn't work either. |
| 13:04 |
Stompro |
I tried "AllMembers" but receive back <Error>Content requested requires admin access</Error> |
| 13:09 |
Stompro |
Hmm, we could make use of AvailableContent to not request content that they say they don't have for a title. |
| 13:21 |
mmorgan |
Stompro: Just curious, have you applied the fix for https://bugs.launchpad.net/opensrf/+bug/1916500? |
| 13:21 |
pinesol |
Launchpad bug 1916500 in OpenSRF "Improve TLS settings in example configuration" [Undecided,New] |
| 13:23 |
Stompro |
mmorgan, We use Apache, so I don't think that applies to us. |
| 13:24 |
mmorgan |
Ok, thanks. Just grasping at straws :) |
| 13:25 |
|
mdriscoll joined #evergreen |
| 13:28 |
Stompro |
We do not have great TLS settings right now, still have staff using XUL. Need to setup a separate server for them to interface with. |
| 13:30 |
Dyrcona |
Stompro: Have you tried using https to retrieve the jackets? |
| 13:30 |
Stompro |
Nope, will try. |
| 13:31 |
Dyrcona |
I don't think our TLS settings matter. We updated ours and we're having the issue. |
| 13:31 |
Stompro |
No change, same error back. |
| 13:33 |
Dyrcona |
Maybe they just don't like us? :) |
| 13:34 |
Stompro |
Someone changed something somewhere on their end... hopefully that person didn't take Friday off. |
| 13:43 |
Dyrcona |
Yeahp. |
| 13:44 |
Dyrcona |
if [[ "$ua" == "Evergreen" ]]; then crash() else; .... fi |
| 13:45 |
Dyrcona |
Oops. put the second ; in the wrong place, but you get it. :) |
| 13:49 |
|
sleary joined #evergreen |
| 15:10 |
Dyrcona |
Y'know... We *might* be doing NACO normalization wrong, or I might need to study the code a little harder. |
| 15:10 |
Dyrcona |
Probably the latter but..... |
| 15:17 |
Dyrcona |
If we're applying "NACO" normalization to the search fields, then why are + and & and # missing. If I'm reading the SCA PCC document correctly, we should be preserving those. |
| 15:23 |
Dyrcona |
Yeah, both search_normalize and naco_normalize look like they strip +&# but the LoC documents say to keep them when comparing records. |
| 15:36 |
jeffdavis |
hmm, public.naco_normalize doesn't strip those characters in my database and I don't see where the functions strip them in the code? |
| 15:40 |
Dyrcona |
Let me check master maybe we have custom versions of those functions from way back. |
| 15:44 |
Dyrcona |
jeffdavis: Line 654 in 002.functions.config.sql, they get replaced with control characters, that I think the next line replaces with spaces. |
| 15:54 |
Dyrcona |
There's a line after that looks like it turns the specific control characters back into the original characters, but that doesn't seem to work. |
| 15:54 |
Dyrcona |
At least C++ is transformed into C while C# seems to stay C#. |
| 15:57 |
jeffdavis |
Ha, I was looking for the unicode code points, not the literal characters. The re-conversion works here though - "select public.naco_normalize('1+1')" returns "1+1" |
| 15:59 |
Dyrcona |
All right, so calling the normalization on strings seems to work. |
| 16:00 |
Dyrcona |
select naco_normalize('C++ (computer program lanugage)'); gives me c++ computer program lanugage |
| 16:00 |
Dyrcona |
So, either our records are wrong or we're not using the right normalizers. |
| 16:00 |
Dyrcona |
jeffdavis++ |
| 16:06 |
Dyrcona |
So the problem isn't normalizers, it's cataloging of records and its that search apparently throws away the symbols. |
| 16:09 |
Dyrcona |
Nope. It's the ts_vector has those characters stripped out. |
| 16:10 |
Dyrcona |
Well, let's give it the proper name, index_vector. |
| 16:24 |
Dyrcona |
Also, the record that prompted me to say, "At least C++ is transformed into C..." turns out to be a C++ title that only has "C (Computer Program Language)" as a subject. Looks like I picked a bad example from the start, which is so typical of me. :) |
| 16:51 |
Stompro |
mmorgan, B&T just said they think they narrowed down what the content cafe issue is, but it will probably be Monday or Tuesday before it is fixed. |
| 16:51 |
mmorgan |
Stompro++ |
| 16:52 |
mmorgan |
Thanks for the update!! |
| 16:56 |
mmorgan |
Stompro: So definitely something on their end? |
| 17:05 |
|
mmorgan left #evergreen |
