| Time |
Nick |
Message |
| 03:02 |
|
StomproJ joined #evergreen |
| 04:13 |
|
Guest11814 joined #evergreen |
| 04:29 |
|
dcook joined #evergreen |
| 05:04 |
|
berick_ joined #evergreen |
| 06:37 |
|
Callender joined #evergreen |
| 07:45 |
|
collum joined #evergreen |
| 07:51 |
|
rjackson-isl joined #evergreen |
| 08:04 |
|
jboyer-home joined #evergreen |
| 08:23 |
|
akilsdonk joined #evergreen |
| 08:36 |
|
ericar joined #evergreen |
| 08:39 |
|
book` joined #evergreen |
| 08:55 |
|
kbeswick joined #evergreen |
| 08:56 |
|
Dyrcona joined #evergreen |
| 08:58 |
|
mmorgan joined #evergreen |
| 09:11 |
|
tspindler joined #evergreen |
| 09:19 |
|
yboston joined #evergreen |
| 09:20 |
|
kmlussier joined #evergreen |
| 09:21 |
|
dluch joined #evergreen |
| 09:31 |
|
DPearl joined #evergreen |
| 10:10 |
|
mtate joined #evergreen |
| 10:10 |
|
BigRig joined #evergreen |
| 10:10 |
|
mllewellyn joined #evergreen |
| 10:11 |
|
BigRig joined #evergreen |
| 10:25 |
|
dluch joined #evergreen |
| 10:28 |
|
remingtron joined #evergreen |
| 10:31 |
bshum |
Hmm, interesting find dbs. |
| 10:34 |
jeff |
the whimsy (I think it's whimsy -- maybe not) on that site is amusing. |
| 10:43 |
dbs |
@ana all your eggs in one basket |
| 10:43 |
pinesol_green |
dbs: Nasty-looking, beleaguers |
| 10:44 |
dbs |
We could keep using our existing git repo and cut over to phabricator for the rest. Part of me really likes the ideea of rebooting the wiki from scratch, for example :) |
| 10:45 |
dbs |
But it would also be a big (huge) job, and we aren't exactly heavy on resources, so the whole idea may be whimsical. Still, seems about as close as we might get to a better-than-launchpad solution |
| 10:46 |
bshum |
Heh |
| 10:51 |
bshum |
It certainly looks interesting. |
| 11:00 |
jeff |
sometimes i wish that actor.usr had a creator or a created_at_ou |
| 11:00 |
jeff |
but i don't know how overall useful that would be. |
| 11:13 |
|
kbeswick_ joined #evergreen |
| 11:14 |
jeff |
potential use: "how many new patrons signed up at the book bike last week" |
| 11:17 |
jeff |
staff "work log" feature in the client might be more helpful. not certain. |
| 11:36 |
jl- |
jcamins: hi |
| 11:37 |
jcamins |
jl-: hello. |
| 11:51 |
|
gsams joined #evergreen |
| 11:53 |
|
ldw joined #evergreen |
| 12:14 |
|
hbrennan joined #evergreen |
| 12:56 |
|
dconnor joined #evergreen |
| 13:05 |
Dyrcona |
Has anyone else ever noticed my list bucket items being duplicated in the database? |
| 13:05 |
jeff |
in terms of one record with multiple entries in a user's list? |
| 13:06 |
jeff |
sure thing. ran into it when trying out "order by date added to container" |
| 13:07 |
|
ldw joined #evergreen |
| 13:20 |
Dyrcona |
jeff: Were they added in 2012? |
| 13:20 |
Dyrcona |
My duplicates all seem to come from October of 2012. |
| 13:24 |
hbrennan |
This was a fear of mine a month ago and I tried really hard to repeatedly add the same record, but was never successful (thankfully) |
| 13:25 |
Dyrcona |
hbrennan: My thinking is that it was a bug that lasted for a short time about two years ago. I didn't search for a Launchpad entry, though. |
| 13:26 |
hbrennan |
Dyrcona: Sounds like it. Whoever thought of preventing that from happening ++ |
| 13:26 |
Dyrcona |
Also, you only see the duplicates in the database. The OPAC filters them out as a side effect of how it retrieves the bibliographic information to display. |
| 13:26 |
hbrennan |
Good to know! |
| 13:26 |
Dyrcona |
My hunch is it happened when adding a new record to the book bag. |
| 13:27 |
jeff |
Dyrcona: pretty sure we've seen them recently, but that could be due to us behaving in unusual ways. |
| 13:27 |
Dyrcona |
The code probably re-added all of the existing entries, too. |
| 13:27 |
Dyrcona |
I'll see if I can find anything on Launchpad. (GLWT!) |
| 13:27 |
jeff |
Dyrcona: you tried to reproduce and were unsuccessful? |
| 13:28 |
Dyrcona |
jeff: Nope. It is only 1 of my bookbags and only for entries on 2012-10-16. |
| 13:28 |
Dyrcona |
Anything added in 2013 or later is fine. |
| 13:29 |
Dyrcona |
Now, I might have done something in the database to cause it. I can't rule that out. |
| 13:32 |
Dyrcona |
None of my other book bags show duplicates, but they also don't have anything added in October of 2012, just September and November. |
| 13:33 |
jeff |
Dyrcona: I was able to add duplicate items to a list just now in our 2.5.1 system running lightly-ported 2.1 era templates |
| 13:34 |
jeff |
so if it was something done post-2.5.1, or something done at the template level, i obviously don't have that in place. |
| 13:35 |
jeff |
but other than that it was pretty easy to add three items to a temp list, then go to my lists and add them to a new list, then go back and add two of the three items to the temp list and then add those to the previously-created list. |
| 13:35 |
jeff |
don't have running master handy to test with. |
| 13:37 |
Dyrcona |
I can't find any Launchpad bugs. |
| 13:38 |
hbrennan |
Nor I. |
| 13:40 |
Dyrcona |
I am going to try to come up with a query to see how widespread this is. If it only affects my one list, then I'll get one with things and ignore it. |
| 13:40 |
Dyrcona |
s/one/on/ |
| 13:44 |
Dyrcona |
Interesting. I already had a query to count cbrebis by owner and bucket name....If I add in the target_biblio_record_entry field, and then say having count(*) > 1, there we go! |
| 13:46 |
jeff |
i went with: select count(*), cbreb.id, cbrebi.target_biblio_record_entry from container.biblio_record_entry_bucket cbreb join container.biblio_record_entry_bucket_item cbrebi on cbreb.id = cbrebi.bucket where cbreb.btype = 'bookbag' group by 2,3 having count(*) > 1 order by 1 desc,2,3; |
| 13:47 |
jeff |
which returns 2402 rows. |
| 13:47 |
jeff |
290 buckets. |
| 13:48 |
jeff |
with 186 owners |
| 13:48 |
Dyrcona |
That's close to mine, except I included owner and name of the cbreb. |
| 13:49 |
Dyrcona |
My original query got the owner's active barcode, too, but only counted raw entries, not duplicates. |
| 13:57 |
Dyrcona |
Wow! One entry appears 214 times on a single list. |
| 13:58 |
jeff |
most of my high-duplicate entries are due to a script here. :-) |
| 14:01 |
Dyrcona |
I don't think that is the case for this one. |
| 14:02 |
|
zerick joined #evergreen |
| 14:02 |
Dyrcona |
It's not owned by one of our staff accounts. |
| 14:02 |
jeff |
the "Hot Music" bucket has one bib listed 302 times, then several others listed ~270 times, etc. :-) |
| 14:02 |
|
akilsdonk joined #evergreen |
| 14:04 |
Dyrcona |
I wonder what happens if you add notes to one of the duplicated entries. |
| 14:13 |
Dyrcona |
So, the note goes in and shows up again, but it appears to be "random" which entry it hits, i.e. it isn't the lowest id nor the highest. Probably whichever was "last" in table row order. |
| 14:13 |
Dyrcona |
Without an order by, it is the last one to show up.... |
| 14:13 |
jeff |
heh |
| 14:13 |
Dyrcona |
So, no good way to fix this. |
| 14:21 |
Dyrcona |
Well, it does not appear to be confined to a single point in time, so it is something that is ongoing for us at least. |
| 14:24 |
|
kbeswick joined #evergreen |
| 14:25 |
Dyrcona |
Well, that's not good. |
| 14:25 |
Dyrcona |
Trying to test a hypothesis about this being related to temporary lists, I get an internal server error on my dev machine. |
| 14:27 |
hbrennan |
I did see a bug report on internal server error on lists, when changing name... |
| 14:27 |
kmlussier |
I think I just saw Dyrcona fall down a rabbit hole. |
| 14:28 |
Dyrcona |
heh. I've been that hole since about 11:30 am. :) |
| 14:31 |
Dyrcona |
Context loader blew up with a no transaction to roll back from CStore.... |
| 14:31 |
Dyrcona |
Dunno why just adding to temp list would do that. |
| 14:33 |
Dyrcona |
It is acting like it failed to find my bookbags. |
| 14:36 |
Dyrcona |
No, it is finding them. |
| 14:40 |
Dyrcona |
And the osrfsys.log output for the thread trace with the error is useless. |
| 14:40 |
Dyrcona |
It just says a cstore message was sent, then an unkown error occurred, and then kaboom. |
| 14:41 |
Dyrcona |
It doesn't what message was sent or anything useful. |
| 14:54 |
|
tspindler left #evergreen |
| 15:43 |
|
afterl joined #evergreen |
| 15:45 |
|
ericar joined #evergreen |
| 16:09 |
remingtron |
Any developers still around? I'd like some feedback on this doc about the various support scripts: |
| 16:09 |
remingtron |
https://gist.github.com/hektech/8dce2d62e841b3ccc162 |
| 16:09 |
remingtron |
the links don't go anywhere yet, but you can ignore that |
| 16:12 |
gmcharlt |
remingtron: one bit of feedback - the authority linking scripts are absolutely necessary ... if you use authority records |
| 16:12 |
gmcharlt |
i.e., you'd either set them up to run at least daily ... or not run them at all |
| 16:18 |
remingtron |
gmcharlt: thanks. so, you'd need to run both at least daily? only over changed records? |
| 16:18 |
gmcharlt |
correct |
| 16:19 |
remingtron |
great, thanks for the feedback |
| 16:21 |
|
tc_aurator joined #evergreen |
| 16:30 |
|
jboyer-home left #evergreen |
| 16:46 |
|
ericar joined #evergreen |
| 16:52 |
|
kmlussier left #evergreen |
| 16:58 |
|
afterl left #evergreen |
| 17:19 |
|
mmorgan left #evergreen |
| 17:21 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 17:35 |
jeffdavis |
In 2.6, if I do a search with "Group Formats & Editions" checked, then click "Place Hold" on a metarecord (a result with a count in parentheses after the title), it should attempt to place a metarecord hold, correct? |
| 17:36 |
jeffdavis |
I feel like this is a dumb question, but on our test servers, the hold_type param in the Place Hold URL is T instead of M. |
| 18:26 |
bshum |
jeffdavis: I just tested it on one of our test servers and mine came up with M and not T when clicking place hold for a metarecord |
| 18:27 |
bshum |
Not sure why yours would say "T" |
| 18:35 |
jeffdavis |
Neither am I. :S Thanks for checking. |
| 18:49 |
|
ericar joined #evergreen |
| 19:11 |
jeffdavis |
Ah, looks like a bug introduced when merging our TPAC customizations into 2.6, phew. |
| 19:44 |
|
jboyer-home joined #evergreen |
| 21:37 |
|
artunit joined #evergreen |
