Evergreen ILS Website

IRC log for #evergreen, 2016-10-31

| 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
07:13 rjackson_isl joined #evergreen
07:14 JBoyer joined #evergreen
07:24 agoben joined #evergreen
07:28 kmlussier joined #evergreen
08:28 kmlussier Good morning #evergreen!
08:29 jeff good morning!
08:35 collum joined #evergreen
09:05 bos20k joined #evergreen
09:10 Dyrcona joined #evergreen
09:10 finnx joined #evergreen
09:11 mmorgan joined #evergreen
09:28 yboston joined #evergreen
09:49 jvwoolf joined #evergreen
09:58 collum_ joined #evergreen
09:58 collum joined #evergreen
10:03 mmorgan1 joined #evergreen
10:07 Bmagic If someone has overdues - does the system ignore their holds when it comes time to capture?
10:08 Bmagic oh wait - that would be "capture" in the penalty list
10:16 tsbere Bmagic: That it would. So it would depend on whether or not you want the hold to not capture.
10:17 tsbere Bmagic: I think we generally allow capture, but not fulfillment, so that when they go to pick the item up they can be asked to pay their fines...
10:17 Bmagic Im trying to think of reasons why a newer hold would capture before an older hold.
10:21 abneiman Did someone set it top of queue? Or was the older hold suspended when new one was captured?  Those both happened at my former library with regularity. (we also had capture blocked for patrons who exceeded max fines)
10:22 Bmagic Both title level. Both at the same library. Both have the same set of copies in the map. Where do I see the "top of queue" information?
10:22 tsbere Bmagic: Hold priorities on patron types, org unit proximity, older hold was skipped due to a different block in place...
10:22 abneiman If you're in the staff client on the holds screen it should be a column picker option
10:26 Bmagic When looking at queue position on the bib, I can see the that the patron that should have recieved the copy, is at the top of the queue. But instead, the system skipped everyone and chose the lowest patron on the queue. The first 3 holds are suspended
10:30 jeff holds have lots of state. even if you look at all possible inputs now and it doesn't make sense, it may have (and likely did) made sense at the time: holds that were suspended/unsuspended, copies that changed status after some holds had been targeted and the new hold was placed before those earlier holds automatically retargeted, etc.
10:30 jeff which is not to encourage you to give up on looking into this specific case, but just to caution against tearing your hair out *too* much. :-)
10:31 jeff (unless you really really love a mystery enough to take it to extremes, which is something that i assure you nobody here has ever done, never-ever.)
10:32 Bmagic lol
10:32 Bmagic This occurred 1 hour ago
10:33 Bmagic The data has probably not changed that much. Considering the ILS skipped 15 holds and chose the last one on the list makes me wonder.....
10:33 tsbere How old is the copy?
10:34 Bmagic 35 days old
10:34 Bmagic sorry, 65 days old
10:35 tsbere Does the hold that was captured have the cut in line flag set? (I don't think you mentioned that one way or another yet)
10:36 Dyrcona Bmagic: Was the copy recently in a non-holdable state? If so, did it come out of that state near the time that the last hold would have been retargeted, but not the others?
10:36 Dyrcona That exact thing happened here just last week.
10:36 Bmagic action.hold_request? cut_in_line - that column is null for both
10:37 Bmagic Recently in a non-holdable state... let me look at history
10:37 Bmagic I suppose that would be asset.copy -> holdable ? and asset.copy_location -> holdable
10:38 tsbere Bmagic: Or even just the copy's own holdable flag, for that matter.
10:40 Bmagic the entire history for that copy has holdable=true. The copy location is holdable...
10:41 rjackson_isl Probably not an issue here but thought I would mention - we recently migrated a library and had the selection_depth set to 2 instead of 0 - I think this messed up the proximity rows and resulted in a similar issue as you are describing
10:42 Bmagic both patrons have the same profile. Niether is expired. Niether is barred or inactive
10:43 Dyrcona Bmagic: Status, too. My case was a damaged copy that was checked in at 11:45 am and we to reshelving, then was targeted around 1:30 pm, and checked in again at 3:26 pm.
10:44 Bmagic I thought of status. The status of the copy that was checked in was checked out, reshelving, on holds shelf, rinse repeat for weeks
10:44 sandbergja joined #evergreen
10:46 Bmagic Would suspended holds at the top of the queue introduce a bug at all? I mean, there are clearly 15 holds that should have filled before this one at the end. It's strange that it's the very last hold that was fililed. Makes me get that "buggy" feeling
10:48 tsbere Bmagic: They should just have been skipped, no other effects. Though it could be that the others *were* suspended, but aren't now.....though now that I think about it, you may want to check the mint_condition flag on the copy and holds.
10:49 Bmagic let me take a look at that
10:49 tsbere Bmagic: And, of course, the selection depth, as previously mentioned.
10:51 * Dyrcona thinks we should drop the mint condition field and the code for it, but I'm sure that others disagree. ;)
10:51 Dyrcona @band The Mint Condition
10:51 pinesol_green Dyrcona: http://wonder-tonic.com/geocitiesizer/content.ph​p?theme=2&music=6&url=evergreen-ils.org
10:51 csharp hmm - seeing issues running the 2.9.3-2.10.0-upgrade-db.sql script - it's apparently not ok with the the "DO" section of 0945
10:51 Bmagic The only difference between the two rows in action.hold_request is the hold ID, Request date, and prev_check_time
10:52 Bmagic mint condition is true for both
10:52 csharp psql:2.9.3-2.10.0-upgrade-db.sql:296: ERROR:  cannot alter type of a column used by a view or rule
10:52 csharp DETAIL:  rule _RETURN on view demographic depends on column "dob"
10:52 Dyrcona csharp: You probably have a custom view that needs to be dropped and recreated.
10:53 csharp so even though we drop reporter.demographic in the DO section, it apparently doesn't care about that
10:53 Dyrcona I had a number that I had to drop because of that and other changes.
10:54 Dyrcona A DO section is like a transaction. I think you'll have to drop it before the DO.
10:54 csharp Dyrcona: that's what I was thinking, but I was surprised I'd be the first to hit that issue :-/
10:55 Dyrcona I didn't that one. We don't have that view.
10:55 Dyrcona I hit several other custom views, over a dozen, that I had to drop and recreate.
10:56 Dyrcona Since they were all custom views, I didn't bother mentioning it to anyone else. ;)
10:57 Dyrcona I used this to save viewdefs as they came up: select 'create view ' || :'view' || ' as ' || pg_get_viewdef(:'view', true);
10:58 Dyrcona Put that in a SQL fiel and run it like psql -f file.sql -v view=view_name >> create_viewdefs.sql
10:58 csharp well, reporter.demographic is in stock EG - right now I'm seeing if there's a custom rule
10:58 csharp Dyrcona: thanks for the tips here, btw
10:58 Dyrcona I didn't think it was stock.
10:58 tsbere Dyrcona: For certain definitions of stock
10:58 tsbere Dyrcona: It doesn't load by default, but it is there in the files
10:58 Dyrcona Well, I was getting to that. :)
10:59 Dyrcona Stock/custom. :)
10:59 berick the lack of an "IF EXSISTS" on the DROP VIEW for reporter.demographic suggests it's installed everywhere
10:59 Dyrcona Well, I don't have it. :)
11:00 tsbere Huh. I thought that was in those extra pines views.
11:00 Dyrcona I believe it is.
11:00 * tsbere doesn't tend to use it either way as most of our patrons have missing or incorrect DOB entries anyway...
11:00 berick it's in reporter-schema.sql, loaded by default
11:01 Dyrcona For certain definitions of default.... :)
11:01 jeff we have reporter.demographic and i do not have record of running into issues when upgrading to 2.10. i show 0945 as applied.
11:02 jeff csharp: what version of postgres are you running? we're on 9.4.
11:02 csharp jeff: 9.4 here too
11:02 Dyrcona I didn't have any issue with that particular view, but I don't have it.
11:02 jeff okay, that probably eliminates one possibility.
11:03 jeff csharp: what does "\d+ reporter.demographic" look like for you?
11:03 berick Dyrcona: appears it was never part of an upgrade script :(
11:04 Dyrcona berick: I guess not.
11:04 Dyrcona I don't see it in a concerto database, either.
11:04 berick but it is part of the stock schema if you install today
11:04 berick it's in my dev VM's
11:05 Dyrcona Doh.
11:05 jeff reporter.demogorgon
11:05 Dyrcona Yeah, I typed \df by mistake. :)
11:05 Dyrcona jeff++
11:05 Dyrcona It's there in my concerto db.
11:05 * berick nods
11:05 csharp jeff: http://pastebin.com/Z7j5aHV8
11:05 Dyrcona And, I do have it on my training database.
11:07 berick csharp: maybe you have another custom view that uses reporter.demographic?
11:08 Dyrcona Yeah, I ran into that. I had to drop some views because they used another view that I had to drop.
11:08 jeff would it be safe and effective to BEGIN a transaction and attempt to drop that view, in order to see if it is relied upon by another?
11:08 Dyrcona Stupid me... I have reporter.demographic in production, too.
11:09 Dyrcona Dyrcona--
11:09 berick heh
11:09 bshum That custom classic_current_circ uses it with a join
11:09 bshum So does classic_current_billing_summary
11:09 berick bshum: those are handled by the upgrade.
11:09 bshum Hmm
11:09 berick i think csharp may have some other unknown stuff using the view
11:10 bshum There's always something :)
11:10 berick jeff: i think that would work
11:11 jeff unless it stops at the first dependent...
11:11 Dyrcona That's why I wrote that little script.
11:12 Dyrcona I'd try to drop a view and find one or two others.
11:13 jeff looks like it does not stop at first dependent on 9.3 and up.
11:20 mmorgan joined #evergreen
11:21 csharp looks like just the two already-accounted-for views depend on reporter.demographic
11:21 Christineb joined #evergreen
11:21 berick nice, 20(+) hackaway attendees
11:22 berick csharp: what happens if you BEGIN; DROP VIEW repoter.demographic; ROLLBACK;
11:22 berick does it give any more details?
11:22 berick well, hmm
11:23 berick not sure that's really the thing
11:23 csharp that's how I see those
11:23 berick k
11:23 csharp I'm going to try moving the DROP VIEW outside of the DO and see what happens
11:25 brahmina joined #evergreen
11:26 csharp bizarre - after doing that, it still complains with the same error
11:26 csharp the view has already been dropped before the DO starts
11:26 berick still in the same transaction, though
11:26 Dyrcona csharp: You are dropping the views that depend on reporter.demographic, right?
11:26 csharp Dyrcona: yep
11:26 berick assuming the drop happens after the BEGIN
11:26 berick at the top of the file
11:27 csharp berick: right
11:27 csharp this is why I'm having trouble with the idea that I'm the first to see this
11:27 csharp but whatever :-)(
11:27 Dyrcona I didn't have any trouble with that view upgrading from 2.9.5 to 2.10.7.
11:28 Dyrcona I made a custom upgrade script using make_release.
11:28 csharp I'm going to try just applying the 0945 script on its own
11:28 csharp as an experiment
11:29 Dyrcona I did have to drop and recreate 25 local, custom views, though.
11:29 Dyrcona I did that outside of the upgrade script.
11:30 csharp nope - that doesn't work either
11:33 csharp ...and there's not a rule in pg_rules that has anything to do with reporter.demogorgon
11:41 csharp ooooooooh
11:41 csharp there's another view - public.demographic
11:41 csharp ugh
11:42 csharp literally the same view
11:42 csharp ok - I'mma drop that and all should work as expected
11:42 csharp thanks to all who helped!
11:43 jeff postgresql TRIED to tell us: DETAIL:  rule _RETURN on view demographic depends on column "dob"
11:43 tsbere wouldn't it be nice if it bothered to tell us schemas in those messages? >_>
11:58 Dyrcona joined #evergreen
12:13 jihpringle joined #evergreen
14:22 dbs whither sqitch
14:25 berick heh
14:34 phasefx hrmm, I tried to assign myself a bug and got Service Unavailable
14:40 * mmorgan was able to mark a bug as 'affects me' just a little while ago.
14:42 kmlussier phasefx: No bugs for you!
14:42 mmorgan :)
14:46 phasefx my chaos powers spread
14:49 phasefx worked that time :D
15:33 csharp @developer
15:33 pinesol_green csharp: Communication:12, BigPicture:14, DetailOriented:12, KungFu:14, GetsStuffDone:11, FlakeFactor:6, JavaAvoidance:11
15:34 berick CheetoPowderCoverage:15
15:38 csharp berick++
15:38 * csharp blows it out of the keyboard, wipes on pants leg
15:49 * bshum eats his cheetos with a fork
15:49 berick a salad fork
15:52 kmlussier bshum: Do you really?
15:52 bshum kmlussier: Often, though when I get to the bottom of the bag and the tiny broken bits, I'll admit a spoon is easier to use than a fork.
15:53 berick bshum: stab them or scoop them?
15:53 bshum berick: Scoop I guess.
15:53 berick ah, ok
15:53 bshum Stabbing Cheetos is hard.  They're very brittle.
15:54 berick that's what I feared
15:54 bshum Well, depends on the Cheetos I guess....
15:54 bshum The puff kind are fun to stab :D
15:54 mmorgan and the stabbing implement!
15:56 * bshum prefers "crunchy" Cheetos
15:56 kmlussier Wow, the thought of eating any kind of bagged snack with a fork or spoon never crossed my mind.
15:56 bshum kmlussier:  Lays potato chips by sliding the wafer between each prong of the fork :)  The fun part was seeing how many you could grab on the same pass :D
15:57 * kmlussier prefers the puffy kind.
15:57 * bshum might be too meticulous for his own good
15:57 berick gmcharlt: FYI @ http://git.evergreen-ils.org/?p=worki​ng/OpenSRF.git;a=shortlog;h=refs/head​s/user/berick/nginx-ws-and-http-proxy
15:58 gmcharlt berick++
15:58 kmlussier bshum: I was thinking sophisticated. :)
15:59 kmlussier Now that I think about it, though, I suppose sophisticated people wouldn't eat Cheetos.
17:03 mmorgan left #evergreen
17:08 pinesol_green [opensrf|Mike Rylander] LP#1631520: configure install location of Perl modules - <http://git.evergreen-ils.org/?p​=OpenSRF.git;a=commit;h=b6557d6>
17:18 jvwoolf left #evergreen
17:26 pinesol_green [opensrf|Bill Erickson] LP#1473479 Syslog configuration adoption - <http://git.evergreen-ils.org/?p​=OpenSRF.git;a=commit;h=34038f2>
17:28 berick woohoo
17:30 pinesol_green [opensrf|Ben Shum] Docs: Add Xenial references in the websocket setup instructions - <http://git.evergreen-ils.org/?p​=OpenSRF.git;a=commit;h=e3f9b6a>
17:30 pinesol_green [opensrf|Ben Shum] Docs: Change 14.04 to Trusty in README - <http://git.evergreen-ils.org/?p​=OpenSRF.git;a=commit;h=15f8c53>
17:30 pinesol_green [opensrf|Ben Shum] LP#1603708: Remove support for Ubuntu 12.04 Precise - <http://git.evergreen-ils.org/?p​=OpenSRF.git;a=commit;h=7842338>
17:45 berick gmcharlt++
18:56 hbrennan joined #evergreen
21:21 * jeff tries to think of what hardware he's wished for at past hackfests/hack-a-way
21:35 jeff barcode scanner, rfid pad, laptop approximating a circ workstation in terms of hardware and os... receipt printer...
21:43 jeff barcodes, tags, power strip...
21:44 jeff might well stay in the trunk of the rental car, but just in case...
23:46 Christineb joined #evergreen

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