| Time |
Nick |
Message |
| 03:59 |
|
dbs_ joined #evergreen |
| 04:00 |
|
mceraso joined #evergreen |
| 04:11 |
|
justdoglet joined #evergreen |
| 05:05 |
|
gsams joined #evergreen |
| 07:01 |
|
rlefaive joined #evergreen |
| 07:11 |
rhamby_ |
morning all |
| 07:53 |
|
TARA joined #evergreen |
| 08:03 |
|
rlefaive joined #evergreen |
| 08:04 |
|
Dyrcona joined #evergreen |
| 08:10 |
|
ericar joined #evergreen |
| 08:20 |
jeff |
rhamby_: morning! |
| 08:30 |
|
mrpeters joined #evergreen |
| 08:36 |
|
kmlussier joined #evergreen |
| 08:36 |
kmlussier |
Good morning! |
| 08:37 |
kmlussier |
@coffee [someone] |
| 08:37 |
* pinesol_green |
brews and pours a cup of Kenya Ndiara Full Flavor Roast, and sends it sliding down the bar to Dyrcona |
| 08:37 |
kmlussier |
@tea [someone] |
| 08:37 |
* pinesol_green |
brews and pours a pot of Masala Chai, and sends it sliding down the bar to dbs_ (http://ratetea.com/tea/rishi/masala-chai/4495/) |
| 08:37 |
Dyrcona |
Thanks! |
| 08:37 |
Dyrcona |
@coffee kmlussier |
| 08:37 |
* pinesol_green |
brews and pours a cup of Brazil Fazenda Boa Vista, and sends it sliding down the bar to kmlussier |
| 08:38 |
* jeff |
makes some new reports with fancy drill-downs and everything |
| 08:43 |
|
mmorgan joined #evergreen |
| 08:51 |
|
mmorgan left #evergreen |
| 08:52 |
jeff |
I wonder if a name formatting function or name formatting view would be more useful. |
| 08:55 |
|
mmorgan joined #evergreen |
| 08:56 |
|
jwoodard joined #evergreen |
| 08:57 |
tsbere |
jeff: That sounds like a "depends on what you want to use it for" situation |
| 08:58 |
tsbere |
jeff: Though have you tried just using the format function? <_< |
| 09:01 |
jeff |
wait, is there an existing format function for patron names? |
| 09:02 |
tsbere |
jeff: No, the sprintf-style string format function named "format" |
| 09:02 |
jeff |
or were you asking if i had tried using the postgres format() function? |
| 09:02 |
jeff |
aha, got it. |
| 09:05 |
jeff |
in this case, i think I'll trade functionality over readability. |
| 09:05 |
jeff |
and dispatch with COALESCE(au.family_name, 'NO_LAST_NAME') || ', ' || COALESCE(au.first_given_name,'NO_FIRST_NAME') || ' ' || COALESCE(au.second_given_name, '') || COALESCE(au.suffix, '') AS patron_name |
| 09:05 |
jeff |
in favor of FORMAT('%s, %s %s %s', family_name, first_given_name, second_given_name, suffix) |
| 09:06 |
jeff |
tsbere++ |
| 09:06 |
jeff |
pretty sure I've used FORMAT() elsewhere, not sure why I didn't think to use it here. |
| 09:07 |
tsbere |
I tend to forget about it at times as well |
| 09:08 |
tsbere |
Though wanting to cut down on spaces-following-spaces sometimes leads to more convoluted things regarding second_given_name and suffix |
| 09:08 |
jeff |
the other fun thing this morning was: |
| 09:08 |
jeff |
HAVING MAX(circ.xact_start) > NOW() - '1 year'::INTERVAL |
| 09:08 |
jeff |
vs |
| 09:08 |
jeff |
HAVING MAX(circ.xact_start) < NOW() - '1 year'::INTERVAL |
| 09:08 |
jeff |
I started with the latter. |
| 09:09 |
tsbere |
I can see both being useful in different situations |
| 09:09 |
jeff |
And was wondering why this (admittedly small) library only had one patron with a circ yesterday. |
| 09:09 |
jeff |
and of course it wasn't yesterday, it was 1 year ago yesterday, because math. :P |
| 09:09 |
phasefx |
jeff: don't know if this is the case for you, but for the logs, if any of those au. fields contain empty strings instead of nulls, NULLIF would be good |
| 09:10 |
phasefx |
jeff: ne'er mind me, I'm thinking staging tables, not EG fields with a not null on family name; dur :) |
| 09:10 |
jeff |
phasefx: NULLIF is handy, especially around COALESCE ('' vs NULL family_name for example would not be handled as NO_LAST_NAME by my original) |
| 09:11 |
tsbere |
For a more convoluted format command: FORMAT('%s, %s%s%s', COALESCE(family_name, 'NO_LAST_NAME'), COALESCE(first_given_name, 'NO_FIRST_NAME'), COALESCE(' ' || second_given_name,''), COALESCE(' ' || suffix, '')) |
| 09:11 |
jeff |
that falls under the part that I edited out where I described the first (before FORMAT()) as messy, while still not catching all the desired edge cases. |
| 09:12 |
jeff |
tsbere: add some NULLIFs to catch said corner cases, and we've got the best of both worlds! |
| 09:12 |
jeff |
anyway, this serves as a pretty good demonstration of why i was considering a patron name function and/or view, so that i wasn't having to remember how to reimplement the wheel in each report. :-) |
| 09:13 |
* phasefx |
's mind is purely in migration land :) |
| 09:13 |
tsbere |
jeff: A function that takes an optional "format string" argument to jam into the format command could work. Then you can use positional-argument format strings to change things up, but keep all your "NO_whatever_NAME" logic in place. |
| 09:14 |
jeff |
In practice, the NO_whatever_NAME is probably not needed, which is why I'm happy with the simple FORMAT() for now. |
| 09:15 |
phasefx |
CASE WHEN exception THEN ... ELSE FORMAT END :) |
| 09:21 |
jeff |
opposite of "no need to log back in, because you were up so late last night": it's been so long since I logged into this particular account I needed to re-sync my hardware token. |
| 09:27 |
* tsbere |
had an account he logged into with his (brand new) hardware token once, then the next time he needed to the token's battery had died >_> |
| 09:27 |
jeff |
ouch. |
| 09:28 |
jeff |
if there hasn't been a "hugely catastrophic impending disaster with 2FA as the only barrier between our hero and certain destruction" story yet, I'd be surprised. |
| 09:31 |
tsbere |
jeff: Luckily for me, the "next time" was "to indicate that they should CLOSE THE ACCOUNT" - I wasn't supposed to have an account anymore due to having changed jobs. Twice. And they mailed (postal service) me a "your password expired, please change it" letter. |
| 09:33 |
* tsbere |
ended up calling the support number and explaining things....and yet as far as he knows the account is still sitting there with an expired password and a link to a dead hardware token |
| 09:47 |
|
yboston joined #evergreen |
| 10:00 |
|
rlefaive joined #evergreen |
| 10:02 |
|
tarac_ joined #evergreen |
| 10:04 |
|
JBoyer joined #evergreen |
| 10:29 |
|
rlefaive joined #evergreen |
| 10:46 |
kmlussier |
Bah! Looks like I'll have to update the sample MARC file at http://wiki.evergreen-ils.org/doku.php?id=qa:eg_test_cases to use circ modifiers due to bug 1423750 |
| 10:46 |
pinesol_green |
Launchpad bug 1423750 in Evergreen "vandelay: importing items without circulation modifiers always fails" [Medium,New] https://launchpad.net/bugs/1423750 |
| 10:47 |
Dyrcona |
Well, the bug could always be fixed. ;) |
| 10:51 |
kmlussier |
Dyrcona: Given that it's been sitting there for more than a year, I won't hold my breath. |
| 10:52 |
Dyrcona |
Well, no, I wouldn't either. |
| 10:53 |
kmlussier |
I don't know how many sites it really affects. It would only impact sites that a) don't use circ modifiers regularly on their copies (like MVLC) and b) import holdings through Vandelay. |
| 10:55 |
Dyrcona |
MVLC doesn't import holdings through Vandelay.--I don't think that bug affects acquisitions, does it? |
| 10:56 |
berick |
Dyrcona: ACQ copies are created through a different process, external to vandelay |
| 10:58 |
Dyrcona |
berick: Thanks. That's what I thought. |
| 11:02 |
|
geoffsams joined #evergreen |
| 11:05 |
|
terran joined #evergreen |
| 11:09 |
kmlussier |
My goal for this year is to become clearer on which code contributions require a QA test and which do not. bug 1447746 alters a database function. Does this rise to the level of requiring a pgTap test? |
| 11:09 |
pinesol_green |
Launchpad bug 1447746 in Evergreen "Do not update bib source on match-only merge" [Wishlist,Confirmed] https://launchpad.net/bugs/1447746 |
| 11:19 |
Dyrcona |
At the very least, a pgtap test for the existence of the new column could be done. |
| 11:19 |
|
rlefaive joined #evergreen |
| 11:19 |
Dyrcona |
It can be difficult to write tests for database functions. |
| 11:20 |
|
ddale joined #evergreen |
| 11:21 |
kmlussier |
OK, thanks for the guidance Dyrcona. |
| 11:21 |
kmlussier |
Dyrcona++ |
| 11:22 |
Dyrcona |
You could test that by adding a queue and a record, running the overlay function, and then retrieving the results. |
| 11:22 |
Dyrcona |
It would be a rather involved test, like some of the ones I've written lately. ;) |
| 11:23 |
mceraso |
At the Hack-A-Way this past November, gmcharlt gave an excellent overview of Evergreen and all of its pieces. I thought a map of this was made...was this ever shared with the community? I thought that it was, but I'm having difficulty finding it. Anyone know, offhand? |
| 11:23 |
kmlussier |
mceraso: I think there is a link to it from the Google doc. |
| 11:23 |
Dyrcona |
Could be done as Perl tests or as pgtap. |
| 11:24 |
mceraso |
kmlussier: Aha! That sounds familiar! |
| 11:24 |
kmlussier |
mceraso: Is this it? https://docs.google.com/drawings/d/17aNEr8vLen5wBjCAP4NPnjL7fYT3VxK6_9wVArR9VII/edit?usp=sharing |
| 11:24 |
mceraso |
kmlussier: Yes! Excactly what I needed :) |
| 11:24 |
kmlussier |
It probably would be good to add it to the wiki at some point. |
| 11:25 |
mceraso |
kmlussier++ #thanks! |
| 11:25 |
mceraso |
Yes, agreed |
| 11:26 |
Dyrcona |
That looks like a good diagram to me. |
| 11:27 |
Dyrcona |
You wouldn't happen to have the URL for the main hack-away document would you? |
| 11:27 |
Dyrcona |
I don't seem to have added it to My Drive. |
| 11:27 |
kmlussier |
Dyrcona: https://docs.google.com/document/d/1_wbIiU47kSElcg0hG2o-ZJ9hNmyM8v7rOWyi8jGvA38/edit?usp=sharing |
| 11:27 |
Dyrcona |
Thanks! |
| 11:49 |
|
Christineb joined #evergreen |
| 11:59 |
|
tarac_ joined #evergreen |
| 12:02 |
|
brahmina joined #evergreen |
| 12:04 |
|
jvwoolf joined #evergreen |
| 12:51 |
|
tarac_ joined #evergreen |
| 13:07 |
|
jihpringle joined #evergreen |
| 13:37 |
|
sandbergja joined #evergreen |
| 13:39 |
|
tarac_ joined #evergreen |
| 13:54 |
|
kmlussier joined #evergreen |
| 14:02 |
|
rlefaive joined #evergreen |
| 14:40 |
|
rlefaive joined #evergreen |
| 14:54 |
|
rlefaive joined #evergreen |
| 15:05 |
|
mmorgan1 joined #evergreen |
| 15:45 |
|
jlitrell joined #evergreen |
| 15:51 |
|
kmlussier joined #evergreen |
| 15:51 |
|
brahmina joined #evergreen |
| 15:51 |
|
dbs_ joined #evergreen |
| 15:51 |
|
_bott_ joined #evergreen |
| 15:51 |
|
jonadab joined #evergreen |
| 15:51 |
|
berick joined #evergreen |
| 15:51 |
|
Callender joined #evergreen |
| 15:51 |
|
Stompro joined #evergreen |
| 15:51 |
|
Dyrcona joined #evergreen |
| 15:51 |
|
jyorio joined #evergreen |
| 15:51 |
|
graced joined #evergreen |
| 15:51 |
|
Bmagic_ joined #evergreen |
| 15:51 |
|
artunit_away joined #evergreen |
| 15:51 |
|
mnsri_away joined #evergreen |
| 15:51 |
|
b_bonner joined #evergreen |
| 15:51 |
|
rashma joined #evergreen |
| 15:51 |
|
tsbere joined #evergreen |
| 15:52 |
|
Dyrcona joined #evergreen |
| 15:55 |
|
justdoglet joined #evergreen |
| 16:05 |
|
hbrennan joined #evergreen |
| 16:10 |
kmlussier |
terran++ #Bug Squashing Day wrangling! |
| 16:49 |
Bmagic_ |
terran++ |
| 16:50 |
|
Bmagic joined #evergreen |
| 17:01 |
bshum |
terran++ |
| 17:05 |
|
jvwoolf left #evergreen |
| 17:08 |
Stompro |
Hello folks, when you are doing a pg_restore of your EG DB, do you normally use the disable triggers flag? |
| 17:08 |
|
mmorgan joined #evergreen |
| 17:14 |
|
mmorgan left #evergreen |
| 17:18 |
jeffdavis |
Stompro: I don't. |
| 17:21 |
Stompro |
jeffdavis, thanks, I saw someone mention using it once, I'm just wondering if it speeds up a restore. I'm wondering if a reingest happens during restore when triggers are not disabled? |
| 17:23 |
jeffdavis |
pg_dump -Fd -Z 9 --serializable-deferrable -f dumpfile production_evergreen_db ; psql -vdb_name=new_db -f create_database_extensions.sql ; pg_restore -Fd -d new_db dumpfile |
| 17:23 |
jeffdavis |
is basically our process |
| 17:23 |
jeffdavis |
restore is fairly slow (I run it overnight) but no, I don't believe it does a reingest |
| 17:25 |
jeffdavis |
maybe it would if your dumpfile is in SQL format (pg_dump -Fp or without the -F option) |
| 17:26 |
Stompro |
I'm using the directory format also, with -j 4 to speed things up. |
| 17:27 |
Stompro |
I'm not using --serializable-deferrable, I'll have to read up on that. |
| 17:30 |
Stompro |
Hmmm, I guess I should be using that. |
| 17:36 |
|
rlefaive joined #evergreen |
| 18:04 |
|
TARA joined #evergreen |
| 18:15 |
bshum |
pg_restore's -j option if you have more CPUs is quite nice. |
| 18:16 |
bshum |
I don't recall trying out parallel pg_dump though |
| 18:16 |
bshum |
Which sounds like it's an option in PG 9.3+ |
| 18:19 |
bshum |
An old article, but seems to indicate that it exists: http://michael.otacoo.com/postgresql-2/postgres-9-3-feature-highlight-parallel-pg_dump/ |
| 20:01 |
|
dcook joined #evergreen |
| 22:29 |
jeff |
bshum: yeah, it's handy. :-) works with directory-format backups only. |
| 22:31 |
jeff |
(as Stompro described) |
| 22:48 |
jeff |
Stompro: keep in mind that the --disable-triggers option is only relevant for data only dumps or restores. |
| 22:49 |
jeff |
Stompro: otherwise, pg_restore's going to copy the data into the tables before it adds things like constraints and triggers. |
| 23:39 |
|
sitalk joined #evergreen |
| 23:45 |
sitalk |
Hello everyone. |
| 23:45 |
sitalk |
I am having the following problem: |
| 23:48 |
sitalk |
The installation of Evergeen went smooth and there were no any errors after starting Evergreen. However I got the following error after restarting apache: |
| 23:49 |
sitalk |
[FAIL] Starting web server: apache2 failed! |
| 23:49 |
sitalk |
[warn] The apache2 configtest failed. ... (warning). |
| 23:49 |
sitalk |
Output of config test was: |
| 23:49 |
sitalk |
AH00526: Syntax error on line 43 of /etc/apache2/eg_vhost.conf: |
| 23:49 |
sitalk |
Invalid command 'OSRFGatewayConfig', perhaps misspelled or defined by a |
| 23:49 |
sitalk |
module not included in the server configuration |
| 23:49 |
sitalk |
Action 'configtest' failed. |
| 23:49 |
sitalk |
Has anyone seen such error before? |
| 23:49 |
sitalk |
Do you have any idea how this issue could be resolved? |
| 23:49 |
sitalk |
Thanks in advance. |
| 23:50 |
sitalk |
I am using Evergreen 2.10 on Debian 8.4 |
