Evergreen ILS Website

IRC log for #evergreen, 2018-06-14

| Channels | #evergreen index | Today | | Search | Google Search | Plain-Text | summary | Join Webchat

All times shown according to the server's local time.

Time Nick Message
06:31 pinesol_green News from qatests: Testing Success <http://testing.evergreen-ils.org/~live>
06:59 agoben joined #evergreen
07:15 rjackson_isl joined #evergreen
08:27 bdljohn joined #evergreen
08:50 idjit joined #evergreen
08:52 yboston joined #evergreen
08:55 krvmga joined #evergreen
08:58 lsach joined #evergreen
09:06 jvwoolf joined #evergreen
09:10 jvwoolf1 joined #evergreen
09:13 Dyrcona joined #evergreen
09:35 kmlussier joined #evergreen
09:35 pinesol_green [evergreen|Remington Steed] Docs: Minor corrections to "Borrowing items" section - <http://git.evergreen-ils.org/?p=​Evergreen.git;a=commit;h=bd663dd>
09:50 Christineb joined #evergreen
09:50 collum joined #evergreen
10:17 pinesol_green [evergreen|Bill Erickson] LP#1774427 Parse DoB dates as whole dates - <http://git.evergreen-ils.org/?p=​Evergreen.git;a=commit;h=4cd44bb>
10:42 dbs huh. 48 new bib records yesterday with tcn_source = '', from a mix of users and times
10:44 dbs two of them are ACQ orders. I wonder if this is a z39.50 copy cataloguing thing
10:46 dbs it is, in fact, every record created yesterday
10:49 dbs Workaround is to run a nightly cron job to fill in the tcn_source but that's annoying
10:54 dbs SELECT '"' || tcn_source || '"' AS tcn_source, COUNT(*) FROM biblio.record_entry WHERE deleted IS FALSE AND create_date::DATE = NOW()::DATE - '1 day'::INTERVAL GROUP BY tcn_source ORDER BY 2 DESC;
10:55 dbs (query to see how many of your records from yesterday have tcn_source definitions)
11:16 csharp dbs: we don't have any null/blank ones, but it may be due to a difference in workflow
11:16 csharp (e.g., our libraries only add records via z39.50 from OCLC)
11:19 berick dbs: same issue here.  all "" yesterday
11:20 berick we don't use z39, but we do use vandelay
11:21 berick looks like ./Cat/BibCommon.pm defaults to "" when no tcn_source is provided.
11:21 berick in biblio_record_xml_import()
11:22 berick or rather when one cannot be extracted from the record
11:24 csharp hmm - none with "" in the last 90 days for us - I thought acq vandelay might cause it, but apparently not
11:36 Dyrcona Well, while we're on the subject of vandelay and imports, none of our records are importing if they have holdings tags.
11:36 Dyrcona The example I've been giving are two records with 949 tags and a holdings import profile that looks for the 949.
11:37 Dyrcona The bibs don't even make it to the queue and I see no errors in the logs on my test vm.
11:38 Dyrcona They say this happens in the XUL and web staff clients. I've so far only tested xul, but will try the web staff client in a moment.
11:40 khuckins joined #evergreen
11:41 kmlussier How do you use Vandelay without selecting a source? When I retrieve the interface, it defaults to oclc and there is no way to not select an option as far as I can tell.
11:42 berick kmlussier: source vs. tcn_source
11:42 Dyrcona kmlussier: That's bib source. They're talking about tcn_source, another source field on the bib record entry.
11:42 kmlussier Oh, sorry. I'm obviously confused. :)
11:43 Dyrcona Well, it is confusing. :)
11:45 * berick had the same double-take
11:47 beanjammin joined #evergreen
11:48 dbs thanks csharp / berick - I had just been musing that it might be a JS undef or Perl null == '' thing going on
11:48 dbs the BibCommon pointer will be helpful
12:08 jihpringle joined #evergreen
12:25 jvwoolf joined #evergreen
12:27 jvwoolf1 joined #evergreen
12:52 Dyrcona On my test vm, I'm getting a 403 on vandelay-upload.
12:53 Dyrcona With "Require all granted"!
12:53 Dyrcona The tmp file is created...
12:57 dbs Dyrcona: exceeding the max upload length maybe?
12:58 Dyrcona dbs: I don't think so. It's 2 records 1,319 bytes. I'm looking at the possibilities.
12:58 dbs heh I guess not :)
12:59 Dyrcona I think this particular problem is local to my vm, but I'll check production, too.
12:59 Dyrcona The import directory didn't exist on the vm.
13:00 Dyrcona Ok. Now, my records are in the queue. :)
13:02 Dyrcona Actually importing them leads to what looks like a WSOD.
13:04 dbs Dyrcona: they're probably importing just fine
13:05 dbs the user experience for vandelay imports is not optimal
13:05 Dyrcona Been too long for just two records...
13:05 dbs (I go back and check the queue to see what actually happened)
13:05 dbs found the culprit: ad3cf21e065
13:05 pinesol_green dbs: [evergreen|dbs] Make the bib source selector in Vandelay MARC batch importer/exporter work - <http://git.evergreen-ils.org/?p=​Evergreen.git;a=commit;h=ad3cf21>
13:07 Dyrcona I did and nothing imported.
13:07 Dyrcona BBIAB
13:10 Dyrcona I tried importing just 1 of the records and it appears to have failed.
13:10 Dyrcona Console errors are all realated to nls/en translation stuff, so not important.
13:12 Dyrcona OK. Cstore error pointing to a db error.
13:14 * dbs appends an "if ($tcn_source)"
13:14 Dyrcona Three lines look relevant, and looks like a problem with vandelay_import_item_imported_as_inh_fkey() line 3 at IF
13:15 dbs ah right, holdings! we never use those
13:15 dbs (not in vandelay anyway)
13:23 Dyrcona Well, my function in the db looks like the function in the base schema.
13:26 Dyrcona 2018-06-14 13:06:57 EDT [2055-13] evergreen@jasontest ERROR:  record "new" is not assigned yet
13:26 Dyrcona 2018-06-14 13:06:57 EDT [2055-14] evergreen@jasontest DETAIL:  The tuple structure of a not-yet-assigned record is indeterminate.
13:26 Dyrcona 2018-06-14 13:06:57 EDT [2055-15] evergreen@jasontest CONTEXT:  PL/pgSQL function vandelay_import_item_imported_as_inh_fkey() line 3 at IF
13:26 JBoyer Dyrcona, I assume you're looking at vandelay.import_item? When is that trigger called? Mine's called after insert and update
13:26 Dyrcona That's the errors in the postgres logs.
13:26 JBoyer That sounds like it might be called on delete, which was a problem with several of those _inh_ triggers initially
13:27 Dyrcona There's something about delete after that, yeah.
13:28 Dyrcona Actually, the next two log lines:
13:28 Dyrcona SQL statement "DELETE FROM vandelay.import_item WHERE record = OLD.id"
13:28 Dyrcona PL/pgSQL function vandelay.cleanup_bib_marc() line 8 at SQL statement
13:29 Dyrcona I seem to recall discussing these triggers before. Did anyone come up with a fix?
13:29 Dyrcona Oh, yeah, don't call it on delete was my suggestion.
13:30 * Dyrcona checks the trigger definitions in the database.
13:31 Dyrcona Ah ha!
13:31 Dyrcona I have two triggers with slight different names calling that function, one on insert and update, other on insert, update and delete.
13:32 Dyrcona So, I drop the bad one and see what happens.
13:34 Dyrcona cyclical logic... can't drop constraint because trigger depends on it, drop trigger instead.
13:36 Dyrcona Yay!
13:36 Dyrcona dbs++ and JBoyer++ # For listening and offering suggestions.
13:38 JBoyer That sounds familiar too. The names were auto-generated and so there may be at least 2 different ways. I think I was involved in 1 effort to fix it, though that would have only affected 1 "spelling" of the function names.
13:38 JBoyer Bmagic was running into a similar issue a while back.
13:39 * csharp only has one function by that name
13:39 JBoyer Uh, "2 different ways they're named" or something. I'm not sure where I was headed when I apparently stopped writing that.
13:40 JBoyer csharp, ideally you do only have 1. I'm not sure we really tracked down the cause of the multiple names. (for all I know it was the fix. D: )
13:43 csharp understood
13:45 Dyrcona Ok. Only 1 function, but I had two triggers calling it.
13:46 Dyrcona inherit_import_item_imported_as_fkey calls it on insert or update on vandelay.import_item
13:47 Dyrcona inherit_imported_as_fkey calls it on insert, update, or delete
13:47 Dyrcona The delete is the problem, so I dropped the second trigger and all is happy.
13:48 Dyrcona And, I think dickreckard had almost the same problem: https://pastebin.com/2mKsdmSv
13:49 Dyrcona :)
13:49 Dyrcona To quote Downchild Blues Band: "My mind don't work and my whole body aches!"
14:01 rlefaive joined #evergreen
14:25 dbs bug # 1776954 is open and has a branch for the tcn_source empty string thing
14:26 dbs ahem, bug 1776954
14:26 pinesol_green Launchpad bug 1776954 in Evergreen "Zotero fails to capture metadata" [Undecided,New] https://launchpad.net/bugs/1776954
14:37 Dyrcona To quote Downchild Blues Band again, "Everything's Gonna Be Alright."
14:54 khuckins_ joined #evergreen
15:00 Dyrcona TypoScript sounds like the programming language for me.
15:00 berick @quote add < Dyrcona> TypoScript sounds like the programming language for me.
15:00 pinesol_green berick: Error: You must be registered to use this command. If you are already registered, you must either identify (using the identify command) or add a hostmask matching your current hostmask (using the "hostmask add" command).
15:00 berick heh, every time
15:01 Dyrcona :)
15:01 berick @quote add < Dyrcona> TypoScript sounds like the programming language for me.
15:01 pinesol_green berick: The operation succeeded.  Quote #188 added.
15:02 berick @who said [quote random] about [band]
15:02 pinesol_green paxed said Quote #158: "< JBoyer> rm it all and let the fs sort it out." (added by csharp at 11:25 AM, August 18, 2016) about Zuckerberg's Big Mistake.
15:03 * dbwells almost adopted Typo3 for our CMS back in the day.
15:52 khuckins__ joined #evergreen
16:37 kmlussier I don't know much about how markmail works, but it looks like the last message it has from the open-ils lists is from two days ago. https://georgialibraries.markmail.org/search/?q=
16:41 rhamby kmlussier: that's about the last time I think I saw a message
16:42 kmlussier There have been a few more about a record merging bug and the one I just sent out about baskets and shelves.
16:42 kmlussier http://libmail.georgialibraries.org/piper​mail/open-ils-general/2018-June/date.html
16:42 Dyrcona I got 6 messages on the general list yesterday and 1 today.
16:43 Dyrcona And, don't click a link when firefox is in the middle of updating itself. :)
16:44 Dyrcona That looks about right to me.
16:49 * jeff sends a virtual high-five to the one other person who submitted "lists" for the survey
16:53 Dyrcona :)
16:53 berick aww, a list of 2
16:53 Dyrcona '() is still a list. :)
16:54 Dyrcona Although there's nothing in't.
16:54 Dyrcona To paraphrase Lord Byron or somebody like that.
16:55 Dyrcona Yeah, Lord Byron...
16:55 Dyrcona https://www.brainyquote.co​m/quotes/lord_byron_161299
17:00 Dyrcona And with that, I'm signing out to reboot for a kernel update.
17:45 jeffdavis Byron's early contributions to the development of set theory are insufficiently known.
18:31 pinesol_green News from qatests: Testing Success <http://testing.evergreen-ils.org/~live>

| Channels | #evergreen index | Today | | Search | Google Search | Plain-Text | summary | Join Webchat