| Time |
Nick |
Message |
| 00:07 |
|
jvwoolf joined #evergreen |
| 00:35 |
|
jeff__ joined #evergreen |
| 07:05 |
|
rfrasur joined #evergreen |
| 07:21 |
|
rjackson_isl_hom joined #evergreen |
| 08:15 |
|
alynn26 joined #evergreen |
| 08:22 |
|
mantis1 joined #evergreen |
| 08:24 |
|
rfrasur joined #evergreen |
| 08:28 |
|
Stompro joined #evergreen |
| 08:37 |
|
mmorgan joined #evergreen |
| 08:45 |
|
collum joined #evergreen |
| 08:56 |
|
Dyrcona joined #evergreen |
| 09:50 |
|
laurie joined #evergreen |
| 09:55 |
|
jvwoolf joined #evergreen |
| 10:39 |
|
jvwoolf1 joined #evergreen |
| 10:52 |
|
Christineb joined #evergreen |
| 12:04 |
|
sandbergja joined #evergreen |
| 12:12 |
|
mrisher joined #evergreen |
| 12:21 |
|
jihpringle joined #evergreen |
| 12:33 |
Bmagic |
Dyrcona: my problem with crad is: The options in the dropdown menu eg/staff/admin/server/config/coded_value_map for "Sound recording format" are incomplete. It seems it's a subset of select * from config.marc21_physical_characteristic_value_map where ptype_subfield=62 |
| 12:37 |
* Dyrcona |
shrugs. |
| 12:38 |
Bmagic |
I can't seem to find the code that filters that list down to what is finally displayed. |
| 12:38 |
Bmagic |
I would like to specify an option that's not listed - and if I manually update the JSON in config.composite_attr_entry_definition - it breaks |
| 12:40 |
Dyrcona |
Does the option you want exist in the database for the index you're trying to modify? If not, you'll have to add it. |
| 12:40 |
Bmagic |
it exists in config.marc21_physical_characteristic_value_map |
| 12:41 |
Bmagic |
does it need to be defined elsewhere? |
| 12:42 |
Bmagic |
looking at the code from composite_attr_entry_definition.js. Section following function buildSelectors() |
| 12:50 |
Bmagic |
.... found it! |
| 12:50 |
Bmagic |
select * from config.coded_value_map where ctype='sr_format' |
| 12:50 |
Bmagic |
only those options are displayed |
| 12:51 |
Bmagic |
and not the full definition from config.marc21_physical_characteristic_value_map |
| 12:56 |
Dyrcona |
Bmagic: There are a number of interconnected tables involved in all of that. If something is used by sr_format, but you want it for something else, you'll have to add the appropriate entries for that something else. |
| 12:57 |
Bmagic |
Thanks for being my duck! |
| 12:57 |
Dyrcona |
Bmagic: I also don't feel qualified at the moment to try and explain how all of that works at the moment. It has been a long time since I last looked at it in depth. |
| 12:57 |
Dyrcona |
Quack! |
| 12:58 |
Dyrcona |
At the moment, I'm apparently tired or distracted.... :) |
| 12:58 |
Bmagic |
it's probably a.... virus.... |
| 13:04 |
Dyrcona |
Hope not. |
| 13:05 |
Dyrcona |
:) |
| 13:12 |
|
sandbergja joined #evergreen |
| 13:21 |
|
jvwoolf joined #evergreen |
| 13:58 |
Dyrcona |
Really? This is timing out? Returning NULL from app_request_recv after timeout: open-ils.actor.ou_setting.ancestor_default.batch [281,["opac.holds.org_unit_not_pickup_lib","credit.payments.allow"] |
| 13:59 |
Dyrcona |
Not even close to max connections... |
| 14:01 |
Dyrcona |
Well... Emergency closing stuff have been running for about 20 minutes and a couple of autovacuums almost as long. |
| 14:01 |
|
jvwoolf1 joined #evergreen |
| 14:12 |
Dyrcona |
Oh... This is not good: 31 days 00:31:46.144166 |
| 14:13 |
Dyrcona |
SELECT * FROM action.emergency_closing_stage_2_circ( '62708' ) |
| 14:13 |
Dyrcona |
That's been for over 31 days! |
| 14:13 |
|
khuckins joined #evergreen |
| 14:21 |
Dyrcona |
Four processes related to the emergency closing handler running for 5+ days. Three of them running for just over 31 days. I canceled the back ends in postgres. |
| 14:29 |
Dyrcona |
Ha! And, now there's another one running for about 8 minutes from the same brick as the others. Why do I think I'll find it still running tomorrow? |
| 14:30 |
|
jihpringle joined #evergreen |
| 14:32 |
jeffdavis |
Most of our libraries have done emergency closures and we haven't seen anything that long-running. |
| 14:33 |
Dyrcona |
We're on 3.2, and we've upgraded many times over the years. We're probably missing some expected indexes or something. |
| 14:39 |
rhamby |
make sure the library hasn't set all their hours to closed |
| 14:43 |
csharp |
Dyrcona: I've seen that on PINES, more than once |
| 14:44 |
csharp |
(3.4) |
| 14:47 |
Dyrcona |
We have some stupid stuff in library dates, like a library that has hours of operation for every day, then scads of entries in closed dates for Wednesday..... |
| 14:48 |
csharp |
yeah - we had to address that before too |
| 14:53 |
Dyrcona |
Hey! We have 9 libraries with no hours of operation, though I didn't check their parent_ou, yet. |
| 14:54 |
Dyrcona |
I guess hours of operation don't inherit, do they? |
| 14:55 |
alynn26 |
not that I am aware of. |
| 15:01 |
csharp |
no, they don't |
| 15:01 |
csharp |
if you're entering them, and click "apply to all my libraries" (or whatever the actual wording is) it creates closing for child branches, though |
| 15:02 |
csharp |
*closings |
| 15:04 |
Dyrcona |
Yeah, I was talking about hours of operation and not closings, but that's good to know, too. |
| 15:04 |
Dyrcona |
GIGO |
| 15:28 |
|
dbwells joined #evergreen |
| 15:32 |
|
dbwells joined #evergreen |
| 15:42 |
|
mantis1 left #evergreen |
| 16:08 |
|
dbwells_ joined #evergreen |
| 16:23 |
|
alynn26_away joined #evergreen |
| 16:26 |
|
dbwells joined #evergreen |
| 16:27 |
|
rfrasur joined #evergreen |
| 16:29 |
|
jvwoolf joined #evergreen |
| 16:38 |
|
AFloyd__ joined #evergreen |
| 17:19 |
|
sandbergja joined #evergreen |
| 17:27 |
|
mmorgan left #evergreen |
| 17:52 |
|
mrisher joined #evergreen |
| 18:00 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 19:54 |
|
jvwoolf joined #evergreen |
| 20:39 |
|
jvwoolf joined #evergreen |
| 20:52 |
|
alynn26_away joined #evergreen |
| 21:27 |
|
sandbergja joined #evergreen |
| 23:31 |
|
jvwoolf joined #evergreen |
| 23:32 |
|
Stompro joined #evergreen |
