IRC log for #evergreen, 2019-06-14

All times shown according to the server's local time.

Time	Nick	Message
00:46		sandbergja joined #evergreen
01:35		Bmagic joined #evergreen
02:04		jeff_ joined #evergreen
04:10		yar joined #evergreen
05:06	pinesol	News from qatests: Testing Success <http://testing.evergreen-ils.org/~live>
06:16		JBoyer_alt joined #evergreen
06:17		gsams joined #evergreen
07:06		JBoyer joined #evergreen
07:08		rjackson_isl joined #evergreen
08:14		bos20k joined #evergreen
08:35	JBoyer	sandbergja++ # fixing the missing seed data update in bug 1759343
08:35	pinesol	Launchpad bug 1759343 in Evergreen 3.2 "Make Annotate on Bill Pay Screen Sticky" [Low,Fix committed] https://launchpad.net/bugs/1759343
08:41		Dyrcona joined #evergreen
08:46		mmorgan joined #evergreen
09:12		aabbee joined #evergreen
09:24		yboston joined #evergreen
09:28		nfBurton joined #evergreen
09:49		collum joined #evergreen
09:52		nfBurton_ joined #evergreen
10:00	Dyrcona	jeff: For that log file size program, I ended up writing something simple in Perl. I decided it would be quicker for me to write it using File::Find, rather than trying to parse the output of ls -R in awk.
10:39		yboston joined #evergreen
11:34		Christineb joined #evergreen
11:43		jihpringle joined #evergreen
11:47		Dyrcona joined #evergreen
12:03		sandbergja joined #evergreen
12:11		sandbergja joined #evergreen
12:19		sandbergja joined #evergreen
12:28		yboston joined #evergreen
12:50		collum joined #evergreen
13:05		sandbergja joined #evergreen
13:06	miker	jeffdavis: I've been poking at ahopl myself a bit, and I have some thoughts on making it faster in some cases. in particular, I think if we added a few fields (and one new join) to the main IDL query source, and avoid joining to do filter/sort operations, I can get an equiv query that runs (for some specific filters, on one specific data set) in 200ms rather than 5100ms ... are you close to bugging your NOT EXISTS stuff?
13:07	miker	er, jeff, not jeffdavis... pardon my tab complete
13:14	* jeffdavis	shakes fist at the impostor
13:50		bos20k joined #evergreen
14:32		yboston joined #evergreen
14:54		Dyrcona joined #evergreen
15:56	mmorgan	As a follow up to my cache question yesterday, does anyone recommend clearing cache on exit in Chrome? Seems like cache is a huge problem when we're tweaking things server side.
15:58	mmorgan	T+1 week on web client, and counting
16:04	jeffdavis	We tell people to try clearing their cache first if they run into any problems, but I don't think we advise them to regularly proactively clear it or anything.
16:06	jeffdavis	It's probably not a bad idea if you are doing a lot of changes right now though.
16:06		yar joined #evergreen
16:07	berick	mmorgan: you could also configure the cache timeout headers in Apache so they expire automatically however often you need.
16:08	Dyrcona	The default of 1 year is ridiculous, but nobody asked me.
16:09	Dyrcona	I'm thinking about just removing it.
16:09	mmorgan	berick: That sounds interesting, I'd rather it be something we can control that way than keep asking our users to clear the cache, making sure they're clearing enough of it.
16:10	mmorgan	Dyrcona: So removing it would mean that a fresh page is delivered each time?
16:14	Dyrcona	Mostly. It lets the browser decide about caching rather than suggesting it cache things for a year.
16:16	Dyrcona	I think the cache setting is so high because someone is worried about performance, but we have lots of problems because of caching and its not always when we tweak things on the server.
16:17	Dyrcona	It's a standard answer from our libapps group any time someone reports a problem: clear the cache. Its a cargo cult response.
16:17	* mmorgan	adopted that as a standard response the first day :)
16:17	Dyrcona	A couple of days might be all right for caching most things. I'm thinking of dropping the cache response for images down to a day.
16:21	mmorgan	The first day on 3.2.4 web client we had a number of calls that libraries couldn't check in, or scan barcodes into item status, both issues were solved by clearing the cache. Lots of disruption, and to users it looked like a major issue.
16:21	Dyrcona	Yeahp, sounds 'bout right.
16:23	* mmorgan	needs to go read up on cache
16:28	berick	mmorgan: lot of different ways to manage caching in apache (or nginx for that matter). for browser client, at minimimum you want to expire content under the /eg/staff and /js/ui/default/staff/ paths.
16:29	berick	setting the expire time to something like +10 hours (or some such) will force the client to fetch new files every morning (generally speaking)
16:30	Dyrcona	Browsers are free to ignore those suggestions from the server, but Firefox and Chrome generally respect them.
16:32	berick	and given the mix of caching options, I highly recommend checking the headers manaually with 'curl -I ...' or similar
16:33	mmorgan	berick: Thanks for the advice. I'm all for any cache management we can do on our end rather than making our users continually clear cache.
16:33	mmorgan	berick++
16:34	berick	now I'm finding caching issues I need to address ;)
16:34	berick	Expires: Thu, 31 Dec 2037 23:55:55 GMT
16:35	berick	that must be the date of the singularity
16:37	Dyrcona	Is that the Y2k38 date?
16:38	Dyrcona	No, the problem date is Jan 19, 2038 if your system is old/not updated.
16:45	Bmagic	is it possible to somehow omit some patrons from receiving the action_trigger notice? opt_in_setting? The group of patrons are those that have a specific profile
16:48	Dyrcona	opt_in_setting might work.
16:50	Dyrcona	Not sure if at filters would work.
16:52	Bmagic	I'm not familiar with opt_in_setting. Docs don't seem to mention too much detail on it: http://docs.evergreen-ils.org/3.1/_notifications_action_triggers.html
16:53	berick	Bmagic: at filter would be simplest approach
16:53	berick	but opt-in setting is also an option
16:54	Bmagic	the json would "-not"......
16:54	mmorgan	Opt in settings allow patrons to opt in with a user setting. The patrons you want to get the notice would need the user setting set.
16:55	Bmagic	and we can invent new actor.usr_setting.name's?
16:56	Bmagic	in the case of a checkout hook - type is "circ" and therefore the actor.usr_setting needs to start with "circ." ?
16:57	berick	Bmagic: you can create user settings and the names can be anything
16:57	berick	Bmagic: to be clear, you want patrons to manually opt in?
16:57	Bmagic	right on - then configure the AT to look for it...
16:58	Bmagic	berick: well, no, this probably won't be exposed to the patron (unless the interface magically figures it out as an option)
16:58	Bmagic	I was resigning myself to perform an insert statement for a subset of the patrons
16:59	berick	Bmagic: then i'd recommend and a/t filter file instead. that way you don't have to maintain it going forward
16:59	Bmagic	yeah, sounds fair. So in the at filter file situation, I'd have to make a special granularity for this AT so that the cron can pass the new filter to it?
17:00	berick	Bmagic: here's an example overdue notice filter that limits to a set of profile ID's https://gist.github.com/berick/407e158c5e3d2f1b1da8f0cd48a2f112
17:00	pinesol	News from qatests: Testing Success <http://testing.evergreen-ils.org/~live>
17:00	Bmagic	thanks! That's exactly the syntax I was trying to hammer out
17:01	berick	Bmagic: a dedicated granularity is probably best, yes
17:01	Bmagic	thanks yall berick++ Dyrcona++ mmorgan++
17:11	Bmagic	berick: but the syntax that would work the best for me would be "not" profile id X
17:12		mmorgan left #evergreen
17:14	Bmagic	came up with this
17:14	Bmagic	"-not" : {"profile" : [34] }
17:16	pastebot	"Bmagic" at 168.25.130.30 pasted "{ "checkout.due" : { "context_" (23 lines) at http://paste.evergreen-ils.org/10023
21:29		yar joined #evergreen
23:06		sandbergja joined #evergreen