| Time |
Nick |
Message |
| 06:36 |
|
Guest71 joined #evergreen |
| 07:32 |
|
collum joined #evergreen |
| 08:35 |
|
redavis joined #evergreen |
| 08:44 |
|
mmorgan joined #evergreen |
| 09:09 |
csharp_ |
spagnod: we just have the one image that's fully rebuilt every time (which is useful for testing Git branches, etc.) - if you're looking for something more permanent, you might try installing on a VM? |
| 09:10 |
csharp_ |
or on a container with persistent storage? (I haven't done a lot of container work, so just throwing spaghetti at the wall) |
| 09:23 |
|
Dyrcona joined #evergreen |
| 09:29 |
spagnod |
Alright, I'll try a VM |
| 09:53 |
Dyrcona |
Testing a custom db upgrade and got this: psql:cwmars-3.7.4-3.15.0-upgrade-db.sql:16687: ERROR: cannot CREATE INDEX "usr_setting" because it has pending trigger events. |
| 09:54 |
Dyrcona |
Something like that usually ends up with a ROLLBACK, but in this case there's no ROLLBACK in my output. |
| 09:55 |
Dyrcona |
I wonder if \set ON_ERROR_STOP on prevented the rollback from happening. I find the documentation for that setting to be confusing. "You keep using that [setting]. I don't think it means what you think it means." |
| 09:56 |
Dyrcona |
Think I'll try it again without that set. |
| 09:56 |
Dyrcona |
Since the script has multiple transactions and some blocks outside of transactions, I'd like the rest to stop if any prior transaction fails. |
| 09:57 |
Dyrcona |
I thought that's what ON_ERROR_STOP does, but I'm probably mistaken, and maybe I should jump over to #postgresql to ask how I do what I want to do. You would think that I would know by now. |
| 10:09 |
|
mmorgan1 joined #evergreen |
| 10:10 |
Dyrcona |
I should have checked if the 1461 update applied before reloading the database. |
| 10:15 |
Dyrcona |
I think maybe I understand that setting a little better. Looks like maybe the script did just stop there and no rollback was issued. |
| 10:25 |
|
mmorgan1 left #evergreen |
| 10:38 |
|
mmorgan joined #evergreen |
| 10:55 |
Dyrcona |
Heh. Typoed "updgrade" sometimes it like that. |
| 10:55 |
Dyrcona |
You can insert your own verb. :) |
| 10:55 |
berick |
"udpate" joins the chat |
| 10:57 |
Dyrcona |
Hey! That pg_restore ran pretty quickly. |
| 11:06 |
Dyrcona |
In the case of having to split a db update into two or more transactions, I wonder if I should add subversions, like 1433a and 1443b, and then have the latter also do the 1433? That way if something goes boom I can tell which part(s) didn't make it. |
| 11:06 |
Dyrcona |
psql:cwmars-3.7.4-3.15.0-upgrade-db.sql:17470: ERROR: cannot ALTER TABLE "ui_staff_portal_page_entry" because it has pending trigger events |
| 11:07 |
Dyrcona |
The fun just keeps rolling on. |
| 11:24 |
Dyrcona |
psql:cwmars-3.7.4-3.15.0-upgrade-db.sql:17535: ERROR: duplicate key value violates unique constraint "perm_grp_once" # That one might actually mess with some of our accounts. We have a couple that are just "User" and then have individual permissions applied. |
| 11:26 |
Dyrcona |
I may have to prepend code to the db upgrade to handle those. |
| 11:38 |
Dyrcona |
looks like the db upgrade finished. I'll have to try it again with the prepended code. |
| 13:22 |
JBoyer |
Re: no ROLLBACK in the output, I also use ON_ERROR_STOP for some things and wouldn't expect it to output ROLLBACK because the 2 ways to roll back a transaction are to actually do it with the ROLLBACK statement, or have COMMIT tell you that it's not happening. |
| 13:22 |
JBoyer |
ON_ERROR_STOP does stop *right now* so the COMMIT isn't run and doesn't output ROLLBACK. |
| 13:23 |
JBoyer |
I use that in a custom upgrade script runner with -e set so it throws everything to the ground on any error. very handy |
| 13:25 |
JBoyer |
(except when some upgrade scripts have an out-of-xact thing that doesn't matter and fails. :) ) |
| 13:33 |
Dyrcona |
My incorrect expectation has been corrected. I have moved on, and I am currently drowning in git branches based on different Evergreen releases and trying to get the "same" changes into them when git doesn't like it, i.e. too much code drift to apply patches. |
| 13:34 |
Dyrcona |
Well, I guess patch didn't like it. Maybe I should give git am a try. |
| 13:40 |
Dyrcona |
Nope, "patch does not apply." |
| 13:40 |
Dyrcona |
Guess I'll just copy and past the new lines. |
| 13:40 |
Dyrcona |
paste, even. |
| 14:33 |
Bmagic |
Syndetics provides a 1x1 image when they don't have an image. Evergreen likes that and happily uses it as it's cover image. Syndetics says that's the way they provide a non-image. Anyone had to deal with this? |
| 14:39 |
pinesol |
News from commits: LP#2080899: BOOPAC: Disable Submit Payment Button when no amount selected <https://git.evergreen-ils.org/?p=Evergreen.git;a=commitdiff;h=cb22f90f2894128eab8a38886e927a96ef2b5c15> |
| 14:39 |
pinesol |
News from commits: lp2080899 Prevent payment when no charges selected <https://git.evergreen-ils.org/?p=Evergreen.git;a=commitdiff;h=78365c1bd9d8f380824b2553ecd282c8f840aecd> |
| 14:59 |
|
mmorgan1 joined #evergreen |
| 15:19 |
sleary |
Bmagic: from my perspective, I really wish they didn't, because then we get a focus ring around an empty pixel and duplicate audible announcement of the title for our keyboard / screen reader users |
| 15:20 |
sleary |
It would be easier to eliminate that link if there were no image at all |
| 15:33 |
|
ACSpike[Work] joined #evergreen |
| 15:37 |
|
ACSpike[Work] left #evergreen |
| 15:40 |
pinesol |
News from commits: LP2092293 Fix selected overdue, lost bill row colors <https://git.evergreen-ils.org/?p=Evergreen.git;a=commitdiff;h=fd26d0fcd024dab8d0268aeb3c94dd2f7a117d00> |
| 15:49 |
Bmagic |
sleary: my point exactly. We do have a blank image hooked up in apache, but it only works when Evergreen doesn't have an image otherwise. So, it seems, Syndetics needs to change their ways or we need to detect a 1x1 pixel image and ignore it somehow. |
| 15:59 |
sleary |
Bmagic: there is... line 290: https://git.evergreen-ils.org/?p=working/Evergreen.git;a=blob;f=Open-ILS/src/templates-bootstrap/opac/parts/js.tt2;h=71fe9b4cae0671a825c6b3411b3c054a6373ed89;hb=refs/heads/main |
| 16:01 |
Bmagic |
and the JS will cause Evergreen to provide the blank? |
| 16:02 |
Bmagic |
I thought it worked via apache eg_vhost.conf, where when the web page calls for an image that doesn't exist on the server, it Rewrites to the blank png file |
| 16:03 |
sleary |
Bmagic: in theory, that will remove the <img> and its parent <a> when the image width is less than 2px |
| 16:03 |
Bmagic |
understood, but what it doesn't seem to do is put the blank image in it's stead |
| 16:04 |
Bmagic |
we need it to put the blank image (whatever that might be as per the apache config on the server side) |
| 16:04 |
sleary |
ah. OK, then we will need to rewrite that bit :) |
| 16:05 |
sleary |
I will think about it some more... we really don't want two links and two audio announcements when there's really no image |
| 16:06 |
Bmagic |
I'm thinking that this can't be a new issue. Certainly there are folks using Evergreen that take advantage of Evergreen's blank image feature and would expect it to put that in the OPAC when a record doesn't have an image. Maybe those folks aren't using Syndetics |
| 16:06 |
sleary |
I could swear I've seen a related bug |
| 16:07 |
Bmagic |
I think Syndetics is the issue not Evergreen. But if Syndetics won't stop sending us 1x1 pixel images back, we might have to code for it |
| 16:09 |
Bmagic |
if we do code for it, I would imagine the solution would be on the AddedContent::Syndetics perl module side. Where we could detect a 1x1 pixel image and ignore it (not save it to memcached) so that Evergreen doesn't get a hit for that bib record |
| 16:50 |
Dyrcona |
explain.depesz.com++ depesz++ |
| 16:52 |
Dyrcona |
Turns out that the problem with one of my slow queries was NOT where I thought it was, and using explain analyze and depesz's site, I was able to get the same results in 10 seconds instead of 90! |
| 16:52 |
Dyrcona |
It used to be just as fast on Pg 10, but the optimizer changed, so I had to update the query. |
| 17:01 |
|
mmorgan1 left #evergreen |
| 19:03 |
|
mmorgan joined #evergreen |
| 19:25 |
|
mmorgan left #evergreen |
