| Time |
Nick |
Message |
| 07:06 |
|
collum joined #evergreen |
| 07:58 |
|
kworstell-isl joined #evergreen |
| 08:11 |
|
BDorsey joined #evergreen |
| 08:17 |
|
cbrown joined #evergreen |
| 08:41 |
|
mmorgan joined #evergreen |
| 09:03 |
|
mmorgan1 joined #evergreen |
| 09:05 |
|
Dyrcona joined #evergreen |
| 09:42 |
abneiman |
Noting that I'm working on 3.12 and 3.13 point release notes right now, for those in a mergin' mood |
| 09:44 |
csharp_ |
abneiman++ |
| 09:47 |
csharp_ |
I'm using the EOLI migration tools eg_staged_bib_overlay script to re-import our full bib and authority records (no holdings on bibs) and it's working well, but slowly - I'm looking for ways to speed it up |
| 09:47 |
csharp_ |
is parallel-izing possible? |
| 09:48 |
csharp_ |
we're matching on bib ID since this was a MARC cleanup by a vendor on records we already have |
| 09:48 |
csharp_ |
I disabled symspell reify |
| 09:48 |
csharp_ |
and browse updates |
| 09:49 |
csharp_ |
(this is all on a test server at this point) |
| 09:49 |
Dyrcona |
You could split the input file up and run the import multiple times at once, each processing a different file of course. |
| 09:49 |
csharp_ |
but it was going slowly enough that I opened bug 2080802 |
| 09:49 |
pinesol |
Launchpad bug 2080802 in Evergreen "Add MARC write protection on bib and authority records" [Wishlist,New] https://launchpad.net/bugs/2080802 |
| 09:49 |
csharp_ |
Dyrcona: good |
| 09:50 |
Dyrcona |
Short of disabling triggers there's not much else you can do speed things up. A simple update on biblio.record_entry can take up to 2 to 5 seconds depending on the hardware and complexity of the record, number of linked authorities, etc. |
| 09:51 |
csharp_ |
yeah... |
| 09:51 |
csharp_ |
I was seeing times between 700/900ms before disabling the ingest indexing |
| 09:51 |
csharp_ |
1.5M bibs |
| 09:56 |
csharp_ |
I was walking all the way through indexing_ingest_or_delete() for where the hangups might be with limited succeess |
| 10:27 |
abneiman |
gmcharlt++ # release notes script |
| 10:40 |
|
BDorsey_ joined #evergreen |
| 10:44 |
|
mixo joined #evergreen |
| 10:46 |
mixo |
Hello. How can I set smtp settings in opensrf.xml with ssl or tls and authentification? |
| 10:59 |
Bmagic |
mixo: we usually handle SMTP stuff at the postfix/sendmail layer, and let Evergreen talk to localhost |
| 10:59 |
|
BDorsey joined #evergreen |
| 11:02 |
Bmagic |
ok eeevil: back at this search problem again. A new clue: I get the expected resutls when searching a different branch (branch ID 102) - which is odd, because the copy is attached to branch 103. I make a tiny tweak to the giant search query and I can make the database spit out the ibs I expect |
| 11:02 |
Bmagic |
search.calculate_visibility_attribute_test('circ_lib','{1,101,103,105}',FALSE) -- switching 103 over to 102 makes it "work" |
| 11:03 |
eeevil |
sounds like you've got a problem with your org tree. an org has wrong type, something like that |
| 11:03 |
Bmagic |
that's what I was thinking |
| 11:04 |
Bmagic |
but, of course, they are all fine |
| 11:04 |
Bmagic |
one difference was one had an address |
| 11:05 |
Bmagic |
ou_type = 3 for both, email address appears for 102 but not 103, phone is filled out for 102 but not 103 |
| 11:05 |
Bmagic |
maybe I need to give 103 an email and phone. I'll try |
| 11:07 |
Bmagic |
darn, I was hoping that would do it |
| 11:08 |
Bmagic |
maybe I need to run the badges calculation script |
| 11:09 |
mixo |
Bmagic thank you for answer. |
| 11:09 |
Dyrcona |
Bmagic: The orgs also have an opac visible flag. Is that true for both orgs? |
| 11:10 |
Bmagic |
yep, opac_visible all the way down from org_unit, to bib, to call number, to copy, and copy status |
| 11:10 |
Bmagic |
it shows up in search results at the consortium level |
| 11:10 |
Dyrcona |
Ok. Just mentioning the obvious because sometimes...y'know.... |
| 11:10 |
Bmagic |
but change the search scope to the branch (the branch that the copy is actually attached) and it doesn't come up |
| 11:11 |
Bmagic |
it's blowing my mind |
| 11:11 |
Dyrcona |
I'm with eeevil. Double check the branch has the correct type. You might also try reingest just that bib if you haven't done so already. |
| 11:11 |
Bmagic |
the latest clue is if I scope the sibbling branch (in the staff client) - I get results! even though the copy is attached to the other branch |
| 11:12 |
Bmagic |
yep, I've been reingesting like a madman |
| 11:12 |
Bmagic |
used pingest and ingest_ctl |
| 11:12 |
Dyrcona |
Bmagic: Is there a custom org. tree? |
| 11:14 |
Bmagic |
it's a simple setup: consortium node ID 1, system node, ID 101, 4 branches ID 104, 102, 103, 105. ou_type is 1 for consortium, 2 for system, 3 for the four branches |
| 11:15 |
Dyrcona |
Bmagic: Anything in actor.org_unit_custom_tree_node? |
| 11:15 |
Bmagic |
it's like I have a "bad" branch. When searched, it doesn't include all of the results |
| 11:15 |
Bmagic |
nothing in that table |
| 11:16 |
mmorgan1 |
Bmagic: Just back to what jihpringle said on Friday about the deleted flag in shelving location - you mentioned checking opac_visible, but not deleted. Worth a double check. |
| 11:16 |
Bmagic |
oooo, double checking |
| 11:16 |
Dyrcona |
mixo: If you have a host/service that already relays email for you, look up how to configure one of postfix/exim/sendmail as a "Smart host" to relay through that other server. You might want to check with whoever runs the mail relay to see if it is OK to do so. |
| 11:16 |
Bmagic |
select * from asset.copy_location where deleted -- no results |
| 11:17 |
mmorgan |
Ok! Double checked! |
| 11:21 |
mixo |
Dyrcona. Ok, thank you. |
| 11:27 |
Bmagic |
ok, how about this: "is_available" the copy status is, in fact, "In Processing" - would that do it? |
| 11:28 |
Bmagic |
why would a consortium search turn up the bib that has (only one copy attached btw) a copy that is "in process" but a branch-specific search wouldn't? |
| 11:30 |
mmorgan |
is_available = false should not hide the item at the branch. |
| 11:31 |
Dyrcona |
Bmagic: Might be an org unit setting involved, but I can't think of any specific one OTTOMH. |
| 11:44 |
Bmagic |
maybe a branch specific search defaults to "only show available" ? |
| 11:47 |
Bmagic |
or maybe "copy_active" |
| 11:50 |
Bmagic |
reading the postgres function, maybe I need to execute asset.all_visible_flags ? |
| 12:03 |
|
jihpringle joined #evergreen |
| 12:12 |
Bmagic |
I think this is it. I have other items that are "available" status at this branch and they are showing in branch-specific searches. Just not "In Process" (and only when scoped to that branch) |
| 12:18 |
Dyrcona |
I'm not familiar with the all_visible_flags function. |
| 12:20 |
Bmagic |
"I think this is it" - is the copy status playing a role in my issue. If the status doesn't have the property "copy_available" = TRUE, then the copy is not included in branch-specific searches |
| 12:20 |
|
jihpringle joined #evergreen |
| 12:21 |
Dyrcona |
Seems odd that it only affects branches, though. You could that function, looks like it is a simple wrapper to calculate visibility attributes. |
| 12:22 |
Dyrcona |
I missed a verb after "could." I think I meant to say, "You could try running that function." |
| 12:38 |
mmorgan |
Bmagic: There are limit to Available post search options in both public and staff catalog, filter gets added to the url. I'm not really sure how sticky those are. |
| 12:39 |
Bmagic |
the opac search does not have that flag set but nonetheless, when branch-specific scope is used, the non-available item isn't included |
| 12:40 |
Bmagic |
I'm going to see if the theory holds on other test systems |
| 15:31 |
|
blobmarley2 joined #evergreen |
| 15:34 |
|
scottangel joined #evergreen |
| 15:34 |
|
Jaysal joined #evergreen |
| 15:37 |
|
Dyrcona joined #evergreen |
| 15:45 |
berick |
dang, Ubuntu, you don't support Coordinated Lunar Time yet? |
| 15:56 |
eeevil |
I'm still waiting for https://en.wikipedia.org/wiki/International_Fixed_Calendar to catch on... |
| 15:59 |
sleary |
"... Eastman instituted its use at the Eastman Kodak Company in 1928, where it was used until 1989" OH MY |
| 15:59 |
sleary |
I bet that was a fun software upgrade |
| 16:02 |
berick |
"Year Day" does sound fun |
| 16:02 |
eeevil |
right? |
| 16:04 |
Dyrcona |
I don't know what the world may need, but I'm pretty sure a new calendar is not it. |
| 16:05 |
Dyrcona |
I had enough with primidi Thermidor 12.... |
| 16:06 |
pinesol |
News from commits: LP1740529 follow-up: release note and minor ng lint complaints <https://git.evergreen-ils.org/?p=Evergreen.git;a=commitdiff;h=585b07e1ec3f38de9ab328b853231416cdfda97a> |
| 16:06 |
pinesol |
News from commits: LP1740529 Dark mode for staff: toggle, color vars <https://git.evergreen-ils.org/?p=Evergreen.git;a=commitdiff;h=fd10c167d928661754e4d1ea3e8acbbf6bb8a151> |
| 16:06 |
eeevil |
aw, well ... how about deserialized browse entry ingest instead? https://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/miker/concurrent-browse-entry (csharp_, this is what I mentioned a few weeks back, and have finally had time to polish to the point of sharing) |
| 16:08 |
eeevil |
I have not LP'd it yet, but if anyone wants to start looking at it, please do. note: you probably will be scared off by the reification db function the first time you look at it. I was scared writing it. but, it seems to be doing the thing for me. |
| 16:09 |
Dyrcona |
"I dont' know what the world may need, but a V8 engine's a good start for me. I think I'll drive around and find a place to be surly." |
| 16:10 |
eeevil |
I read that as referring to the JS runtime, jfyi... |
| 16:11 |
Dyrcona |
Well, that works, too... I'll surf around and find a site to be surly. |
| 16:15 |
Dyrcona |
I kind of like the idea of intercalary days, though. It seems so quaint and complicated. ;) |
| 16:33 |
jeffdavis |
I don't have time to dig into it but that concurrent browse branch is exciting to see |
| 17:10 |
|
mmorgan left #evergreen |
| 18:52 |
|
jihpringle joined #evergreen |
