| Time |
Nick |
Message |
| 07:12 |
|
kworstell-isl joined #evergreen |
| 07:53 |
|
redavis joined #evergreen |
| 08:00 |
|
BDorsey joined #evergreen |
| 08:33 |
|
mmorgan joined #evergreen |
| 08:34 |
|
mantis1 joined #evergreen |
| 08:48 |
mantis1 |
trying to work on this ticket: https://bugs.launchpad.net/evergreen/+bug/1948991 I noticed that most menu titles are not directly in the page's file but referred somewhere else. I think it's fm_IDL but whenever I make changes to those "reporter" tags, it doesn't reflect in my testbox. I'm unsure if these need to be changed elsewhere. |
| 08:48 |
pinesol |
Launchpad bug 1948991 in Evergreen "Administration Options - Mismatch between menu name and interface name" [Medium,Confirmed] - Assigned to Gina Monti (gmonti90) |
| 09:02 |
|
Dyrcona joined #evergreen |
| 09:10 |
|
kworstell-isl joined #evergreen |
| 09:42 |
|
dguarrac joined #evergreen |
| 09:50 |
|
kworstell-isl joined #evergreen |
| 10:30 |
csharp_ |
Bmagic: do y'all still have tools for LibraryIQ export that are shareable somewhere? the vendor has an outdated link to the mobius_evergreen repo... |
| 10:31 |
csharp_ |
we have a library interested in testing |
| 10:31 |
Bmagic |
yep! Let me get the link |
| 10:32 |
Bmagic |
csharp_: https://github.com/mcoia/evergreen-libraryiq-export |
| 10:38 |
csharp_ |
Bmagic++ # muchas gracias |
| 10:39 |
Bmagic |
csharp_++ # because I think it's neat to put plus signs next to an underscore |
| 10:41 |
csharp_ |
yes_++ |
| 10:42 |
Bmagic |
evergreen_rocks_just_as_hard_as_++ |
| 10:42 |
Bmagic |
cont. : _dune |
| 10:45 |
Dyrcona |
Going back to something I ruminated about in channel last week, one apparently cannot flesh links that do not have a corresponding field in the fileds list: example the "renewals" on the "circ" class. |
| 10:53 |
csharp_ |
Dyrcona: sorry, don't know the full context, but parent_circ is the field, right? |
| 10:55 |
berick |
still needs a field called "renewals" on the circ |
| 10:56 |
Dyrcona |
Yeah, what berick said. I'm actually in the middle of modifying the IDL to add the renewals field. |
| 10:57 |
Dyrcona |
I can flesh parent_circ no problem. (I only noticed this when working on my own Fieldmapper implementation.) |
| 10:58 |
Dyrcona |
ooh. I broke something, 'cause now the circ retrieve return nothing at all. |
| 10:59 |
Dyrcona |
Severe query error -- see error log for more details |
| 11:00 |
Dyrcona |
ERROR: column circ.renewals does not exist at character 72 |
| 11:01 |
Dyrcona |
I'm not actually concerned with retrieving the renewals. I'm just experimenting with something that I noticed because I want to make sure I understand how it works. |
| 11:02 |
Dyrcona |
i wonder if the link actually needs to have the map attribute filled in? |
| 11:03 |
berick |
Dyrcona: oils_persist:virtual="true" |
| 11:04 |
Dyrcona |
Oh, yeah. You're right. berick++ |
| 11:04 |
Dyrcona |
I almost put that in the first time, but didn't. |
| 11:06 |
Dyrcona |
bingo! That worked. |
| 11:07 |
Dyrcona |
maybe I'll bug this and create a branch. |
| 11:09 |
|
BDorsey_ joined #evergreen |
| 11:24 |
csharp_ |
berick++ Dyrcona++ |
| 11:24 |
csharp_ |
learnin'++ |
| 11:29 |
Dyrcona |
I should automate looking for links without corresponding fields. This is the only one I've noticed, but it doesn't mean that there are not more. |
| 11:31 |
|
jvwoolf joined #evergreen |
| 12:03 |
Dyrcona |
Wow! My program found 133 classes with links that have missing fields. |
| 12:04 |
* Dyrcona |
checks that main is checked out. |
| 12:05 |
Dyrcona |
I think I'll skip virtual classes and see what the number comes to. |
| 12:07 |
Dyrcona |
Not much difference: 127 versus 133. |
| 12:09 |
|
jvwoolf joined #evergreen |
| 12:09 |
|
jvwoolf joined #evergreen |
| 12:19 |
Dyrcona |
Hm. Something's wrong with my program. It's saying fields are missing that are definitely there, though it does find the missing fields. |
| 12:20 |
Dyrcona |
it looks like it's maybe the first fields listed in most cases that is erroneously missing. |
| 12:21 |
Dyrcona |
Oh! right, the index is 0 and 0 is false.... |
| 12:21 |
Dyrcona |
I need to use isset or something like that. |
| 12:22 |
|
sandbergja joined #evergreen |
| 12:22 |
Dyrcona |
Now there are only 7 classes. That's much better/believable. |
| 12:23 |
Bmagic |
I've been bitten by that before. The ol' "0" versus false assumption |
| 12:24 |
Bmagic |
this: if( $var ) when $var = '0' but it does* exist. Tricks me every time |
| 12:25 |
sandbergja |
mantis1: After you changed terminology in fm_IDL.xml, did you make sure that it is copied to both /openils/conf/fm_IDL.xml and /openils/var/web/reports/fm_IDL.xml? And then restart opensrf (for example, with osrf_control --restart-all --localhost)? All of those steps are probably necessary to get a terminology change to show up for you locally |
| 12:25 |
sandbergja |
(depending on your setup). |
| 12:25 |
mantis1 |
sandbergja++ |
| 12:25 |
mantis1 |
ah that is right! Thank you so much |
| 12:26 |
mantis1 |
it's been so long since I've done something with the file |
| 12:26 |
sandbergja |
hope it works out! Thanks for tackling that bug. |
| 12:28 |
sandbergja |
Requesting feedback on this Perl page for the newdevs wiki, if anyone has the capacity to take a look: https://wiki.evergreen-ils.org/doku.php?id=newdevs:perl. I'm a Perl newbie, so I don't want to lead anybody else astray with my bad habits or assumptions. :-D |
| 12:28 |
sandbergja |
If you do have a chance to take a look, feel free to make any changes, or to let me know and I can make them. Thanks in advance! |
| 12:34 |
|
jihpringle joined #evergreen |
| 12:38 |
|
jvwoolf joined #evergreen |
| 12:42 |
Dyrcona |
regarding the two IDL files: autogen.sh is supposed to take care of that. |
| 12:43 |
Dyrcona |
Bmagic: Yes, in this case "$var === false" versus "$var == false" 0 satisfies the latter but not the former. (I wrote this in PHP.) |
| 12:43 |
Bmagic |
yep, triple equal |
| 12:51 |
Dyrcona |
I wonder if I can automate finding the required fields that aren't? I think parsing the SQL looking for the constraints is going to be more effort than it's worth. |
| 13:12 |
mantis1 |
this is a weird one but does the bootstrap OPAC have much javascript in it? |
| 13:12 |
mantis1 |
I'm getting an unusual complaint from a patron |
| 13:13 |
Dyrcona |
What's the complaint? |
| 13:15 |
|
kworstell_isl joined #evergreen |
| 13:18 |
mantis1 |
someone decided to block javascript from their browser (for 'security reasons') and they are complaining that they can't log into the opac |
| 13:23 |
jeffdavis |
Yes, the Bootstrap OPAC is much more JS-dependent than TPAC. (Not sure offhand about login specifically.) |
| 13:25 |
Dyrcona |
I'm not sure about login either, but they should just enable JavaScript. Most of the web will not work properly without it. |
| 13:25 |
mantis1 |
jeffdavis++ |
| 13:25 |
mantis1 |
thanks |
| 13:25 |
mantis1 |
and yeah I mean...just enable javascript idk |
| 13:27 |
jvwoolf |
Looks like the Login modal doesn't pop up if you disable Javascript, but you can go right to eg/opac/my_account if you're so inclined |
| 13:27 |
Dyrcona |
It was one of the goals for TPAC for it to basically function without JavaScript. BooPAC does not share that goal. |
| 13:28 |
* Dyrcona |
thinks at this point we might as well just implement it with Angular. |
| 13:30 |
|
kworstell-isl joined #evergreen |
| 13:36 |
Dyrcona |
huh. i should search for fields with datatype=link and no corrsponding link field. |
| 14:04 |
|
jvwoolf joined #evergreen |
| 14:05 |
Dyrcona |
Table inheritance makes parsing the create table stuff even trickier. I'm just thinking about how to represent the table in data while parsing the sql. |
| 14:07 |
Dyrcona |
if I can figure this out, I can have a program update the IDL without checking everything by hand against the schema code. I wonder if looking at the schema in the database would be easier? |
| 14:09 |
berick |
Dyrcona: i bet you could add a line or to to Fieldmapper.pm to report on those scenarios |
| 14:36 |
Dyrcona |
berick: I'm working on a query to hit information_schema.columns to see if a column is required, right now that looks like column_default is null and is_nullable = 'NO'. I'm thinking of building a DOMDocument from the IDL, iterating the non-virtual fields of the non-virtual classes, looking them up in the db, and adding oils_obj:required='true' as appropriate, and then writing out the IDL again. |
| 14:37 |
|
jvwoolf joined #evergreen |
| 14:48 |
berick |
Dyrcona: neat. sync'ing the idl to the db could be very handy. |
| 14:50 |
Dyrcona |
y'know. I wasn't thinking about making this a reusable tool, but that would be even better. |
| 14:51 |
Dyrcona |
berick++ |
| 14:55 |
Dyrcona |
i suppose I could implement an IDL validator program that check for missing links and check the required value for fields. We could add in other validations later. |
| 15:08 |
Bmagic |
Dyrcona: you're probably the best person to ask: have you ran marc_export over an Evergreen Postgres database version higher than 10? Production data preferably. |
| 15:09 |
Dyrcona |
Bmagic: Yes. |
| 15:09 |
Dyrcona |
Pg 15 mostly. |
| 15:09 |
Dyrcona |
Are you having issues? |
| 15:10 |
Bmagic |
oh good. I have done the same recently. It worked (pg 15 for me too). Though, there were many records it threw some console errors about. It still resulted in a marc file. And that file contained errors according to MARCEdit, which it happily stripped out for me using the validator tool. |
| 15:11 |
Dyrcona |
What console errors? I'm not sure that has to do with the Pg version so much. It's more likely down to character set issues in the MARC. |
| 15:11 |
Bmagic |
the DB is "C" and UTF-8, same as it was on PG10. I'm troubleshooting an export for a VuFind instance. VuFind doesn't like the export (all of a sudden) - one change we made was upgraded to pg15 from 10. Just trying to rule that out as a possible issue. I think it's just plain bad records that were introduced recently. and the pg version is a red herring |
| 15:12 |
Bmagic |
yep, character set issues. Which, we're no strangers to. But the underlying DB version could play a role. |
| 15:13 |
Dyrcona |
Did you upgrade Ubuntu, too? There was an Ubuntu upgrade that required reindiexing the database or something because the Unicode library version changed. |
| 15:13 |
Bmagic |
yep, new OS too. Though we did pingest after all was moved over |
| 15:13 |
Dyrcona |
I think a dump and restore would also fix it. |
| 15:13 |
Bmagic |
it was a dump->restore situation |
| 15:14 |
Dyrcona |
No, it's the postgres indexes themselves, not the Evergreen search indexes. |
| 15:14 |
|
mantis1 left #evergreen |
| 15:14 |
Bmagic |
I see, well, it was dumped on the older ubuntu version paired with pg10. Restored on the new OS paird with pg15 |
| 15:15 |
Dyrcona |
So, whenever you dump: Always dump with pg_dump from the new PostgreSQL version if you can. It avoids some problems later. |
| 15:15 |
jeff |
this explains a bit more about what I think Dyrcona is talking about (glibc locale changes during the life of a postgresql cluster/db): https://wiki.postgresql.org/wiki/Locale_data_changes |
| 15:15 |
Bmagic |
That's all. I was just curious if you'd done the same. I assume no issues for you? |
| 15:16 |
jeff |
I don't think that anything there would explain something that would lead to charset-related errors on text data retrieved from the db. |
| 15:16 |
Bmagic |
jeff++ |
| 15:16 |
jeff |
(but if I'm wrong, please let me know!) |
| 15:16 |
Dyrcona |
Well, I don't usually muck with the end results when dumping from Pg 15 lately. We still use 10 (gasp!) in produciton. |
| 15:17 |
Dyrcona |
jeff: no, I think you're right. |
| 15:17 |
jeff |
mostly it affects index sort order / collation changes, which can result in duplicates being alowed when they should not be, or data not being returned at all when it should be. |
| 15:17 |
Bmagic |
I've decided (based on the strength of recent new installation of Evergreen 3.11.1 on PG15 for a new group of academics) that we upgrade to PG15 for anyone going to 3.11 and greater |
| 15:18 |
Dyrcona |
I wish more folks would actually look at new Pg versions. I'm playing with pg 16 and production data, now, but have no idea if it is really ready for prime time. |
| 15:19 |
Bmagic |
We have two production consortia on pg15. Been 6 weeks or so. So far it's just fine |
| 15:19 |
Dyrcona |
Also, i don't know that pg versions should really cause bad character issues in the data. We could check the release notes again. I know that we have had to adjust the creations of some indexes and update tests because of Pg changes with character set handling in the past. |
| 15:20 |
Bmagic |
the character issue may not be related. I was sort of guessing, because the PG version was something we changed between then and now. But records get added all the time too, so.... |
| 15:20 |
Dyrcona |
Those were mainly related to stripping accents in name search. |
| 15:22 |
Dyrcona |
We get wide character and other warnings during export all the time. The best is when some UTF-16 sneaks, usually copy and paste from a browser. It always seems to happen when someone copy/pastes a description from Amazon. |
| 15:22 |
Bmagic |
same |
| 15:23 |
Dyrcona |
I suppose I could export a set of records from a pg10 db and compare that with the same records from pg16. I have a server running both with the same data. |
| 15:23 |
Bmagic |
yeah, that's the kind of thing I was contemplating |
| 15:27 |
Dyrcona |
Re Pg versions: We should drop Pg 10 and Pg 11 from future installations and be ready to drop Pg 12 soon. We should have added Pg 16 already.... I'll repeat that I wish more folks would look at this. |
| 15:28 |
Bmagic |
I'm happy with PG15 on production. I think it's time |
| 15:28 |
Dyrcona |
Bmagic: I'll make a note to do a couple of dumps and compare the results. I'll see about running something that we do regularly. |
| 15:28 |
Bmagic |
Dyrcona++ |
| 15:30 |
Dyrcona |
I might as well start one of them now. |
| 15:31 |
Dyrcona |
I should also make sure that they're using the same marc_export. |
| 15:32 |
|
jvwoolf joined #evergreen |
| 15:35 |
Dyrcona |
Bmagic: you are dumping binary MARC with encoding UTF-8? |
| 15:36 |
Dyrcona |
I've got one that, for some reason, dumps XML then uses yaz-marcdump to convert it to binary MARC. |
| 15:37 |
Dyrcona |
XML would be easier to compare. |
| 15:37 |
Dyrcona |
...Even if the file is bloated. |
| 15:38 |
* Dyrcona |
started a binary dump already and decides to let it go. |
| 15:45 |
Dyrcona |
ls |
| 15:45 |
Dyrcona |
Wrong window.... |
| 15:45 |
Dyrcona |
Bmagic: Are you getting errors from marc_export itself, or is the other side telling you the file is bad? |
| 15:48 |
Dyrcona |
Because I'm seeing nothing with this: marc_export -i -e UTF-8 --descendants AIC > aic.mrc |
| 16:02 |
Dyrcona |
yaz-marcdump also has no problem with either output file from pg 10 or pg 15. |
| 16:21 |
|
jvwoolf left #evergreen |
| 16:38 |
Bmagic |
I'd have to run it again and see. just a sec |
| 17:03 |
Dyrcona |
Bmagic: We can pick this up again tomorrow. I'm signing out. |
| 17:03 |
|
mmorgan left #evergreen |
| 17:24 |
pinesol |
News from commits: LP1889133 - Angular Staff Catalog: Error sorting by Hold Status <https://git.evergreen-ils.org/?p=Evergreen.git;a=commitdiff;h=5f06b444e4347245066aae35d54c49bfc718d7ce> |
| 17:51 |
|
jonadab joined #evergreen |
| 18:18 |
|
jonadab joined #evergreen |
| 18:43 |
|
jonadab joined #evergreen |
