| Time |
Nick |
Message |
| 03:44 |
|
sard joined #evergreen |
| 06:32 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
| 07:14 |
|
rjackson_isl joined #evergreen |
| 07:45 |
|
dwgreen joined #evergreen |
| 08:35 |
|
mmorgan joined #evergreen |
| 08:38 |
|
Dyrcona joined #evergreen |
| 08:59 |
|
bos20k joined #evergreen |
| 09:08 |
|
kmlussier joined #evergreen |
| 09:15 |
kmlussier |
Oh phooey! I gave a +1 to rescheduling the developers meeting without first looking at my calendar. Looks like I won't be able to attend. |
| 09:16 |
rhamby |
calendars-- |
| 09:30 |
|
yboston joined #evergreen |
| 09:58 |
rhamby |
kmlussier++ : for eagle eyes |
| 10:01 |
|
mmorgan1 joined #evergreen |
| 10:20 |
|
rlefaive joined #evergreen |
| 10:36 |
|
littlet joined #evergreen |
| 10:40 |
|
bos20k joined #evergreen |
| 10:43 |
kmlussier |
When renaming an org unit, I've noticed that it takes a long time for web client displays to update to the new name, even after running autogen, clearing cache, restarting apache, etc. |
| 10:44 |
berick |
kmlussier: the client caches org units specifically at the session level. you have to close all tabs. |
| 10:45 |
kmlussier |
berick: Ah, ok. Good to know. Thanks! |
| 10:59 |
|
mmorgan joined #evergreen |
| 11:10 |
|
rlefaive_ joined #evergreen |
| 11:11 |
|
littlet joined #evergreen |
| 12:09 |
|
rlefaive joined #evergreen |
| 12:18 |
|
collum joined #evergreen |
| 12:32 |
|
khuckins joined #evergreen |
| 12:47 |
|
jvwoolf joined #evergreen |
| 12:58 |
|
littlet joined #evergreen |
| 13:18 |
* Dyrcona |
considers adding an alias suod=sudo |
| 13:23 |
kmlussier |
heh |
| 13:40 |
jeff |
Dyrcona: do you really want to give your typos elevated privileges? |
| 13:40 |
Dyrcona |
Just that one. :) |
| 13:41 |
Dyrcona |
Trouble is I usually make it on vms that will be replaced soonish anyway, so no real point in having the alias. |
| 13:41 |
jeff |
or are we going to veer off into prob&stats discussion on if you're more or less likely to have a typo later in the line after that typo? :-) |
| 13:41 |
Dyrcona |
heh. :) |
| 13:49 |
Bmagic |
@later tell hbrennan We are on 3.0.2 and now I understand what you are talking about! |
| 13:49 |
pinesol_green |
Bmagic: The operation succeeded. |
| 13:50 |
berick |
@last --from hbrennan |
| 13:50 |
pinesol_green |
berick: Error: I couldn't find a message matching that criteria in my history of 1000 messages. |
| 13:51 |
Dyrcona |
@seen hbrennan |
| 13:51 |
pinesol_green |
Dyrcona: hbrennan was last seen in #evergreen 1 week, 6 days, 15 hours, 38 minutes, and 4 seconds ago: <hbrennan> omg, night people! Hi! |
| 13:56 |
abowling1 |
exit |
| 14:00 |
|
rlefaive joined #evergreen |
| 14:03 |
|
kmlussier joined #evergreen |
| 14:07 |
|
rlefaive joined #evergreen |
| 14:09 |
|
rlefaive joined #evergreen |
| 14:10 |
Dyrcona |
Should some of the changes to the 2.12.6 to 3.0.0 upgrade script from Lp 1719726 be backported to the numbered upgrade scripts? |
| 14:10 |
pinesol_green |
Launchpad bug 1719726 in Evergreen "updates to monolithic schema update script for 3.0-rc" [Medium,Fix released] https://launchpad.net/bugs/1719726 |
| 14:23 |
kmlussier |
+1 |
| 14:27 |
Dyrcona |
@seen tsbere |
| 14:27 |
pinesol_green |
Dyrcona: tsbere was last seen in #evergreen 14 weeks, 5 days, 0 hours, 19 minutes, and 5 seconds ago: <tsbere> I dunno. If a bug gets enough positive karma does it evolve into a feature? |
| 14:27 |
|
rlefaive joined #evergreen |
| 14:28 |
kmlussier |
We should make that a quote. If we haven't done so already. |
| 14:28 |
kmlussier |
@quote search feature |
| 14:28 |
pinesol_green |
kmlussier: 1 found: #173: "<tsbere> I dunno. If a bug gets enough positive..." |
| 14:28 |
kmlussier |
heh |
| 14:28 |
Dyrcona |
:) |
| 14:28 |
Dyrcona |
tsbere++ # Just 'cause. |
| 14:29 |
kmlussier |
tsbere++ |
| 14:29 |
csharp |
tsbere++ |
| 14:30 |
|
rlefaive joined #evergreen |
| 14:41 |
|
jvwoolf1 joined #evergreen |
| 15:09 |
|
rlefaive joined #evergreen |
| 15:18 |
|
rlefaive joined #evergreen |
| 15:32 |
|
StomproJ joined #evergreen |
| 15:33 |
|
dpearl1 joined #evergreen |
| 15:37 |
|
cesardv_ joined #evergreen |
| 15:37 |
|
mnsri joined #evergreen |
| 15:37 |
|
drigney joined #evergreen |
| 15:37 |
|
bshum joined #evergreen |
| 15:40 |
|
phasefx joined #evergreen |
| 15:45 |
|
RBecker joined #evergreen |
| 15:55 |
jeffdavis |
I'm puzzled that the fix for bug 1736419/1730758 is working for others but not on my test system |
| 15:55 |
pinesol_green |
Launchpad bug 1736419 in Evergreen "Search Showing Bibs with no Holdings" [High,Confirmed] https://launchpad.net/bugs/1736419 |
| 15:56 |
* mmorgan |
is puzzled about that, too. |
| 15:59 |
jeffdavis |
https://upstream.catalogue.libraries.coop/eg/opac/record/249 is a record with a located URI at BR1, but the record doesn't show up in a catalog search on that server. |
| 16:02 |
mmorgan |
I'm trying to understand the vis_attr_vector fields. What do the very large integers in those fields refer to? |
| 16:04 |
jeffdavis |
mmorgan: hmm, for records with located URIs and no holdings I only have very small values in vis_attr_vector - e.g. the record above has {4} in there which is the actor.org_unit.id of the located URI location |
| 16:06 |
mmorgan |
jeffdavis: Yes, I see similar for most records with located uris and no holdings, but some also show, for example: {268435571,74} |
| 16:07 |
kmlussier |
jeffdavis / mmorgan: Before the fix was even added, I was puzzled that people saw different behavior in the original bug report. |
| 16:08 |
mmorgan |
jeffdavis: is your test system a fresh install of 3.0? |
| 16:08 |
mmorgan |
Ours is an upgrade. |
| 16:10 |
jeffdavis |
Ours a fresh 3.0.2 install with concerto data. |
| 16:12 |
jeffdavis |
kmlussier: yeah, good point |
| 16:17 |
kmlussier |
mmorgan: And you don't see a difference between new Located URI records and ones that were there before the upgrade? |
| 16:19 |
mmorgan |
Not since I applied the patch, but I'll try adding another one. |
| 16:23 |
Bmagic |
what is the difference between the 901a and 901c ? They seem like they are always the same. I was thinking one was the ID and the other was TCN but I am not finding that to be true |
| 16:25 |
jeffdavis |
Bmagic: looking at evergreen.maintain_901, seems like 901a is TCN and 901c is ID |
| 16:25 |
jeff |
Bmagic: a is the tcn, c is the id. |
| 16:26 |
Bmagic |
jeffdavis: weird because I am looking at a row where the tcn_value != id and the 901a == 901c |
| 16:26 |
jeff |
keep in mind there are various knobs that can control that, and if you disable triggers at insert time for a migration and don't go back and re-ingest, that can impact things also. |
| 16:26 |
Bmagic |
found many examples where 901a != tcn_value |
| 16:27 |
Bmagic |
no biggie - just curious |
| 16:27 |
jeff |
Bmagic: recently edited bibs? |
| 16:27 |
Bmagic |
well, these are 2013.... let me check some more recent ones |
| 16:28 |
Bmagic |
oh boy I come up empty looking for anything newer than 2014. Nevermind then! |
| 16:28 |
Dyrcona |
Bmagic: Did you ever change "cat.bib.use_id_for_tcn"? |
| 16:28 |
jeff |
one such knob that can impact if 901a == 901c is the global flag cat.bib.use_id_for_tcn |
| 16:28 |
mmorgan |
kmlussier, jeffdavis: I just added a new record with an 856 and $9, but the uri isn't being generated for some reason. So I'm not retrieving it in the public catalog. |
| 16:29 |
jeff |
mmorgan: correct indicators? 4 and 1 (or 0?) iirc? |
| 16:29 |
Dyrcona |
Bmagic: select * from config.internal_flag where name = 'cat.bib.use_id_for_tcn'; -- should return enabled = 't' |
| 16:29 |
mmorgan |
4 and 0 - oops. Think I see the problem. |
| 16:30 |
Bmagic |
Dyrcona: yeah, checked that after you mentioned it. It is enabled on the db but I don't have a date when it was enabled |
| 16:30 |
Dyrcona |
or maybe 'f'depending on what you're actually seeing. My guess is that was changed at some point in the past. |
| 16:30 |
Dyrcona |
Bmagic: It is enabled by default, but may have been disabled for a record load or something. |
| 16:31 |
Bmagic |
gotcha |
| 16:32 |
mmorgan |
Helps if the $u is included :) |
| 16:33 |
jeff |
aiui, oclc libs dislike cat.bib.use_id_for_tcn. |
| 16:33 |
jeff |
but i could be mistaken. |
| 16:33 |
Dyrcona |
Bmagic: There's no harm in fixing the bres with update set tcn_value = id where tcn_value <> id |
| 16:33 |
jeff |
either way, i wouldn't change it without thinking. |
| 16:33 |
Dyrcona |
jeff: Could be...We've used it at MVLC and C/W MARS and both use OCLC for records. |
| 16:34 |
Dyrcona |
LoC recommends you use it. :) |
| 16:34 |
jeff |
Dyrcona: they do? |
| 16:35 |
jeff |
it's been a little while since I was last looking at this, but I'm surprised that they have any recommendation on a 9xx tag. |
| 16:35 |
Dyrcona |
jeff: I recall reading something from LoC that recommended you change the 001 on import and add an 035$a. |
| 16:35 |
Dyrcona |
jeff: We're not quite talking about the same thing. :) |
| 16:35 |
jeff |
Dyrcona: i think you're confusing flags. that sounds like you're talking about cat.maintain_control_numbers. |
| 16:36 |
Dyrcona |
No, you're talking about cat.maintain_control_numbers, me thinks. |
| 16:36 |
mmorgan |
kmlussier, jeffdavis: I can retrieve my newly created record in the opac. The link is not showing at the cons level, but the record is retrieved in a search. |
| 16:36 |
Dyrcona |
Or, rather, I think the flag you mentioned affects the behavior of both. |
| 16:38 |
kmlussier |
mmorgan: The link isn't displaying at the cons level? That's strange. In the previous testing, the problem only seemed to affect what was retrieved in searches, not the link display. |
| 16:39 |
mmorgan |
Yes, I hadn't noticed that before. |
| 16:40 |
* csharp |
confirms that OCLC libraries set cat.bib.use_id_for_tcn = false |
| 16:40 |
Dyrcona |
I think you've confirmed that an OCLC library/consortium sets it to false. |
| 16:41 |
Dyrcona |
We ran into issue with duplicate TCNs during our migration from Horizon at MVLC, so we had to set it true just to load records. :) |
| 16:41 |
csharp |
our libraries (at least) expect tcn_value to be the OCLC accession number |
| 16:42 |
Dyrcona |
That's good. It could help prevent duplication of records at least. :) |
| 16:42 |
csharp |
yeah, that's at the foundation of our dedupe policies |
| 16:42 |
jeff |
i can vouch for a second OCLC library that sets it to cat.bib.use_id_for_tcn = false, so that's two. :-) |
| 16:43 |
Dyrcona |
Well, I can vouch for two that don't, so we're tied. :) |
| 16:43 |
|
Jillianne joined #evergreen |
| 16:43 |
* jeff |
revises original statement |
| 16:43 |
jeff |
ainui, some oclc libs dislike cat.bib.use_id_for_tcn. |
| 16:43 |
Dyrcona |
:) |
| 16:43 |
mmorgan |
kmlussier, jeffdavis: Also not seeing the link at the cons level for existing bibs that haven't been touched :-/ I'll add that to the bug. |
| 16:53 |
dbwells |
Not following the conversation closely at all, but we are an OCLC library, and we have both cat.bib.use_id_for_tcn and cat.maintain_control_numbers set to false. (I also think the LoC recommendations for 001/035 don't hold any water for a MARC record stored in a DB with other metadata, but that's just an opinion.) |
| 16:56 |
Dyrcona |
And dbwells gets the last word. :) |
| 16:56 |
* Dyrcona |
is signing out. Good evening, all! |
| 17:03 |
|
mmorgan left #evergreen |
| 17:15 |
miker |
@later tell mmorgan the big numbers in the bre.vis_attr_cache array are the bit-shifted IDs of the bib source of the record. the shifting algorithm (well, "algorigthm" is strong ... configuration) is defined in the function search.calculate_visibility_attribute() |
| 17:15 |
pinesol_green |
miker: The operation succeeded. |
| 17:15 |
miker |
jeffdavis: -^ |
| 17:35 |
jeffdavis |
Ah, ok. Bib source is null for all records on a default install apparently. (Adding a source added a large-number entry to vis_attr_vector, but records with luris still don't show in public search results for me, fwiw.) |
| 17:58 |
|
jvwoolf1 left #evergreen |
| 18:32 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
| 21:05 |
|
Jillianne joined #evergreen |
