| Time |
Nick |
Message |
| 04:30 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
| 07:02 |
|
rjackson_isl joined #evergreen |
| 07:26 |
|
agoben joined #evergreen |
| 07:38 |
|
Dyrcona joined #evergreen |
| 08:41 |
|
kmlussier joined #evergreen |
| 08:42 |
Dyrcona |
Hurrah for money.open_usr_summary! |
| 08:42 |
pinesol_green |
[evergreen|Jeanette Lundgren] Docs: Update reporter_cloning_shared_templates.adoc - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=538a30f> |
| 08:42 |
pinesol_green |
[evergreen|Jeanette Lundgren] Docs: LP#1673841 Fix formatting in Apache docs - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=5cf5032> |
| 08:48 |
|
_adb joined #evergreen |
| 08:53 |
JBoyer |
We just got our first request to add Google's Project Fi to our list of SMS providers. That's not a big deal to add but I thought I saw a bug some time ago to do that already? Fever dream? |
| 09:05 |
Dyrcona |
JBoyer: Yeah, it just went in to master IIRC. |
| 09:06 |
Dyrcona |
Like in the last week or so. |
| 09:06 |
JBoyer |
Ah. Just the usual LP search falling down on the job then. |
| 09:06 |
JBoyer |
Dyrcona++ |
| 09:08 |
Dyrcona |
Maybe I'm wrong about it going in, but I know I saw the code and chatted with bshum about it briefly. |
| 09:11 |
kmlussier |
Yeah, I see it on the system that I just built yesterday. I don't see the commit, though. |
| 09:11 |
Dyrcona |
Yeah, there was someting about Google FI and Republic Wireless. |
| 09:12 |
kmlussier |
Oh, that's in the 2.12 release notes. I guess I should have known about that. :) |
| 09:13 |
Dyrcona |
It's in the 950.data.seed.values.sql but no upgrade script. |
| 09:13 |
Dyrcona |
And, yeah, I recall glancing over it in the release notes. :) |
| 09:14 |
kmlussier |
JBoyer: If you did what I did, you probably had trouble finding it because you saw the Republic Wireless on the title of the bug and didn't realize it also covered Google Fi. |
| 09:14 |
Dyrcona |
Or the upgrade script doesn't containg the words Google or Republic. |
| 09:15 |
JBoyer |
kmlussier, No, LP wouldn't return anything at all for generic searches like Project Fi or sms gateway or the like. I should have searched my commit email list, at least Outlook can manage that. |
| 09:17 |
JBoyer |
Though Outlook has the opposite problem since every message contains the word Project and many descriptions contain the word Fix... ;) |
| 09:18 |
kmlussier |
No upgrade script, because, according to the commit message, systems may have added them manually. hmmmm |
| 09:18 |
JBoyer |
:/ |
| 09:19 |
kmlussier |
JBoyer: Yeah, the problem is that LP doesn't search Fix Released bugs by default, which can be annoying, but, I can understand why. Even with including the released bugs, though, it didn't come up with a search for Google Fi which surprises me because I thought LP searched comments. |
| 09:19 |
JBoyer |
Carefully using a DO block means there's next to nothing that can't be in an upgrade script, regardless of what the existing system has/hasn't done. |
| 09:20 |
* kmlussier |
agrees with JBoyer |
| 09:21 |
kmlussier |
In this case, though, the release notes do tell folks how to add them. |
| 09:22 |
JBoyer |
\me needs to pay more attention to those sometimes. |
| 09:22 |
* JBoyer |
too. |
| 09:23 |
Dyrcona |
LP does not search comments, apparently, unless you try to open a new bug. |
| 09:23 |
Dyrcona |
Attempting to report a new bug is my dirty way of doing a better search. |
| 09:24 |
Dyrcona |
JBoyer: I use DO blocks a lot in my own scripts, but I'm not sure we want to make their use a habit in upgrade scripts. |
| 09:26 |
JBoyer |
Ideally they're not necessary but I'd prefer an upgrade script that can just do the right thing rather than reading through release notes looking for additional SQL to run or instructions on manually adding missing data and so on in the client. |
| 09:32 |
jeff |
fwiw, you don't always need a DO block for every "systems may have already added them" scenario. |
| 09:32 |
dbwells |
We also pretty regularly do "these may fail but try them anyway" upgrades outside of the main commit block for version releases. Not sure if that would have helped here. |
| 09:33 |
jeff |
bug 1378829 handled a fair number of possible states that someone's database could be in regarding a long-standing often-locally-fixed issue -- if i do say so myself. :-) |
| 09:33 |
pinesol_green |
Launchpad bug 1378829 in Evergreen 2.12 "Typo COPY_STATUS_LONGOVERDUE.override permission" [Low,Fix committed] https://launchpad.net/bugs/1378829 |
| 09:34 |
JBoyer |
It's certainly not the only way, no. But it's definitely an option if more effort is required than just pulling inserts or updates outside of the transaction. |
| 09:35 |
kmlussier |
jeff: Yeah, that's the bug that came to mind when I was looking for the SMS upgrade script. It's not a major crisis if the new SMS providers aren't added during upgrade, but some sites may be unknowingly missing new features. |
| 09:38 |
|
yboston joined #evergreen |
| 10:14 |
|
Jillianne joined #evergreen |
| 10:31 |
|
plux joined #evergreen |
| 11:08 |
gmcharlt |
https://evergreen-ils.org/evergreen-3-0-development-update-5/ |
| 11:21 |
|
_bott_ joined #evergreen |
| 11:36 |
kmlussier |
gmcharlt++ |
| 11:53 |
|
jvwoolf joined #evergreen |
| 11:57 |
|
sandbergja joined #evergreen |
| 12:02 |
|
rlefaive joined #evergreen |
| 12:37 |
|
Christineb joined #evergreen |
| 12:43 |
|
jihpringle joined #evergreen |
| 13:11 |
JBoyer |
Gather 'round, database types, I have a style question. |
| 13:13 |
JBoyer |
Currently, in the reporter, if you use a Year + Month transform and an On or After operator with a Relative date, you get this lovely message from Clark: |
| 13:13 |
|
kmlussier joined #evergreen |
| 13:13 |
JBoyer |
DBD::Pg::st execute failed: ERROR: operator does not exist: text >= double precision LINE 17: ...d39f3bff5d8d720b02230"."xact_start")::text,2,'0') >= EXTRACT... ^ HINT: No operator matches the given name and argument type(s). You might need to add explicit type casts. at /openils/bin/clark-kent.pl line 255. |
| 13:15 |
JBoyer |
This is caused by unexpected operator priority in the construct: WHERE '...' || '...' >= '...' || '...'; (You can play this game at home in psql to see what I mean.) |
| 13:16 |
JBoyer |
My question is should this be handled by simply wrapping all of the || concatenations in () |
| 13:16 |
JBoyer |
's, or switch to the CONCAT('','',...) function? |
| 13:17 |
JBoyer |
I ask because it only seems prudent to touch every use of || in OpenILS::Reporter::SQLBuilder once. |
| 13:18 |
JBoyer |
Regardless, I need to check LP for a bug related to >=, because I remember bumping into this years ago and giving up rather than tracking it down like today. |
| 13:18 |
JBoyer |
@monologue |
| 13:18 |
pinesol_green |
JBoyer: Your current monologue is at least 9 lines long. |
| 13:35 |
Dyrcona |
Seems to me that a conversion is required, but I haven't looked into it. |
| 13:37 |
JBoyer |
When I've played with it it looks very much like an order of ops thing; if you have this instead: WHERE '...' || '...' >= |
| 13:37 |
JBoyer |
'...'; Then it complains that AND wants a boolean, not text. |
| 13:38 |
JBoyer |
Wrapping all of the || in either bare () or converting to the CONCAT function both work (I've tested both by hand) I just wondered if there might be a stylistic preference. |
| 13:39 |
JBoyer |
I suppose it would aid in the discussion if I put some tiny examples in the bug rather than constantly referring to things like '...' all over the place. |
| 13:41 |
dbs |
kmlussier: I'm going to have to wait until Sunday to "enjoy" that Shatner song, as the video is blocked in Canada (*sigh*) |
| 13:42 |
kmlussier |
dbs: :( |
| 13:42 |
kmlussier |
dbs: Are you traveling Sunday? |
| 13:44 |
kmlussier |
That's actually a dumb question since the only other option would be a special Canadian holiday that lifts restrictions on YouTube videos. |
| 13:45 |
bshum |
That sounds like a fun holiday. |
| 13:47 |
|
rlefaive joined #evergreen |
| 13:48 |
berick |
just Shatner videos |
| 13:49 |
kmlussier |
heh |
| 13:49 |
remingtron |
May 14th, 2017 is YouTube Freedom Day (Canada) |
| 13:51 |
JBoyer |
berick: Holiday or punishment? |
| 13:52 |
berick |
JBoyer: yes |
| 13:52 |
JBoyer |
Ha! |
| 13:53 |
dbs |
kmlussier++ |
| 13:53 |
dbs |
Of all places, Shatner videos should be freely accessible in Canada |
| 13:58 |
Dyrcona |
@blame CRIA |
| 13:58 |
pinesol_green |
Dyrcona: CRIA wants the TRUTH?! CRIA CAN'T HANDLE THE TRUTH!! |
| 13:59 |
Dyrcona |
I guess they changed their name in 2011. Nobody sent me the memo. :) |
| 14:00 |
_adb |
cria? baby camelids? https://en.wikipedia.org/wiki/Cria what'd they do? |
| 14:07 |
Dyrcona |
Canadian Recoriding Industry Association, now known as Music Canada. |
| 14:07 |
Dyrcona |
Or Recording if my fingers would cooperate. |
| 14:07 |
Dyrcona |
@blame typos |
| 14:07 |
pinesol_green |
Dyrcona: Forget it, Jake. It's just typos. |
| 14:08 |
Dyrcona |
Good one, pinesol_green. |
| 14:17 |
jeff |
@decide Syrup or Molasses |
| 14:17 |
pinesol_green |
jeff: go with Molasses |
| 14:17 |
jeff |
More true than you know. |
| 14:20 |
|
rlefaive joined #evergreen |
| 14:43 |
|
Dyrcona joined #evergreen |
| 14:45 |
|
jlundgren joined #evergreen |
| 14:49 |
JBoyer |
Followup to my earlier question about () vs CONCAT(), the results are essentially the same but ( '' || '' ) is slightly faster so that's what I'll go with. |
| 14:57 |
Dyrcona |
Okely dokely, neighbor! |
| 15:18 |
|
Jillianne joined #evergreen |
| 15:24 |
Bmagic |
Can I express marc 020 subfield z's in xpath like this? "//datafield[@tag="020"]/subfield[@code="z"]/text()" |
| 15:24 |
Bmagic |
(doesn't seem to be working on the postgres prompt) |
| 15:25 |
berick |
Bmagic: the stock config metabib field uses: //marc:datafield[@tag='020']/marc:subfield[@code='a' or @code='z'] |
| 15:25 |
|
sard joined #evergreen |
| 15:25 |
Bmagic |
oh, prefixed with marc |
| 15:27 |
Bmagic |
hmm. biblio.record_entry.marc doesn't have marc prefixed |
| 15:28 |
berick |
IIRC, config.xml_transform tells the xpath code what prefixes map to what namespaces |
| 15:28 |
berick |
select * from config.xml_transform where name = 'marcxml'; |
| 15:29 |
berick |
so, yeah, xpath outside of the normal ingest context may work differently |
| 15:29 |
Bmagic |
I see, yeah, I am attempting it directly on biblio.record_entry |
| 15:30 |
Bmagic |
select xpath('//datafield[@tag="020"]/subfield[@code="z"]/text()',marc::xml) from biblio.record_entry where id=xxxxx |
| 15:30 |
Bmagic |
it's not erroring, it's just returning nothing |
| 15:32 |
Bmagic |
If I can't get xpath to work, then I have to resort to regexp_replace in combo with split_part |
| 15:36 |
berick |
Bmagic: select xpath('//*[local-name()="datafield"][@tag="020"]/*[local-name()="subfield"][@code="a" or @code="z"]/text()',marc::xml) from biblio.record_entry where id=23; |
| 15:39 |
Bmagic |
ah! |
| 15:40 |
Bmagic |
local-name() |
| 15:43 |
Bmagic |
berick: I want to update the database of marc, and remove all 020 subfield z under some circumstances. I was going to do regexp_replace(marc,'(.+?<datafield tag="020".+?>.+?)(<subfield code="z">.+?<\/subfield>)(.+?<\/datafield>.*)','\1\3','') |
| 15:51 |
Bmagic |
now I am podering weather or not there is a "cleaner" way |
| 15:51 |
Bmagic |
/podering/pondering LOL |
| 15:58 |
|
jlundgren left #evergreen |
| 16:03 |
JBoyer |
Bmagic, you can use the MARC::XML perl modules inside database functions to clean marc up without risking a regexp_replace. It's not super fast, but we've done a few cleanup projects that way. |
| 16:03 |
Bmagic |
good to know |
| 16:03 |
Bmagic |
JBoyer: thanks for the tip |
| 16:03 |
JBoyer |
I don't have an example at hand, but I think some of the built-in funcs use them? |
| 16:05 |
|
bshum joined #evergreen |
| 16:30 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
| 16:31 |
|
vanessa_ joined #evergreen |
| 16:49 |
|
kmlussier joined #evergreen |
| 17:12 |
|
jvwoolf left #evergreen |
| 18:52 |
dbs |
Bmagic: evergreen.maintain_901() in 002.functions.config.sql is a decent example, I do a lot of my record maintenance with functions like that |
| 22:20 |
|
genpaku joined #evergreen |
