| Time |
Nick |
Message |
| 00:45 |
|
eady joined #evergreen |
| 05:01 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
| 07:09 |
|
JBoyer joined #evergreen |
| 07:32 |
|
agoben joined #evergreen |
| 08:48 |
|
mmorgan joined #evergreen |
| 08:53 |
csharp |
hmm - "my $circs = $e->search_action_user_circ_history([" - shouldn't that be "usr", not "user" |
| 08:53 |
csharp |
? |
| 08:54 |
JBoyer |
If it's searching circ history I assume it's returning circs, not users. What's done with $circs later? |
| 08:54 |
csharp |
http://git.evergreen-ils.org/?p=Evergreen.git;a=blob;f=Open-ILS/src/perlmods/lib/OpenILS/Application/Actor.pm;h=6cc2e8b558535a4f948a9af3d4bad76e835410e5;hb=refs/heads/master#l4308 |
| 08:54 |
JBoyer |
Hey! Look at me not being able to read anything. |
| 08:55 |
csharp |
I'm troubleshooting who's getting a blank C |
| 08:55 |
csharp |
CSV file when attempting to retrieve their circ history |
| 08:55 |
JBoyer |
Depends on if it's autogenerated or not. things like usr, shrt, and alrm drive me nuts for this very reason. |
| 08:56 |
csharp |
the original hypothesis is "too many circs causing opensrf to time out" but I'm wondering if it works at all |
| 08:56 |
csharp |
user in question has 561 action.usr_circ_history entries |
| 08:56 |
dbwells |
csharp: I know at least one IDL def spells out "user" in spite of the table name being "usr" |
| 08:57 |
JBoyer |
That call is used twice, once in Application/Actor.pm and WWW/EGCatLoader/Account.pm but the _usr_ version never appears anywhere. Is it simple enough to call in srfsh? |
| 08:57 |
csharp |
haven't tried that yet |
| 08:57 |
csharp |
not sure of the call syntax - still searching the logs for it |
| 08:57 |
JBoyer |
++ |
| 08:58 |
JBoyer |
Oh, being a *_search_* method, it may take a json query, so that's a pain to enter by hand. |
| 08:58 |
dbwells |
csharp: yes, looks like "user" should be right there: oils_obj:fieldmapper="action::user_circ_history" oils_persist:tablename="action.usr_circ_history" |
| 08:59 |
csharp |
dbwells++ # thanks |
| 08:59 |
csharp |
I'll stop chasing that then |
| 09:00 |
mmorgan |
csharp: Are you familiar with lp 1208875? |
| 09:00 |
pinesol_green |
Launchpad bug 1208875 in Evergreen 2.12 "OPAC: My Account: Download Checkout History CSV breaks when there are a large number of items in the history" [Medium,Fix committed] https://launchpad.net/bugs/1208875 |
| 09:00 |
JBoyer |
what version are you seeing this on? On moving up to 2.12 it feels like (no real measurements taken...) the threshold for "too many X" was lowered in quite a few instances. :/ |
| 09:02 |
csharp |
JBoyer: 2.11.1 |
| 09:02 |
csharp |
mmorgan: no, I'll take a look |
| 09:03 |
JBoyer |
Won't be that then. |
| 09:03 |
dbwells |
csharp: Not sure of your exact circumstances, but here is a base query for srfsh, if it helps. It at least returns some data for me: request open-ils.cstore open-ils.cstore.direct.action.user_circ_history.search.atomic {"id":1} |
| 09:03 |
csharp |
dbwells++ # thanks! |
| 09:03 |
csharp |
mmorgan: looks right on point! thanks! |
| 09:03 |
csharp |
mmorgan++ |
| 09:04 |
JBoyer |
Doesn't look like it was backported to 2.11, but I imagine you shouldn't have too much trouble. Good luck! |
| 09:04 |
JBoyer |
mmorgan++ # Coaxing LP Search to work, heh |
| 09:06 |
mmorgan |
csharp: FWIW, in the past I have found that the action trigger produced the csv for large histories, but it never made it to the browser for download. So potentially you could find it in trigger output. |
| 09:06 |
csharp |
we just turned on circ history like last year or the year before, so that's probably why we'd be just now hitting it |
| 09:06 |
csharp |
mmorgan: I'll look - thanks for the leads! |
| 09:19 |
|
terran joined #evergreen |
| 09:21 |
|
yboston joined #evergreen |
| 09:28 |
|
mdriscoll joined #evergreen |
| 09:37 |
* csharp |
blows the dust off his xenial test server for bug squashin' |
| 09:55 |
|
maryj joined #evergreen |
| 09:58 |
|
Christineb joined #evergreen |
| 10:05 |
|
mmorgan1 joined #evergreen |
| 10:16 |
|
kmlussier joined #evergreen |
| 10:18 |
miker |
dbs: fwiw, https://bugs.launchpad.net/evergreen/+bug/1695911 |
| 10:18 |
pinesol_green |
Launchpad bug 1695911 in Evergreen "Long browse entries cause index row size error" [Undecided,New] |
| 10:21 |
dbs |
miker: +1 |
| 10:41 |
|
mmorgan joined #evergreen |
| 10:47 |
dbs |
hey miker super-naive question here, but in the absence of that UNIQUE CONSTRAINT should I ever have two rows in metabib.browse_entry where sort_value & value are identical? |
| 10:48 |
pinesol_green |
[evergreen|Jason Boyer] LP1704463: Item Status Fields Correction - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=a15dc23> |
| 10:49 |
dbs |
(because of course my attempt to add a unique index using substring() is failing due to duplicates; example 1 being https://laurentian.concat.ca/eg/opac/results?query=a+compleat+history+of+europe+or+a+view+of+the+affairs+thereof+civil+and+military+for+the+year+1705+containing+all+the+publick+and+secret+transactions+therein+the+several+steps+taken+by+france+for+an+universal+monarchy+and+to+enslave+her+neighb |
| 10:49 |
dbs |
ours+the+wars+in+italy+poland+germany+netherlands&qtype=title&fi%3Asearch_format=&locg=105 |
| 10:50 |
dbs |
was trying with a simplistic: CREATE UNIQUE INDEX CONCURRENTLY browse_entry_sort_value_value_key ON metabib.browse_entry (SUBSTRING(sort_value FROM 0 FOR 2048), SUBSTRING(value FROM 0 FOR 512)); |
| 10:52 |
* dbs |
has never dealt with browse stuff before, yay 2.12 upgrade tests :) |
| 10:53 |
* dbs |
ponders throwing the ID field into the mix to guarantee uniqueness, heh |
| 10:59 |
|
Jillianne joined #evergreen |
| 11:04 |
pinesol_green |
[evergreen|Martha Driscoll] LP#1692106: Z39.50 server includes prefix and suffix in 852 - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=e8a19ad> |
| 11:06 |
pinesol_green |
[evergreen|Galen Charlton] LP#1691560: start open-ils.qstore service by default - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=95aa127> |
| 11:11 |
miker |
dbs: sorry ... looked away from IRC. the browse entry table really, really wants to be unique across sort_value and value. perhaps we need to reserve the last 32 bytes for an md5sum (or equiv) of the full value, if truncating? |
| 11:12 |
miker |
a hybrid of dbwells' and my suggestions, IOW |
| 11:13 |
* miker |
reads all the way ... or, yes, heh, id. as you suggest :) |
| 11:13 |
miker |
which would be faster than hashing, so, win |
| 11:14 |
dbs |
miker: okay, I'll give that a shot. thanks! |
| 11:14 |
miker |
dbs++ |
| 11:20 |
dbs |
UNIQUE INDEX succeeded, but ALTER TABLE metabib.browse_entry ADD CONSTRAINT browse_entry_sort_value_value_key UNIQUE USING INDEX browse_entry_sort_value_value_key; failed |
| 11:20 |
dbs |
ERROR: index "browse_entry_sort_value_value_key" contains expressions (per https://www.postgresql.org/docs/9.4/static/sql-altertable.html "The index cannot have expression columns nor be a partial index") |
| 11:21 |
miker |
bah ... well, we can use a BEFORE trigger to calculate the truncation (if required) instead |
| 11:21 |
dbs |
maybe this is why we ended up doing the mfr view... |
| 11:22 |
miker |
well, we did the view so we could store the whole value in, er, value and transparently index just part of it... IIRC |
| 11:22 |
miker |
instead of editing the value. or something like that. |
| 11:23 |
miker |
but, for browse, we care if the values are unique, and how they sort (as in, it should be deterministic), but not really what they are |
| 11:23 |
miker |
because we don't display them directly today |
| 11:44 |
miker |
dbs: well... I should add some clarification ... for mfr, we care about being able to search for an exact, arbitrary value. for browse, we don't care so much about an exact value, but about its position. personally, I'm fine with a well-defined behavior of FIFO when the strings match up to 2k |
| 12:11 |
|
jihpringle joined #evergreen |
| 12:14 |
stompro |
When working on a signoff branch, is it better to git rebase to master or start with a new master branch and cherry-pick -s to get there? I just tried the rebase mode, but I'm not sure if there are other problems with that. |
| 12:24 |
bshum |
stompro: it sounds like the final result should be similar |
| 12:24 |
bshum |
I've done it both ways depending on my mood |
| 12:24 |
bshum |
Sometimes I do a full rebase on a given working branch against master so that I can be sure there weren't any orphaned commits in the branch |
| 12:24 |
bshum |
Like if they made a commit at the top, but there was some merge further down that I didn't notice |
| 12:25 |
bshum |
Or like if there were lots of commits made in a working branch, instead of cherry-picking one at a time... lazy |
| 12:26 |
stompro |
bshum, thanks, I think I'm going to go back to the cherry-pick route for now, I was trying the rebase route because of the lazy factor, there are 10 commits for the bookplate feature. |
| 12:28 |
dbs |
99.9% of the time i do the "new master branch and cherry-pick -s" |
| 12:28 |
bshum |
stompro: I'll usually use git rebase -i (interactive mode) and then step through each commit it finds one by one; adding my git signoff on each step |
| 12:28 |
dbs |
btw, "tig" is a useful command for that :) |
| 12:28 |
bshum |
Like git commit --amend -s ; git rebase --continue |
| 12:28 |
bshum |
And letting it go |
| 12:29 |
bshum |
Well, after changing it from "pick" to "edit" |
| 12:29 |
dbs |
tig will let you cherry-pick -s against a list of commits in a nice ASCII UI |
| 12:29 |
bshum |
dbs++ # good tips |
| 12:29 |
dbs |
(by pressing "S" IIRC) |
| 12:30 |
dbs |
(although I might have mapped that key myself, as "C" is the plain cherry-pick without signoff) |
| 12:31 |
dbs |
in .tigrc I have bind generic C !git cherry-pick -s %(commit) |
| 12:55 |
|
sandbergja joined #evergreen |
| 12:58 |
|
maryj_ joined #evergreen |
| 13:23 |
|
terran joined #evergreen |
| 13:43 |
|
maryj joined #evergreen |
| 14:15 |
|
kmlussier joined #evergreen |
| 14:39 |
pinesol_green |
[evergreen|Kathy Lussier] LP#1486451: Remove rdetails_status nowrap style - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=e2c70de> |
| 16:25 |
* phasefx |
just got bit by a launchpad timeout error.. going to rewrite the ticket in vim first :D |
| 16:31 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
| 16:50 |
|
Jillianne joined #evergreen |
| 16:57 |
phasefx |
berick: dbs: kmlussier: https://bugs.launchpad.net/evergreen/+bug/1704873 |
| 16:57 |
pinesol_green |
Launchpad bug 1704873 in Evergreen "webstaff item print labels" [Undecided,New] |
| 16:58 |
phasefx |
if you guys have any tuits to poke at that, I'd give you hugs |
| 17:00 |
* kmlussier |
was about to slowly back away from anything involving spine labels, but there are hugs? |
| 17:00 |
phasefx |
there are hugs, but a limited number, since I'm a huge introvert :) |
| 17:04 |
|
mmorgan left #evergreen |
| 17:05 |
kmlussier |
phasefx: Yeah, that's why I usually do cookies. Virtual hugs work. :) |
| 17:05 |
* kmlussier |
isn't sure how many tuits she really has this week, but will keep it in mind. |
| 17:05 |
phasefx |
muchos gracias |
| 17:06 |
* phasefx |
is on vacation next week |
| 18:56 |
|
genpaku joined #evergreen |
| 22:07 |
|
drigney joined #evergreen |
| 22:12 |
|
mnsriz joined #evergreen |
| 22:21 |
|
Jillianne joined #evergreen |
