| Time |
Nick |
Message |
| 00:14 |
|
malexander joined #evergreen |
| 00:56 |
|
dbwells_ joined #evergreen |
| 02:08 |
|
malexander joined #evergreen |
| 04:46 |
|
khuckins joined #evergreen |
| 05:40 |
|
malexander joined #evergreen |
| 06:00 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 07:21 |
|
rjackson_isl_hom joined #evergreen |
| 08:26 |
|
mantis1 joined #evergreen |
| 08:47 |
|
alynn26 joined #evergreen |
| 08:51 |
|
mmorgan joined #evergreen |
| 09:00 |
|
tlittle joined #evergreen |
| 09:06 |
|
Dyrcona joined #evergreen |
| 09:12 |
|
malexander joined #evergreen |
| 09:14 |
|
terranm joined #evergreen |
| 09:33 |
terranm |
rhamby++ for submitting a pullrequest for a bug that's been hanging around since 2011! |
| 09:33 |
rhamby |
heh, I've looked at it over the years and thought "someone will do that" ... and I guess finally it was me |
| 09:35 |
|
jvwoolf joined #evergreen |
| 09:39 |
terranm |
We're officially below 100 open pullrequests that aren't yet signed off yet! <waves arms in the air like Kermit> |
| 09:45 |
Dyrcona |
webforms-- # Once misclick/slip of the fingers and you're on a different web page and have lost what you were typing into the form. |
| 09:48 |
Dyrcona |
Also, touchpads-- |
| 09:48 |
rhamby |
I like touchpads touchpads++ |
| 09:48 |
rhamby |
I've grown to perferm them over mouses |
| 09:48 |
rhamby |
though I despise with unreasonable emotion that the plural of a computer mouse is mouses instead of mice |
| 09:50 |
mmorgan |
terranm: Woo Hoo!! |
| 09:50 |
Dyrcona |
Meh, I say mice. |
| 09:51 |
* mmorgan |
prefers meeces |
| 09:51 |
Dyrcona |
English..... |
| 09:51 |
terranm |
Language is fluid. Say it enough times and it becomes truth. |
| 09:52 |
mmorgan |
terranm++ |
| 09:52 |
mmorgan |
So true! For better or worse... |
| 09:52 |
rhamby |
I fully endorse the fluidity of language ... until it forms a shape I don't like |
| 09:52 |
terranm |
It tends to form a murky puddle |
| 09:52 |
Dyrcona |
Anyway, I can't for the life of me reproduce something that someone at one of our libraries managed to do 3 times: fire off a pcrud search from the client that tries to retrieve all acq.lineitems. Also, why is the object called, "jub?" |
| 09:54 |
rhamby |
ran out of initialims? |
| 09:54 |
tlittle |
Dyrcona Maybe trying a line item search like Lineitem ID > 0? |
| 09:55 |
Dyrcona |
I've tried lineitem id <> 0, and I get results, that also does a open-ils.storage call. Somehow, they're getting into the Angular/AngularJS acq interface and not the Dojo interface, but how? |
| 09:57 |
Dyrcona |
Sorry, not open-ils.storage, open-ils.cstore... |
| 09:58 |
Dyrcona |
The log entry that leads to the crash looks like this: open-ils.pcrud.search.jub.atomic "AUTHTOKEN",{"id":{"!=":null}},{} |
| 10:00 |
tlittle |
In the Angular acq search, it defaults to no search term [is] ___ and I can go ahead and hit the search button and it appears to be trying to search. I don't know what's happening on the back end when I do that, though |
| 10:01 |
tlittle |
Sorry, that's General Search, which is for line items |
| 10:02 |
Dyrcona |
Is it acq/legacy/general? |
| 10:02 |
tlittle |
That's the Angular acq "General Search" |
| 10:02 |
Dyrcona |
Upon further inspection, I see that pcrud searches are being done, but I haven't managed to make it search for jub, apparently. |
| 10:03 |
Dyrcona |
tlittle: I think that eventually, the drone doing the search will eat up all the available memory on the server where it is running and will crash. |
| 10:04 |
Dyrcona |
So, we're on 3.2.10 in production. I'm trying to reproduce this on 3.5.3. I haven't figured out how to access Angular acq in our current configuration. |
| 10:06 |
Dyrcona |
If I try searching from general search with no parameters, I get a bad parameters error. |
| 10:07 |
Dyrcona |
When asked about this, the user said "when I uncheck the invoiceable box" which leads me to think that they were on the invoice view. However, I have not been able to get a no parameter search to work from there, either. |
| 10:10 |
Dyrcona |
If I go to eg2 staff client and do acq search, I'm thrown back into legacy acq. |
| 10:13 |
Dyrcona |
No matter what I do in acq there throws be back to legacy. |
| 10:14 |
Dyrcona |
No matter what I do from Search on the invoice view to get all id!=null for lineitem, I get an invalid search parameters error.... |
| 10:14 |
tlittle |
The invoiceable box is actually within a particular invoice, not just the invoice search |
| 10:14 |
Dyrcona |
tlittle: Yes, that's what I meant by "invoice view." |
| 10:15 |
tlittle |
Ah, gotcha. I didn't know if you just meant the invoice search |
| 10:16 |
Dyrcona |
I'm extremely naive user when it comes to acq. I suppose if I bang around on it long enough, I'll manage to reproduce it, but I won't remember the specific steps to get there, either. :) |
| 10:17 |
tlittle |
I'm trying to get that invoiceable/within invoice search to break, and so far if I uncheck the invoiceable box and then try to search with any type of blank term/value I appropriately get popup errors |
| 10:19 |
Dyrcona |
Yeah, the problem is that staff often try many different things when they get frustrated with search. They usually tell us the last thing that they did, and that may not be what caused the problem. |
| 10:20 |
Dyrcona |
For the logs: Search Lineitem ID is not null leads to a severe query error because null gets quoted into a string. |
| 10:21 |
Dyrcona |
I have yet to find an interface where empty search terms leads to anything other than a bad parameters popup. |
| 10:22 |
tlittle |
I don't know if it's pertinent, but when I try Lineitem ID [is not] null, I get the error DB query failed, but then immediately followed by a No Results popup |
| 10:22 |
tlittle |
I think the only place I've particularly noticed it is the Angular acq search |
| 10:22 |
Dyrcona |
Right. The syslog show a severe query error. I'm mixing terminology, sorry. |
| 10:23 |
tlittle |
*noticed empty searches go through, that is |
| 10:23 |
Dyrcona |
I can't seem to get to Angular acq search on my test vm. I'll look at production in a few minutes. Something else has come up. |
| 10:23 |
tlittle |
Good luck! :) |
| 10:58 |
csharp |
JBoyer++ |
| 10:58 |
csharp |
oh yeah - bugsquash week - I've been completely underwater and haven't been able to participate |
| 11:05 |
|
mantis2 joined #evergreen |
| 11:15 |
|
mmorgan1 joined #evergreen |
| 11:16 |
|
mmorgan2 joined #evergreen |
| 11:30 |
|
mantis1 joined #evergreen |
| 11:32 |
mmorgan |
comcast-- |
| 11:43 |
|
malexander joined #evergreen |
| 11:55 |
mmorgan |
Has anyone managed to configure a patron block based on how many days overdue an item is instead of when it's marked Long Overdue or Lost? |
| 11:57 |
|
JBoyer joined #evergreen |
| 12:01 |
|
sandbergja joined #evergreen |
| 12:13 |
terranm |
mmorgan: We have not tried to do that |
| 12:16 |
jeff |
mmorgan: Are you trying to block not on number of overdue items, but on the number of days the most-overdue item is? |
| 12:17 |
|
jihpringle joined #evergreen |
| 12:17 |
mmorgan |
terranm: Thanks. jeff: Numer of days the most overdue item is. |
| 12:17 |
mmorgan |
The actual issue we're exporing is that we have a library that doesn't want to assess a bill until the patron is ready to pay, so they can bill the patron the exact cost to replace the item. |
| 12:18 |
mmorgan |
So we don |
| 12:18 |
mmorgan |
Oops. |
| 12:19 |
mmorgan |
They don't want to block based on the billing that's applied by marking the item Lost or Long Overdue, but the number of days overdue. |
| 12:19 |
mmorgan |
We're just exploring the possibility at this point. |
| 12:19 |
terranm |
So they want to block the patron, but not let the patron know how much they owe??? |
| 12:21 |
Dyrcona |
Can you clone long overdue and have it not add a bill? |
| 12:22 |
Dyrcona |
That sounds like basically what you want. |
| 12:23 |
terranm |
I'm not sure if it could block the account if it didn't add a bill - at least not in our configuration |
| 12:23 |
mmorgan |
terranm: They want the patron to pay the actual cost to replace. They don't know what that is until they know when the patron will pay. |
| 12:23 |
Dyrcona |
You're right. You want a new reactor to block a patron if it is action trigger based. |
| 12:23 |
terranm |
So they don't have the replacement amount in the database? |
| 12:25 |
mmorgan |
We do want patrons to always be able to clear their accounts by paying what they owe. But the library wants to be sure they will cover the cost of the replacement. Disclaimer, this is not a public library. |
| 12:25 |
mmorgan |
Essentially they want a "contact us for the replacement cost" option. |
| 12:26 |
mmorgan |
Dyrcona: Yes, re: the action trigger based block. We explored that a while back but didn't have success. |
| 12:28 |
Dyrcona |
You could try a cron job in Perl to add a custom penalty to patrons who match the criteria. |
| 12:29 |
Dyrcona |
I can't think of any way to do it in stock Evergreen, but I'm not the a/t or penalties guru. |
| 12:31 |
terranm |
Is it a small patron group? If it's not too unwieldy, they could schedule reports and Bar them with user buckets |
| 12:33 |
mmorgan |
terranm: Ok, interesting. It would likely be a small group. Still the inability for them to clear their own block is still a concern. |
| 12:34 |
Dyrcona |
mmorgan: IF it is a special block, like a STAFF_CHR, the patron can't clear it. |
| 12:36 |
mmorgan |
Dyrcona: terranm: jeff: It's helpful to know that there's not a straightforward solution. Thanks all! |
| 12:36 |
mmorgan |
terranm++ |
| 12:36 |
mmorgan |
jeff++ |
| 12:36 |
terranm |
Good luck! |
| 12:36 |
mmorgan |
Dyrcona++ |
| 12:37 |
Dyrcona |
Oh. Maybe I misunderstood. Do you wan the block to clear automatically when it's paid? (That makes sense if so, and I'm not sure how that could work if there's no bill associated with it.) |
| 12:37 |
mmorgan |
I think we just need to find the best billing strategy that gives them a cushion to cover their replacement costs. |
| 12:38 |
Dyrcona |
I suppose you could do the bucket thing and add bills, but then the bills would be added manually per patron, and that's no fun. |
| 12:38 |
mmorgan |
Yes, we always want patrons to be in the position to be able to clear their records by paying fines/bills. |
| 12:38 |
terranm |
Yes, I would suggest just setting Long Overdue to a shorter time period and adding a Long Overdue processing fee. |
| 12:47 |
|
nfBurton joined #evergreen |
| 13:11 |
|
khuckins joined #evergreen |
| 13:13 |
|
collum joined #evergreen |
| 13:18 |
|
tlittle joined #evergreen |
| 13:33 |
|
mmorgan joined #evergreen |
| 13:47 |
|
mantis1 left #evergreen |
| 13:48 |
|
mantis1 joined #evergreen |
| 14:06 |
Dyrcona |
Using "not" in a query seems to be really slow on Pg 12. Is there some setting that I missed? |
| 14:12 |
csharp |
does EXPLAIN ANALYZE tell you anything? |
| 14:13 |
csharp |
especially if you can compare with another PG version on similar hw? |
| 14:18 |
jeff |
NOT IN is specifically known to "not optimize very well": https://wiki.postgresql.org/wiki/Don't_Do_This#Don.27t_use_NOT_IN |
| 14:19 |
Dyrcona |
Yeah, I know about NOT IN. I'll look into it more later. |
| 14:19 |
jeff |
other than that, I *think* "WHERE NOT is_something" where is_something is a boolean was known to miss an index on is_something = FALSE in some cases, but I don't have a URL to give you for that one. |
| 14:19 |
Dyrcona |
Pg 12 is an adventure! |
| 14:20 |
jeff |
but yes, also what csharp said. |
| 14:20 |
jeff |
and sorry if you already knew about NOT IN and if I've already mentioned it to you. :-) |
| 14:23 |
Dyrcona |
Sorry if I seem abrupt....Doing many things at once. |
| 14:23 |
miker |
Dyrcona: from yesterday, "why is it called 'jub'?" -> IIRC (and berick can disabuse me of this if I'm misremembering) but I think that's for "jacked up bib" ... the lineitem being a bib plus a bunch of other stuff tacked on. |
| 14:25 |
Dyrcona |
miker: OK. I'll keep my eyes peeled for Jubjub Birds. |
| 14:26 |
Dyrcona |
Having a hard time reproducing another bug.... |
| 14:26 |
miker |
(though a competing memory wants me to tell you that it's for "janky uber-bib" ... though the "janky" part I'm not certain of) |
| 14:26 |
tlittle |
miker That's a much nicer explanation of jacked up bib than I've always thought--I always interpreted it as "jacked up"=messed up :D |
| 14:27 |
miker |
jeff: re conditional indexes and "not vs =false" ... see the definition of the unique index on asset.copy.barcode's condition ;) |
| 14:27 |
Dyrcona |
Maybe I am reproducing the bug, and it just doesn't look that bad to me. :) |
| 14:29 |
Dyrcona |
OK. I did see the bug. It just didn't look all that buggy to me. :) |
| 14:29 |
Dyrcona |
gmcharlt: Is it OK to push to master, or do you wan that clean for 3.7 beta? |
| 14:30 |
Dyrcona |
s/wan/want/ |
| 14:30 |
Dyrcona |
typos-- |
| 14:30 |
jeff |
miker: That's one that always comes to mind! I think we gained a good 3 seconds per checkin back when you folk found that. :-) |
| 14:32 |
|
sandbergja joined #evergreen |
| 14:35 |
Dyrcona |
Maybe I am hitting cache, now. I don't see much difference between deleted = false and not deleted on Pg 12 at the moment. |
| 14:35 |
Dyrcona |
Anyway, back to bugs.... |
| 14:36 |
miker |
jeff: credit where due, dbs and jamesrf fixed that one! I just tried to pare back the change (and shouldn't have ;) ) -> https://bugs.launchpad.net/evergreen/+bug/587028 |
| 14:36 |
pinesol |
Launchpad bug 587028 in Evergreen "Inefficient asset.copy barcode index slows down circ transactions in pg 8.3" [High,Fix released] |
| 14:37 |
miker |
Dyrcona: are there generated queries that are including "not deleted"? (I haven't been following your details super close) |
| 14:37 |
Dyrcona |
miker: I don't think so. I use it a lot in my own queries, though. |
| 14:38 |
Dyrcona |
We do generate <> or !=, and that seems slower, but I haven't really tested the performance with any instrumentation. |
| 14:38 |
miker |
Dyrcona: fwiw, I use it a lot, too ... haven't noticed a problem, but, not using PG 12 yet, either |
| 14:39 |
Dyrcona |
I've been "testing" a lot on Pg 12 for the past year. |
| 14:48 |
gmcharlt |
Dyrcona: OK to push to master |
| 14:50 |
Dyrcona |
gmcharlt++ Thanks! |
| 14:58 |
|
miker joined #evergreen |
| 14:58 |
|
lisacarlucci joined #evergreen |
| 14:58 |
|
jweston joined #evergreen |
| 14:59 |
|
drigney joined #evergreen |
| 14:59 |
|
phasefx joined #evergreen |
| 14:59 |
Dyrcona |
Also, I've been using websocketd 0.4.1 with no issues on my test vms. |
| 14:59 |
|
abneiman joined #evergreen |
| 15:00 |
|
akilsdonk joined #evergreen |
| 15:05 |
|
sandbergja joined #evergreen |
| 15:08 |
pinesol |
[evergreen|Jeff Davis] LP#1917804: only show MARC 500 data in the General Note field - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=797ffec> |
| 15:25 |
|
terranm joined #evergreen |
| 16:27 |
csharp |
Dyrcona: miker: berick told me "jub" stands for "jacked-up bib" and is also a reference to Jub Jub, a pet iguana in the Simpsons |
| 17:11 |
miker |
"jub is whatever you need it to be" |
| 17:25 |
mmorgan |
Just Us Bugsquashers ;-) |
| 17:25 |
|
mmorgan left #evergreen |
| 17:25 |
terranm |
mmorgan++ |
| 17:30 |
terranm |
I've gotten to the point of my day where I can't even get vanilla master to install on my test server, so that seems like a good time to stop. |
| 17:33 |
|
nfBurton joined #evergreen |
| 17:37 |
|
jonadab joined #evergreen |
| 17:44 |
|
nfBurton joined #evergreen |
| 18:00 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 18:09 |
|
jihpringle joined #evergreen |
