| 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.php?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=working/OpenSRF.git;a=shortlog;h=refs/heads/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 |
