| Time |
Nick |
Message |
| 04:50 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 05:09 |
|
husanu5 joined #evergreen |
| 05:23 |
|
husanu5 joined #evergreen |
| 06:40 |
|
rlefaive joined #evergreen |
| 07:53 |
|
remingtron joined #evergreen |
| 08:11 |
|
rjackson_isl joined #evergreen |
| 08:30 |
|
rlefaive joined #evergreen |
| 08:36 |
|
mmorgan joined #evergreen |
| 08:40 |
|
rlefaive joined #evergreen |
| 08:48 |
|
Dyrcona joined #evergreen |
| 08:53 |
|
mrpeters joined #evergreen |
| 09:07 |
kmlussier |
@coffee [someone] |
| 09:07 |
* pinesol_green |
brews and pours a cup of Kenya Mamuto, and sends it sliding down the bar to finnx |
| 09:12 |
Dyrcona |
@bartender |
| 09:12 |
* pinesol_green |
fills a pint glass with Anchor Porter, and sends it sliding down the bar to Dyrcona (http://beeradvocate.com/beer/profile/28/61/) |
| 09:12 |
Dyrcona |
pinesol_green: Can I get a raw egg cracked in that? Make it breakfast? |
| 09:12 |
pinesol_green |
Dyrcona: http://www.firstpersontetris.com/ |
| 09:12 |
pinesol_green |
Dyrcona: I am only a bot, please don't think I'm intelligent :) |
| 09:13 |
|
rlefaive joined #evergreen |
| 09:19 |
Dyrcona |
pinesol_green: I'm only human. Please, don't think I'm intelligent. |
| 09:19 |
pinesol_green |
Dyrcona: have you tried local mean solar time for the named city as the reference point? |
| 09:19 |
pinesol_green |
Dyrcona: I am only a bot, please don't think I'm intelligent :) |
| 09:20 |
|
yboston joined #evergreen |
| 09:20 |
|
maryj joined #evergreen |
| 09:51 |
* mmorgan |
could use a cup of intelligence right about now, but will settle for coffee :) |
| 09:56 |
berick |
@bartender mmorgan |
| 09:56 |
* pinesol_green |
fills a pint glass with Samuel Adams Chocolate Bock, and sends it sliding down the bar to mmorgan (http://beeradvocate.com/beer/profile/35/14309/) |
| 09:57 |
berick |
beer makes me smart sometimes |
| 10:00 |
mmorgan |
Heh. |
| 11:00 |
|
jihpringle joined #evergreen |
| 11:18 |
|
Newziky joined #evergreen |
| 11:56 |
|
montgoc1 joined #evergreen |
| 12:10 |
|
bmills joined #evergreen |
| 12:11 |
|
rlefaive joined #evergreen |
| 13:49 |
jeff |
hrm. bit of deja vu. why do i have lots of rows in asset.opac_visible_copies where copy_id is null? |
| 13:49 |
* jeff |
checks a few things |
| 13:57 |
jeff |
heh. 4930 rows with record of -1 |
| 13:58 |
jeff |
that probably isn't causing issues, but it might be pointless. |
| 13:58 |
berick |
hm, yeah, i would not expect to see that |
| 13:59 |
berick |
completely unrelated, I wonder if this needs an LP entry. http://pastie.org/10260595 -- in short, browse_entry remains after everything referring to it (I think) is deleted. |
| 14:00 |
jeff |
berick: i don't have high confidence in that area, but gut says "yes" |
| 14:01 |
Dyrcona |
@eightball Should that be a LP bug? |
| 14:01 |
pinesol_green |
Dyrcona: The answer is certainly yes. |
| 14:01 |
Dyrcona |
Can't beat that. Eightball agrees. |
| 14:02 |
Dyrcona |
I think so, too. |
| 14:03 |
jeff |
1129 records whose only entries in asset.opac_visible_copies have a null copy_id |
| 14:03 |
jeff |
1104 distinct |
| 14:03 |
jeff |
select count(distinct record) from asset.opac_visible_copies aovc where copy_id is null and not exists (select 1 from asset.opac_visible_copies where copy_id is not null and record = aovc.record ); |
| 14:04 |
Dyrcona |
jeff: I get 0, just fyi. |
| 14:05 |
Dyrcona |
I did select count(*) from asset.opac_visible_copies where copy_id is null |
| 14:05 |
jeff |
Dyrcona: any results for this? SELECT COUNT(*) FROM asset.opac_visible_copies WHERE copy_id IS NULL; |
| 14:06 |
Dyrcona |
Think our messages crossed. :) |
| 14:06 |
jeff |
hah! |
| 14:06 |
jeffdavis |
0 here too fwiw |
| 14:06 |
jeff |
Dyrcona: thanks. my brain had already marked your relevant message as read. :-) |
| 14:06 |
jeff |
Dyrcona++ jeffdavis++ |
| 14:06 |
berick |
ditto -- zero here |
| 14:07 |
jboyer-isl |
0 here too, though there are 1500+ of the record = -1 entries. |
| 14:07 |
jboyer-isl |
Like you said, likely not a problem, but not really accurate all the same. |
| 14:08 |
Dyrcona |
I get 353 where record = -1. |
| 14:08 |
Dyrcona |
I think those are "normal." |
| 14:08 |
Dyrcona |
For certain values of normal. ;) |
| 14:08 |
jeff |
oh hey, accurate deja vu: http://irc.evergreen-ils.org/evergreen/2014-04-07#i_85256 |
| 14:10 |
Dyrcona |
Looks like you found the answer, too. |
| 14:10 |
jeff |
oh hey. i even figured it out and spelled the mystery's solution out in detail. |
| 14:10 |
jeff |
monologues++ |
| 14:10 |
Dyrcona |
irc_logs++ |
| 14:10 |
Dyrcona |
Heh. |
| 14:11 |
Dyrcona |
I always tell people monologues are fine 'cause they'll help someone searching the logs one day. ;) |
| 14:11 |
jeff |
and with that, we bid the rows adieu: |
| 14:11 |
jeff |
# DELETE FROM asset.opac_visible_copies WHERE copy_id IS NULL; |
| 14:11 |
jeff |
DELETE 12022 |
| 14:11 |
jeffdavis |
jeff++ # solving today's problems yesterday |
| 14:11 |
Dyrcona |
monologues++ |
| 14:11 |
Dyrcona |
jeff++ |
| 14:14 |
jboyer-isl |
jeff++ #the 13th Doctor? |
| 14:20 |
jeff |
hah, of course scrolling to the end of that day, i was still pondering the issue. |
| 14:21 |
jboyer-isl |
Software is never done, only run. |
| 14:23 |
berick |
and ever so much fun |
| 14:29 |
berick |
hm, we're not deleting rows in metabib.full_rec when a record is deleted? |
| 14:29 |
berick |
looks that way in master |
| 14:30 |
berick |
ugh, 32M rows in metabib.full_rec pointing to deleted records here. |
| 14:30 |
berick |
almost 1/3 of the table |
| 14:30 |
* berick |
will open a bug for that one too unless i'm missing something |
| 14:34 |
jeff |
berick: do you have the internal flag ingest.metarecord_mapping.preserve_on_delete set to true? |
| 14:35 |
berick |
jeff: it's disabled in master + concerto, where I tested it first. checking our DB... |
| 14:35 |
jeff |
berick: because with that at false, my read of master says metabib.record_attr_vector_list gets rows removed on bib delete -- but then *I* might be missing something or misunderstanding you. |
| 14:35 |
berick |
disabled here, too |
| 14:35 |
berick |
good to know that's there, though |
| 14:39 |
jeff |
oh, and metabib.full_rec <> metabib.record_attr_vector_list |
| 14:39 |
berick |
yeah, different territory |
| 14:39 |
* jeff |
nods |
| 14:43 |
mmorgan |
berick: jeff: lp 1154267 looks pertinent |
| 14:43 |
pinesol_green |
Launchpad bug 1154267 in Evergreen "Support search for deleted records" (affected: 1, heat: 6) [Undecided,Fix released] https://launchpad.net/bugs/1154267 |
| 14:46 |
berick |
thanks mmorgan. pertinent, indeed |
| 14:47 |
mmorgan |
Though it sounds like with the internal flag jeff mentioned set to false, those rows shouldn't be maintained. |
| 14:48 |
berick |
yeah |
| 15:00 |
|
jihpringle joined #evergreen |
| 15:22 |
mmorgan |
So, cancelling a captured hold apparently doesn't clear the current_copy field. |
| 15:23 |
mmorgan |
... and it's possible to retarget a cancelled hold when viewing them in a patron's record. |
| 15:23 |
berick |
mmorgan: does it need to? |
| 15:24 |
berick |
when it's re-targeted, current_copy will get updated |
| 15:24 |
berick |
well, if it's un-canceled |
| 15:24 |
* berick |
agrees it makes little sense to be able to re-target a canceled hold |
| 15:25 |
mmorgan |
Here's what apparently happened: patron didn't pick up an item in time and it was cleared from the hold shelf. |
| 15:25 |
mmorgan |
The item was captured for another hold and was put back on the holdshelf for a different patron. |
| 15:25 |
mmorgan |
First patron called to say they still wanted the item. |
| 15:26 |
mmorgan |
In an attempt to uncancel the patron's hold, it looks like the retarget option was chosen instead. (followed by the uncancel option) |
| 15:27 |
mmorgan |
The item went to Reshelving status, and the hold for the current patron shows Hold Status -1 |
| 15:29 |
berick |
so, yeah, you shouldn't be able to re-target a canceled hold |
| 15:30 |
mmorgan |
Glad there's agreement :) I'll open a Launchpad bug. |
| 15:31 |
mmorgan |
We see holds with -1 status now and then. Not sure this is the cause of them all, but certainly was today. |
| 15:40 |
Dyrcona |
@seen bshum |
| 15:40 |
pinesol_green |
Dyrcona: bshum was last seen in #evergreen 1 day, 0 hours, 28 minutes, and 36 seconds ago: <bshum> Before we run make_release script |
| 15:40 |
berick |
found this re: deleting rows from metabib.full_rec ... bug #797238 the argument there is you might want to report on deleted records. |
| 15:40 |
pinesol_green |
Launchpad bug 797238 in Evergreen "Re-indexing deleted records upon modification" (affected: 1, heat: 6) [Undecided,Invalid] https://launchpad.net/bugs/797238 |
| 15:41 |
berick |
ok, it seems the idea then is to leave as much data on deleted records around as possible and only delete stuff that causes the record to bubble up in normal work flows |
| 15:41 |
berick |
ok, leaving that one be, then |
| 15:43 |
Dyrcona |
You can set an option on reingest to include deleted records, but you probably know that. |
| 15:43 |
berick |
actually, LP found that bug for me when I was creating a new bug. first time "Do any of the following bugs describe the bug you're trying to report?" ever worked for me. cool. |
| 15:43 |
Dyrcona |
heh. |
| 15:43 |
Dyrcona |
that's often how I search LP, I make a new bug. ;) |
| 15:44 |
jeff |
yeah. the search on that screen is better than the normal search in a lot of cases. :P |
| 15:46 |
berick |
heh, creating a new bug is like a threat to LP, so it steps up its game. |
| 15:46 |
berick |
no moar bugz, pleez |
| 15:47 |
Dyrcona |
My comment about reingest is more related to the bug you shared rather than your quest in general. |
| 15:47 |
* berick |
nods |
| 15:48 |
Dyrcona |
yeah. |
| 15:48 |
Dyrcona |
Just out of curiosity.... |
| 15:48 |
Dyrcona |
@seen senator |
| 15:48 |
pinesol_green |
Dyrcona: senator was last seen in #evergreen 1 year, 18 weeks, 1 day, 3 hours, 56 minutes, and 55 seconds ago: <senator> short term, you may consider disabling autosuggest until you figure why there are so many of those or why they take a long time/error out/whatever |
| 15:49 |
berick |
@bartender senator |
| 15:49 |
* pinesol_green |
fills a pint glass with Allagash 11th Anniversary Ale, and sends it sliding down the bar to senator (http://beeradvocate.com/beer/profile/4/32048) |
| 15:49 |
Dyrcona |
:) |
| 16:05 |
|
bmills joined #evergreen |
| 16:05 |
|
mrpeters left #evergreen |
| 16:35 |
|
maryj_ joined #evergreen |
| 17:05 |
jihpringle |
anyone know if the new permalink in the OPAC 2.8 is supposed to work in the staff client too? http://docs.evergreen-ils.org/2.8/_evergreen_2_8_0_release_notes.html#_opac |
| 17:08 |
|
mmorgan left #evergreen |
| 17:10 |
jeff |
jihpringle: the template which outputs the permalink does not appear to be wrapped in any conditionals that would prevent it from displaying in the staff client. wether or not it is a simple thing to copy the link from within the staff client is another issue... |
| 17:11 |
jihpringle |
thanks |
| 18:43 |
|
bmills joined #evergreen |
