| Time |
Nick |
Message |
| 06:54 |
|
collum joined #evergreen |
| 08:39 |
|
cbrown joined #evergreen |
| 09:20 |
|
mmorgan joined #evergreen |
| 09:21 |
|
Dyrcona joined #evergreen |
| 09:32 |
Dyrcona |
gmcharlt: Anything in particular that you'd like assistance with for the release today? |
| 10:23 |
|
collum joined #evergreen |
| 10:37 |
|
mmorgan1 joined #evergreen |
| 10:53 |
|
Christineb joined #evergreen |
| 11:17 |
|
csharp_ joined #evergreen |
| 12:00 |
|
jihpringle joined #evergreen |
| 12:08 |
goood |
Dyrcona: "osrfStringArrayAdd size is too large" means nothing. we should just remove that log message. |
| 12:20 |
goood |
Dyrcona: and, re api setup, I'm liking the "_by_blah" suffix less and less. see: /patrons endpoint which provides a generic search via GET, and the specializations of /patrons/by_{barcode|username}/:{barcode|username}[/id] etc. ... those specializations could use the find_user controller method by supplying static values for field and comparison, but there are existing opensrf methods, so I didn't do that |
| 12:20 |
* goood |
goes to look at the branch before blabbing futher |
| 12:20 |
goood |
further, even |
| 12:25 |
Dyrcona |
goood: I'll push a cleaned up branch that I made this morning. it drops some commits that are replaced in the WIP branch. |
| 12:26 |
goood |
(note: see /patrons/verify for how to specify a static value (an empty string, in that endpoint's method_params definition, but anything in "s will work)) |
| 12:26 |
goood |
+1 |
| 12:26 |
goood |
Dyrcona++ # loving the api love |
| 12:26 |
Dyrcona |
goood: See this branch for a cleaner look: user/dyrcona/lp2150148_rebase1 |
| 12:27 |
Dyrcona |
I'm OK with renaming any of the paths, etc. I plan to put this where the vendor can look at it next week, so if we can decided on paths this week, that would be great! |
| 12:27 |
goood |
ah ha! first commit makin' me happy already :) |
| 12:27 |
Dyrcona |
:) |
| 12:28 |
goood |
well, let 'em know the API version is still 0.0, and subject to change until we nail it down |
| 12:29 |
goood |
for the marc one, any objection to doing what the by-id method does and just checking the accept header for the desired format? |
| 12:31 |
goood |
OpenILS::OpenAPI::Controller::bib::fetch_one_bib() is the code that checks the resovled requested content format |
| 12:32 |
Dyrcona |
goood: I'll take a look. I'm also not happy that it returns a string with escaped double quotes. I mean to look at that. Might as well do it right now. |
| 12:35 |
goood |
yeah, see how /bibs/:id is set up, for sure. it's the accept header that tells openapi how to render the final output, which is why we should use that to decide which to ship |
| 12:36 |
goood |
which in turn means we need to specifically support different accept-driven formats. otherwise you need to say "response format for this endpoint is DEFINITELY xml" and then it won't escape the content |
| 12:36 |
goood |
point being, let the infrastructure do the magic for you :) |
| 12:39 |
Dyrcona |
OK. |
| 12:40 |
Dyrcona |
I figured since we're definitely asking for XML, might as well say it's XML. |
| 12:40 |
goood |
(GET /bibs/:id has 3 response types: default json with fm_type bre; application/xml for when they ask for that (no escaping, just the marc field from the bre); application/octet-stream for asking for binary marc) |
| 12:41 |
goood |
no, they should ask for xml by setting the accept header to application/xml. that's a big part of openapi (and REST generally) |
| 12:41 |
goood |
otherwise our /native/ "bib" format is the bre json blob |
| 12:43 |
Dyrcona |
OK, but the API I created is only returning MARCXML, it's just calling open-ils.supercat..isbn.marcxml.retrieve. Can I still do that and have a different response type? |
| 12:45 |
goood |
ah, I see... :( ... no, you'd need a wrapper. but if we're def just doing direct xml-only returns, the response type should be application/xml |
| 12:48 |
goood |
(but, for a general purpose "return a bib" method, I think a controller helper/wrapper like find_one_bib would be a good thing. it can still use the supercat method(s) ... in fact, there may be methods that do the binary and bre versions already |
| 12:48 |
goood |
sec... checking |
| 12:53 |
goood |
well, there's a method for the bre (open-ils.supercat.isbn.object.retrieve) which could be used for all three formats, a la find_one_bib(), via a wrapper |
| 12:54 |
goood |
fwiw, I find https://github.com/EquinoxOpenLibraryInitiative/evg-api-explorer really handy when looking for methods to map |
| 12:54 |
Dyrcona |
OK. would you rather I implement that? I implemented the retrieve MARCXML by ISBN because that's what the vendor asked about. |
| 12:54 |
Dyrcona |
yeah, I saw the explorer but haven't set it up. |
| 12:56 |
Dyrcona |
Also, those supercat methods are misnamed. They work for any standard 02x identifier filed, not just ISBN. |
| 12:57 |
goood |
IMO, since it's basically a copy/paste of find_one_bib, but calling the supercat method instead cstore's retrieve, I think the effort is minimal for the benefit, so I would be in favor of that |
| 12:57 |
Dyrcona |
OK. I'll do that. Should I delete the /search/ method? |
| 12:58 |
goood |
and sure, you could pass an issn or upc, but I think that's not a bad thing per se |
| 12:58 |
Dyrcona |
Also, I figured out my quoted string issue. I forgot to set the Accept header in my test script. |
| 13:00 |
Bmagic |
I'm helping a library print spine labels and there's a strange thing going on here. When a call number meets some sort of a pattern, Evergreen will introduce a new line in the middle of a value. Here's the example: "PZ 7 .C76984 Mag 2014 YA" Evergreen puts a new line between the "M" and the "a" in Mag |
| 13:01 |
Bmagic |
But if I change the call number, and replace Mag with M67 (any number value), Evergreen doesn't introduce the new line |
| 13:01 |
goood |
I don't have a STRONG preference on the api path, but on balance, this is closer to a retrieve than a search, and we have a bib-retrieve, so, I'd probably put it at /bibs/by_identifier/:isxn or similar, matching the /patron/by_barcode/:b and /patrons/by_username/:u |
| 13:02 |
Dyrcona |
goood: All right. I'll put it under /bib(s) and delete the /search version. |
| 13:02 |
goood |
Dyrcona++ |
| 13:03 |
Bmagic |
Dyrcona++ |
| 13:03 |
Dyrcona |
After this I can hopefully get started on multiclass search. :) |
| 13:03 |
Dyrcona |
Bmagic: Do you think there might have been an invisible break character in the label? |
| 13:03 |
Bmagic |
I thought that too, nope |
| 13:04 |
Bmagic |
I bet you can recreate the issue on your system if you put that call number on an item and try to print the spine label |
| 13:04 |
Dyrcona |
Huh. That is weird. |
| 13:05 |
Dyrcona |
Maybe. Don't have time right now. |
| 13:05 |
goood |
heh... DEF going to need a wrapper for that :) ... and, we may want to think about the return value shape for that. like, return a list of unapi URIs for easy use in supercat? do we really need to return blobs of MARC? (maybe separate endpoints for those two, with one wrapper underneith, and a static param to say "return this type of crap" in the method_params definition |
| 13:06 |
goood |
(and by supercat, I just mean the unapi location that takes a uri) |
| 13:06 |
goood |
anyway, I must go eat something now |
| 13:07 |
Dyrcona |
goood++ |
| 13:13 |
Dyrcona |
Ah, the API explorer /is/ cool. |
| 13:45 |
jeff |
Bmagic: unable to reproduce here with browser printing on demo. barcode G880400001542 seemed to not break when printing spine labels using your specified call number label. also unable to reproduce on 3.15. can you reproduce on demo? |
| 13:45 |
Bmagic |
I was able to figure out a clue: call number classification is "LoC" - causes the issue |
| 13:47 |
Bmagic |
when the call number is switched to "Generic" the problem goes away |
| 13:47 |
Bmagic |
so maybe it's a feature |
| 13:59 |
Dyrcona |
Be back in half an hour. |
| 14:42 |
|
Dyrcona joined #evergreen |
| 14:49 |
goood |
Bmagic: it is a feature. it's implementing line breaks for cutter numbers, which are part of LC call numbers. |
| 14:52 |
|
jihpringle joined #evergreen |
| 15:02 |
Bmagic |
goood++ # thanks for confirming my suspicions |
| 15:13 |
Dyrcona |
goood: I'm working on the new implementation for retrieval by ISBN, and I'm not sure what to do when nothing is found. Just returning undef leads to a different error: {"errors":[{"message":"Expected application\/json - got application\/xml.","path":"\/header\/Accept"}],"status":400} |
| 15:14 |
Dyrcona |
Oh. I think I see what I should do further down. |
| 15:14 |
goood |
you may want to set the status and return an appropriate-format error? |
| 15:15 |
goood |
like a 404, probably ... wasn't found :) |
| 15:15 |
goood |
yeah, $c->res->code(404) |
| 15:17 |
goood |
and now I see I should be doing that after trying to fetch the bre in fetch_one_bib() |
| 15:17 |
Dyrcona |
probably, yeah. |
| 15:17 |
Dyrcona |
:) |
| 15:26 |
Dyrcona |
Oh. ISO 8869-1 in a MARC record. |
| 15:26 |
Dyrcona |
Grr..... 8859-1... |
| 15:26 |
Dyrcona |
I just happen to pick that record to play with. :) |
| 15:29 |
Dyrcona |
Since this seems to work. I'll make a rebase2 branch and push it to working. |
| 15:38 |
goood |
I love it when a plan comes together |
| 15:38 |
Dyrcona |
:0 |
| 15:39 |
Dyrcona |
user/dyrcona/lp2150148_rebase2 clean version of what I've got so far. |
| 15:44 |
goood |
I was just looking at it. very sweet |
| 15:44 |
goood |
Dyrcona++ |
| 16:40 |
Dyrcona |
I wonder if we want /search/query or bibs/query? We might not need a /search schema after all. |
| 16:41 |
Dyrcona |
I guess /bibs/query makes it seem like we're getting bibs back and /search could return something else, so I guess we do want /search/query. |
| 16:59 |
csharp_ |
@quote get 258 |
| 16:59 |
pinesol |
csharp_: Quote #258: "<michael_scott> Don’t ever, for any reason, do any upgrading, for any reason, ever, no matter what. No matter… where. Or who, or who you are with, or, or where you are going, or… or where you’ve been… ever. For any reason, whatsoever." (added by csharp at 04:59 PM, May 13, 2026) |
| 16:59 |
|
mmorgan1 left #evergreen |
| 17:44 |
gmcharlt |
https://evergreen-ils.org/evergreen-3-17-0-available/ |
| 19:58 |
|
jihpringle joined #evergreen |
| 22:02 |
csharp_ |
gmcharlt++ |
| 23:23 |
|
JBoyer joined #evergreen |
