| Time |
Nick |
Message |
| 04:00 |
|
berick joined #evergreen |
| 04:38 |
|
alynn26 joined #evergreen |
| 04:41 |
|
AFloyd__ joined #evergreen |
| 06:56 |
|
rfrasur joined #evergreen |
| 07:18 |
|
rjackson_isl_hom joined #evergreen |
| 07:37 |
|
Dyrcona joined #evergreen |
| 08:07 |
|
jvwoolf joined #evergreen |
| 08:32 |
|
mmorgan joined #evergreen |
| 08:36 |
|
jvwoolf joined #evergreen |
| 08:40 |
|
jvwoolf1 joined #evergreen |
| 08:47 |
|
Stompro joined #evergreen |
| 09:02 |
|
sandbergja joined #evergreen |
| 10:31 |
|
mantis1 joined #evergreen |
| 11:13 |
|
sandbergja_ joined #evergreen |
| 11:26 |
Bmagic |
Does the matching hold rule dictate "where" the item should be sourced? I'm running into a situation where the generic consortium rule is getting matched and the copy that is filling the hold is not from the pickup branch (there is an available copy that could fill the hold at the pickup branch) - my theory is that the hold rule is the culprit? |
| 11:26 |
|
collum joined #evergreen |
| 11:28 |
csharp |
Bmagic: the hold rule just checks that the hold is allowed at all - it doesn't affect which copy gets targeted |
| 11:29 |
Bmagic |
thought so! |
| 11:29 |
Bmagic |
csharp++ |
| 11:29 |
csharp |
so many moving parts |
| 11:29 |
csharp |
and the mechanism is far less happy with widespread closures in place |
| 11:31 |
Bmagic |
this library is still allowing "curb-side" pickup - the library is closed in the system, however, the YAOUS "Target copies for a hold even if copy's circ lib is closed" is on for the system. Maybe it needs to be set at the branch? |
| 11:33 |
csharp |
the setting should be inherited, I would think |
| 11:33 |
csharp |
perhaps hold boundaries should be set just for the branch? |
| 11:37 |
Bmagic |
I'm looking at HoldTargeter.pm |
| 11:37 |
Dyrcona |
Is the copy on the same volume/bib as the hold? |
| 11:37 |
Bmagic |
line 706 |
| 11:39 |
Bmagic |
it's confusing, but I think* $self->parent->get_ou_setting() climbs the tree |
| 11:39 |
csharp |
it should |
| 11:41 |
Dyrcona |
Bmagic: Which HoldTargeter.pm? |
| 11:41 |
Bmagic |
Utils |
| 11:42 |
Bmagic |
I see that it makes calls to the cache |
| 11:42 |
Bmagic |
I wonder if the issue is temporary while the cache is old |
| 11:43 |
miker |
Bmagic: if it's not already, you may need to set the related YAOUS that mentions the pickup library. they're orthogonal, not additive. |
| 11:44 |
Bmagic |
miker: a setting other than "Target copies for a hold even if copy's circ lib is closed" ? |
| 11:44 |
|
lisacarlucci joined #evergreen |
| 11:45 |
miker |
yes. not at a computer ATM, so can't look up the exact name |
| 11:46 |
Bmagic |
I wonder if the cache is caching that null setting for the branch and not checking the system level setting because the null setting already exists in cache? |
| 11:46 |
berick |
Bmagic: if get_ou_setting() was busted, we'd have a lot more problems |
| 11:47 |
Bmagic |
yeah - the implications of what I was saying would have been larger than this scenario |
| 11:52 |
|
rfrasur joined #evergreen |
| 11:53 |
Bmagic |
So the theory is that the cache was stale. The setting was changed 3/20. How long does it take to clear cache? It looks like the "cache" is variables in a running instance of Evergreen? my $c = $self->{ou_setting_cache}; or does that refer to memcached? |
| 11:54 |
berick |
Bmagic: that cache is created and destroyed with every instance of the targeter. |
| 11:54 |
Bmagic |
dang - that blows that out of the water |
| 11:59 |
|
alynn26_away joined #evergreen |
| 12:04 |
mmorgan |
Bmagic: I think you want this ou setting: "Target copies for a hold even if copy's circ lib is closed IF the circ lib is the hold's pickup lib" |
| 12:04 |
Bmagic |
I saw that - wasn't sure. I'l try that |
| 12:05 |
Dyrcona |
Bmagic: Are the hold and copy on the same bib and/or volume, depending on hold type. |
| 12:05 |
Bmagic |
bib hold, attached copy is available at pickup library |
| 12:05 |
Dyrcona |
Sometimes, people overlook this when it is the same title, but large print, etc., can skew things. |
| 12:06 |
Dyrcona |
Bmagic: It shows up in the hold copy map? |
| 12:06 |
Dyrcona |
If it's not there, nothing you do will make a difference. |
| 12:07 |
* Dyrcona |
is wrestling with dynamic queries for a homegrown function. |
| 12:09 |
|
jihpringle joined #evergreen |
| 12:19 |
|
mrisher joined #evergreen |
| 12:21 |
Dyrcona |
dow_0_open being Monday causes a slight headache with date math in the database. Since 0 is normally Sunday with EXTRACT..... |
| 12:26 |
Dyrcona |
Bleh.... Trying to figure out if a library is open on a given day or not from pure SQL is apparently harder than it sounds, at least in a generic way. |
| 12:36 |
|
Christineb joined #evergreen |
| 12:39 |
Dyrcona |
OK. It turns out not to be so hard if you coerce timestamps to dates to avoid the milliseconds on the close_start and close_end fields. :) |
| 12:58 |
|
ericar joined #evergreen |
| 13:05 |
|
rfrasur joined #evergreen |
| 13:13 |
Dyrcona |
For the curious, this is what I have been working on: https://pastebin.com/50ybEL9t |
| 13:42 |
mmorgan |
Dyrcona: So you're looking at hours open and days closed to get a library's next open date? |
| 13:44 |
Dyrcona |
mmorgan: Yes, and one of the functions needs a check to prevent an infinite loop when there are no hours of operation for the org unit. |
| 13:44 |
mmorgan |
Dyrcona++ |
| 13:45 |
Dyrcona |
I'll update the paste later when I decide which. I'm taking my lunch and afternoon breaks to walk the dog, now. |
| 13:45 |
rfrasur |
infinite_loop-- |
| 13:47 |
berick |
Dyrcona: I have some code in a pullrequest that does that. in Perl, though. |
| 13:47 |
* berick |
searches bugs |
| 13:49 |
berick |
bug 1829295 |
| 13:49 |
pinesol |
Launchpad bug 1829295 in Evergreen "Shelf expire date doesn't respect closed dates" [Wishlist,Confirmed] https://launchpad.net/bugs/1829295 |
| 13:50 |
berick |
don't know if that helps you at all, but seemed worth mentioning |
| 13:58 |
alynn26 |
exit |
| 14:39 |
|
khuckins joined #evergreen |
| 14:59 |
jeff |
berick++ |
| 15:12 |
|
rfrasur joined #evergreen |
| 15:13 |
Dyrcona |
berick: Cool. I'm want something that I can use from SQL. |
| 15:17 |
Dyrcona |
mmorgan: I updated the paste on pastebin with a shortcut for cases where the org_unit has no actor.hours_of_operation entry. It just returns TRUE. It could raise an error instead, but I think this works for what I want it to do. |
| 15:20 |
|
rfrasur joined #evergreen |
| 15:21 |
mmorgan |
Dyrcona: Great. What will you using it for? |
| 15:22 |
Dyrcona |
mmorgan: I'm going to update due dates, patron expiration dates, and a few other dates again. I plan to use the functions to take open and closed dates into account. |
| 15:22 |
mmorgan |
Ok, gotcha. |
| 15:31 |
|
rfrasur_ joined #evergreen |
| 15:56 |
|
mantis1 left #evergreen |
| 16:23 |
|
jihpringle joined #evergreen |
| 16:57 |
|
dbwells_ joined #evergreen |
| 17:01 |
miker |
Dyrcona: fwiw, evergreen.find_next_open_time() from the emergency closing handler code has something that attempts to detect "hours-of-operation closed" situations, if you're just looking for inspiration |
| 17:02 |
Dyrcona |
miker: I didn't know about that function. I can take a look tomorrow. (I'm off the clock, now, and what I have works so far.) |
| 17:02 |
|
rjackson_isl_hom joined #evergreen |
| 17:16 |
|
mmorgan left #evergreen |
| 17:23 |
|
rjackson_isl_hom joined #evergreen |
| 17:32 |
|
collum joined #evergreen |
| 19:20 |
|
collum joined #evergreen |
| 19:41 |
|
dbwells joined #evergreen |
| 22:24 |
|
collum joined #evergreen |
| 22:24 |
|
sandbergja joined #evergreen |
| 22:56 |
|
sandbergja joined #evergreen |
