| Time |
Nick |
Message |
| 00:09 |
pinesol_green |
[evergreen|Kathy Lussier] Docs: 2.11.5 maintenance release notes - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=82dee7d> |
| 00:09 |
pinesol_green |
[evergreen|Kathy Lussier] Docs: 2.12.2 Maintenance release notes - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=a8e1007> |
| 01:16 |
|
Christineb joined #evergreen |
| 04:32 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
| 05:38 |
|
Stone joined #evergreen |
| 05:39 |
Stone |
Good day. I am new on here. I am here to make enquiries about setting up a library |
| 05:39 |
Stone |
I need guidlines, sort of |
| 06:39 |
|
rlefaive joined #evergreen |
| 07:05 |
|
agoben joined #evergreen |
| 07:12 |
|
rjackson_isl joined #evergreen |
| 07:20 |
|
agoben left #evergreen |
| 07:52 |
|
serflog joined #evergreen |
| 07:52 |
|
Topic for #evergreen is now Welcome to the #evergreen library system channel! | We are publicly logged: http://irc.evergreen-ils.org/evergreen | Large pastes at http://paste.evergreen-ils.org |
| 08:26 |
|
_adb joined #evergreen |
| 08:35 |
|
collum joined #evergreen |
| 08:48 |
|
mmorgan joined #evergreen |
| 08:49 |
|
bos20k joined #evergreen |
| 08:54 |
|
Dyrcona joined #evergreen |
| 09:07 |
|
kmlussier joined #evergreen |
| 09:14 |
Dyrcona |
We get this error message in email every time that edi_pusher runs: ERROR: attempt_translation failed for event 65885894, PO 17647, template_output 22791394 |
| 09:15 |
Dyrcona |
I take it that I should be looking action_trigger.event for relevant information about the event number? |
| 09:16 |
bshum |
Probably. |
| 09:16 |
Dyrcona |
Yeap. |
| 09:16 |
Dyrcona |
Never seen this before. The acq.purchase_order row looks good so I assume it must be something with one of the line items or what not. |
| 09:23 |
bshum |
https://bugs.launchpad.net/evergreen/+bug/812593 is from a time we saw an error like that with the attempt_translation fail |
| 09:23 |
pinesol_green |
Launchpad bug 812593 in Evergreen "Acquisitions - certain characters in title causes EDI translation to fail" [Medium,Fix released] - Assigned to Mike Rylander (mrylander) |
| 09:23 |
bshum |
It's long ago fixed, but maybe you've found another situation where the PO content did something odd. |
| 09:24 |
Dyrcona |
Yes, thanks for sharing. I'm not sure it's that or maybe it is some character missed by the previous patch. |
| 09:25 |
Dyrcona |
My error message is different, and I'm still double checking but looks like the event output is empty in my case. |
| 09:26 |
Dyrcona |
Nope. It's not empty. |
| 09:26 |
|
yboston joined #evergreen |
| 09:28 |
|
jvwoolf joined #evergreen |
| 09:30 |
bos20k |
Hello everyone. Question regarding reingesting bib records using metabib.reingest_record_attributes(). Is that something that can be done for all the non-deleted bib records while the system is being used normally by users, or should access to the system be shut down while that is running? |
| 09:31 |
JBoyer |
bos20k, if you do them in very small batches or one at a time it's no big deal for the system to be up. |
| 09:31 |
Dyrcona |
bos20k: Yes, you can do that while users are using the system, and you can use my pingest script from my evergreen utilities repository on github to speed it up. |
| 09:32 |
JBoyer |
Dyrcona has a very handy script for doing that, which I was too slow to mention. ;) |
| 09:32 |
bshum |
But also expect that certain things (in search, etc.) won't work right till all the reingesting is done. |
| 09:33 |
bos20k |
Hmmm, ok, I figured it would probably be ok. I am looking at the 'SELECT COUNT(metabib.reingest_record_attributes(id)) FROM biblio.record_entry WHERE deleted IS FALSE;' statement in the 0967.data.more_fixed_fields.sql database upgrade script. |
| 09:34 |
Dyrcona |
bos20k: I usually cut those out of the upgrade scripts when running them and to the ingests at the end. |
| 09:35 |
bos20k |
Working on an upgrade from 2.9 to 2.12 and don't want to wait for it to complete before bringing the system back up. |
| 09:35 |
bos20k |
Dyrcona: good, that's what I was planning to do. |
| 09:35 |
Dyrcona |
You'll sometimes find multiple upgrades doing more or less the same ingest and its more efficient to do the ingests all at once at the end. |
| 09:36 |
bshum |
nom, nom, nom |
| 09:36 |
Dyrcona |
So, on my acq thing: I looked at the event output and nothing jumps out at me. Is there some way I can test this to see where it is blowing up? |
| 09:37 |
bshum |
Dyrcona: The event that's failing is the push right? But was there anything odd in the POJEDI move? From PO to EDI I mean. That would be a related trigger event. |
| 09:38 |
bos20k |
Thanks! |
| 09:38 |
miker |
bos20k: you can either use Dyrcona's script, or generate SQL along the lines of: 1) \o /tmp/reingest.sql 2) select 'select metabib.reingest_record_attributes('||id||'),'||id||';' from biblio.record_entry where not deleted; 3) \i /tmp/reingest.sql |
| 09:38 |
bos20k |
Dyrcona++ |
| 09:38 |
bos20k |
JBoyer++ |
| 09:38 |
bos20k |
miker++ |
| 09:39 |
miker |
(beware: from memory ;) ) |
| 09:40 |
miker |
bonus points for cut+parallel |
| 09:40 |
miker |
er, split, not cut |
| 09:40 |
bos20k |
miker: I think that code is in 0964.data.electronic-resources.sql |
| 09:41 |
Dyrcona |
bos20k: Going to 2.12, you'll probably want to skip that though and just update the records in a transaction with reignest on same marc set to true. |
| 09:41 |
miker |
bos20k: so it is! |
| 09:42 |
Dyrcona |
There's more than just a metabib reingest required, if you want the new goodies, like 901$s. |
| 09:42 |
bos20k |
miker: is that faster than the SELECT in 0967.data.more_fixed_fields.sql? |
| 09:43 |
Dyrcona |
I wrote a script for doing that that I haven't shared, yet. I think it is still running in training. :) |
| 09:43 |
miker |
bos20k: it's about the same clock time (maybe a bit more for commit overhead) but it lets you keep using the system without the fear of locking bib records |
| 09:43 |
miker |
the one in 0967 will lock records for write |
| 09:43 |
bos20k |
miker: ah, ok |
| 09:43 |
Dyrcona |
Yeap, still going over a month later... |
| 09:44 |
miker |
bos20k: as does, I assume, Dyrcona's script (which I haven't personally used) |
| 09:45 |
miker |
that is, it does /not/ lock records |
| 09:45 |
bos20k |
Dyrcona: I was planning on going through all these upgrade scripts and pulling out the reingest stuff and deduplicating then running them in order once all the other upgrade stuff is done. Is there something different I should be doing? |
| 09:45 |
miker |
bos20k: a single reingest (or, a non-browse reingest followed by a browse-only) is all you'd need at the end |
| 09:46 |
Dyrcona |
miker: Not exactly. Just going from 2.10 to 2.12 there are additional changes that those won't pick up. |
| 09:46 |
miker |
Dyrcona: a full reingest won't pick up some changes? |
| 09:46 |
Dyrcona |
If you don't want those changes, then you'll get them, eventually, as records are updated. |
| 09:47 |
Dyrcona |
I don't think so. Not the metabib.reingest function. |
| 09:47 |
Dyrcona |
What do you mean by "full" ingest just to clarify. |
| 09:48 |
dbwells |
bos20k: Is there any particular reason for using the individual upgrade scripts over the packaged versions? Reingests are typically already pushed to the end of those, so it might save you some fiddling. |
| 09:49 |
miker |
Dyrcona: I was talking about a full update with the 'ingest.skip_browse_indexing' enabled, followed by a browse-only reingest |
| 09:49 |
Dyrcona |
OK, then, that will pick it up. |
| 09:49 |
miker |
so that the first can be parallelized safely (deadlocks possible on parallel with browse enabled) |
| 09:50 |
bos20k |
dbwells: Maybe. At the moment we're not running a normal 2.9. We're running what bshum left. I figured it might be a good way to do it, do them individually. I have just started testing them and have already had to modify them a bit due to nonstandard stuff in our database. |
| 09:50 |
Dyrcona |
dbwells: If you're past the version where the 2.9 to 2.10 upgrade script was made it can be difficult to use the packaged upgrade scripts. |
| 09:50 |
Dyrcona |
I make my own, but I know how. |
| 09:51 |
bshum |
Right, it'd be master as of around when rel_2_9 got branched, but not specifically. |
| 09:51 |
dbwells |
bos20k: Ok, sounds good :) Wasn't sure where you were coming from. |
| 09:51 |
bshum |
bos20k: Following the db upgrade scripts through a certain number point should be relatively safe-ish. |
| 09:52 |
bos20k |
miker: Is there an example somewhere of doing a ' a single reingest (or, a non-browse reingest followed by a browse-only) ' somewhere? Sorry, this is the first I've ever dealt with reingesting... |
| 09:52 |
bshum |
But with the way that backporting happens, you could still end up with some duplicate ID collisions when running things with version-upgrade. Safe bet is probably what you're doing, and checking through all the upgrade files sequentially. |
| 09:52 |
bos20k |
bshum: that's what I thought too :) |
| 09:55 |
Dyrcona |
bos20k: I've got a script for that, but haven't shared it yet. I call it nginest. |
| 09:55 |
Dyrcona |
It has flags for all of the ingest-related options. |
| 09:55 |
dbwells |
miker: Since we're on the topic, and I will actually be doing an upgrade in a few days, we have for the last few years just used a cheesy script to generate a separate "UPDATE...SET marc=marc" command for every row, then churn through them in 8 or so parallel batches. There are no transactions, so no chance of deadlock for anything. Are we crazy to do it this way? In particular, do you think we are giving up a lot of performance? |
| 09:56 |
Dyrcona |
It pulls out a list of the bibs to be ingested, then ingests each one, locking the row as it ingests in a transaction with the flags set appropriately. |
| 09:56 |
bos20k |
Dyrcona: So, were you planning on sharing that? :) |
| 09:57 |
Dyrcona |
It is slow, but seems to have had little impact on training, which is used somewhat, or on my other dev database where I have been doing other bib updates while it chugs away. |
| 09:57 |
Dyrcona |
Yes, at some point, but time. |
| 09:57 |
Dyrcona |
It needs documentation for one thing. |
| 09:58 |
Dyrcona |
Here's a sample of what is running on training: scripts/ngingest --host localhost --verbose --skip-metarecord-mapping --skip-search-indexing --disable-located-uri |
| 09:59 |
Dyrcona |
That's an old version and --disable-* is now --skip-* |
| 10:01 |
miker |
bos20k: I don't have anything handy, sorry. basically, enable the 'ingest.skip_browse_indexing' internal flag, do a "normal" reingest (which you can parallelize), then reset that and do a metabib.reingest_metabib_field_entries(id,true,false,true) reingest to do just the browse part that was skipped |
| 10:04 |
bshum |
dbwells: That's how I used to do my upgrade reingests, I'm pretty sure. |
| 10:04 |
bos20k |
Hmmm, OK, Thanks! |
| 10:05 |
Dyrcona |
Frankly, I don't think there is a good way to do an ingest, too many triggers. Just my grumpy opinion. |
| 10:06 |
dbwells |
bshum: Thank you for the confirmation |
| 10:07 |
bshum |
dbwells: I'm not confirming if we were crazy or not. Just confirming that I've done it your way before. :) |
| 10:08 |
dbwells |
bshum: well, you are always good company :) |
| 10:08 |
berick |
Dyrcona: i can rebase bug 1373690 if it'll help |
| 10:08 |
pinesol_green |
Launchpad bug 1373690 in Evergreen "Direct EDI generation for ACQ orders -- AKA kill ruby webrick" [Wishlist,New] https://launchpad.net/bugs/1373690 - Assigned to Jason Stephenson (jstephenson) |
| 10:08 |
Dyrcona |
berick: It might. If you scroll up you'll see why I want to test it. |
| 10:09 |
Dyrcona |
I'm stuck with an edi pusher error and so far haven't figured out the exact cause. |
| 10:13 |
berick |
yeah, that can be a real pain. one thing to verify: select is_json(jedi) from acq.edi_message where id = .. |
| 10:13 |
* dbs |
waves |
| 10:13 |
jeff |
dbs: greetings! |
| 10:16 |
berick |
haha, I finally found where I fixed an egPcrud error in a working branch. and I of course fixed it a different way (mixed w/ other fixes). Dyrcona, gimme a minute to fix the branch before you test anything, plz. |
| 10:16 |
Dyrcona |
Too many blue icons... I often end up in a different application from the one that I wanted. |
| 10:16 |
Dyrcona |
berick: NP. I don't think I'm getting to it today at this rate. |
| 10:19 |
Dyrcona |
berick: No acq.edi_message is generated for this purchase order. I think that is the step that's blowing up. |
| 10:22 |
berick |
Dyrcona: ah |
| 10:24 |
berick |
Dyrcona: the is_json test should be done on the event_output.data in that case |
| 10:26 |
Dyrcona |
It says 'f' but just eyeballing it earlier, I didn't see the problem. Would perl2json report the exact issue, do you think? |
| 10:26 |
Dyrcona |
Err, json2perl rather.... |
| 10:28 |
Dyrcona |
All right, I'll dump the output data and try parsing it with a small script. |
| 10:28 |
berick |
yeah, it would say more than that |
| 10:28 |
berick |
ditto the 'js' binary |
| 10:29 |
csharp |
@band add Ditto the JS Binary |
| 10:29 |
pinesol_green |
csharp: I eat more coconut cream pie before breakfast than most people eat all day |
| 10:29 |
berick |
hehe |
| 10:34 |
dbs |
berick: I like the direction 3.0 is going with /common/ assets, at some point (maybe 3.1) I'd like to centralize all of the CSS and JS so we can uglify/minify/code-split for opac as well as webby - and maybe generate the css with vars at build time instead of TT2 parsing |
| 10:36 |
berick |
dbs: referring to bug 1642086 ? |
| 10:36 |
pinesol_green |
Launchpad bug 1642086 in Evergreen "jQuery support for the public catalog" [Wishlist,New] https://launchpad.net/bugs/1642086 |
| 10:37 |
Dyrcona |
invalid character encountered while parsing JSON string, at character offset 4802 (before "\t305.569/VIC","item...") That gets me somwhere, I think. |
| 10:39 |
jeff |
@decide Ditto the JS Binary or The jq Conspiracy |
| 10:39 |
pinesol_green |
jeff: go with Ditto the JS Binary |
| 10:39 |
jeff |
fair enough. |
| 10:39 |
berick |
@decide Ditto the JS Binary or Mott The Hoople |
| 10:39 |
pinesol_green |
berick: go with Mott The Hoople |
| 10:39 |
Dyrcona |
Of course! All the young dudes go with Mott the Hoople! :) |
| 10:40 |
Dyrcona |
So, looks like a tab in a call number.... |
| 10:40 |
Dyrcona |
Yeah, hex dump is 09. |
| 10:41 |
Dyrcona |
So, line_index...is that a lineitem id? |
| 10:41 |
berick |
i think so |
| 10:43 |
Dyrcona |
Yes, it looks like it. |
| 10:43 |
Dyrcona |
So, where does that call number come from? I guess I have to do more digging. |
| 10:50 |
dbs |
berick: yep, one small step for OPAC |
| 10:51 |
berick |
dbs: cool, yeah i need to revisit that bug |
| 10:53 |
berick |
hmm, anyone else getting odd ngToast behavior in master? e.g. find a bib in the webstaff catalog, try 'mark for:' title hold transfer |
| 10:53 |
berick |
the whole page shifts down for several seconds instead of showing the toast |
| 10:53 |
berick |
@band add Show Me The Toast |
| 10:53 |
pinesol_green |
berick: As great as you are man, you'll never be greater than yourself. |
| 11:00 |
miker |
berick: master-ish (webstaff serials) is not showing that behavior... toast pops up |
| 11:01 |
berick |
miker: thanks for checking |
| 11:03 |
* berick |
rebuilds dependencies |
| 11:13 |
berick |
hm, still funky. /me will revisit |
| 11:25 |
gmcharlt |
olly olly oxen free: is anybody expecting to do any last-second merges to rel_2_10, rel_2_11, or rel_2_12 prior to today's releases? |
| 11:25 |
Dyrcona |
So, got side tracked on something else, but removing the tab does fix the JSON. Now, to find where the tab came from so it doesn't come back. |
| 11:35 |
Dyrcona |
Bingo! It's in the lineitem_detail.cn_label |
| 11:37 |
gmcharlt |
ok, having heard about any last-minute pushes, I'm declaring a temporary freeze on rel_2_10, rel_2_11, and rel_2_12 for anything that isn't directly related to today's releases |
| 11:38 |
Dyrcona |
gmcharlt++ |
| 11:38 |
gmcharlt |
er, having _not_ heard... |
| 11:39 |
Dyrcona |
Yeah, we got it. :) |
| 11:39 |
* gmcharlt |
picks up the pile of dropped words around his chair and tosses them up in the air like confetti |
| 11:41 |
|
khuckins joined #evergreen |
| 11:43 |
JBoyer |
I always wonder about the story behind things like an actor.card.barcode = '>:(' |
| 11:43 |
JBoyer |
(We have a ui.patron.edit.barcode.regex value now...) |
| 11:46 |
Dyrcona |
JBoyer: Is it a staff person? I've heard that they like to give themselves short barcodes. |
| 11:47 |
JBoyer |
Dyrcona, user alert "Patron is Irate..." would suggest not. ;) And if I were going to go for a short barcode I'd want fewer reasons to use the Shift key. |
| 11:47 |
Dyrcona |
True. |
| 11:48 |
jeff |
last i looked we had multiple emoticon-like holdshelf aliases. |
| 11:49 |
JBoyer |
Hah, though you could use them sort of like the reverse of a custom ringtone based on the job you were about to perform. Simple admin tasks = :D, catalog cleanup = :/, and working a public desk = D: |
| 11:51 |
Dyrcona |
jeff: apropos one-off scripts, I wrote one to check validity of json that might prove useful later. |
| 11:52 |
Dyrcona |
It has 5 use statements and 3 lines of actual code. :) |
| 11:52 |
JBoyer |
jeff, there's a fun test of our unicode handling; can you successfully use a location name of 🔥🆕📚 and have everything appear correctly |
| 11:55 |
csharp |
JBoyer++ |
| 11:56 |
JBoyer |
Bummer, acpl editor says no. :/ |
| 11:56 |
JBoyer |
To the database! |
| 11:56 |
* csharp |
re-enters PINES locations in windings font |
| 11:57 |
csharp |
wingdings, even |
| 11:58 |
|
Christineb joined #evergreen |
| 12:03 |
JBoyer |
Hmph. :/ open-ils.cstore: Error retrieving asset::copy_location with query [SELECT "acpl".id FROM asset.copy_location AS "acpl" WHERE "acpl".owning_lib = '73' AND "acpl".deleted = 'f' AND "acpl".name = '<d83d><dd25><d83c><dd95><d83d><dcda>';]: 3452617 3452617: ERROR: invalid byte sequence for encoding "UTF8": 0xed 0xa0 0xbd |
| 12:05 |
JBoyer |
Silly emoji location names aside, that likely points to an actual issue that will need sussing out before we can really expect much use outside of the latin alphabet. |
| 12:06 |
JBoyer |
(OR, dojo broke it. I dunno.) |
| 12:21 |
|
jihpringle joined #evergreen |
| 12:31 |
|
sandbergja joined #evergreen |
| 12:34 |
Dyrcona |
Well, my output is still broken. |
| 12:37 |
Dyrcona |
Ah ha! I also have to fix asset.call_number.label. |
| 12:47 |
Dyrcona |
JBoyer: It's also likely that whatever c library handles Unicode on your system needs updating. |
| 12:53 |
JBoyer |
Windows has been ok with Unicode since NT 3 or 4, and (current-ish) Firefox should be alright. The raw db insert also worked as expected and was displayed, so my uneducated guess at the moment would be something between Firefox and postgresql. (I know that's still a large pile of things. That's why I'm not currently too fussed about it. :) ) |
| 12:54 |
Dyrcona |
JBoyer: Unicode has versions. Not all characters appear in all versions. Not all Unicode libraries support all version or all characters. You probably know this. |
| 12:54 |
bos20k |
Another and hopefully last question regarding the DB upgrade scripts. In 0988.schema.bib_source_in_901.sql it says to do a 'UPDATE biblio.record_entry SET id = id WHERE source IS NOT NULL;' Can that be done in parallel with the reingest (I'm thinking yes after looking at things)? Is that the best SQL to acheive the settting of the 901$s? |
| 12:55 |
JBoyer |
Dyrcona, Oh, and speaking of weird call number labels, invalid XML chars like & and <> can also cause trouble at various places, depending on what's done with them. |
| 12:55 |
Dyrcona |
bos20k: If you do the ingest as miker suggested by updating the bib records that will be taken care of also. |
| 12:56 |
Dyrcona |
JBoyer: Yes. |
| 12:56 |
Dyrcona |
And tabs, apparently. :) |
| 12:56 |
JBoyer |
Dyrcona, Ah, I see what you mean. I'd have to look up how old those three symbols are. |
| 12:56 |
gmcharlt |
something I ran across and played with today - https://github.com/lvc/pkgdiff |
| 12:56 |
gmcharlt |
produces nice visualizations of diffs between tarballs |
| 12:56 |
bos20k |
Dyrcona: Oh, so if I do the reingest (thinking of using your pingest.pl with no options), the 901$s will be done too? Interesting. |
| 12:56 |
Dyrcona |
pingest.pl will not do it. |
| 12:57 |
bos20k |
Doh |
| 12:57 |
Dyrcona |
If you do the updates, there's also no point in doing pingest.pl. |
| 12:57 |
Dyrcona |
As I said earlier, there's no single "good" way to do an ingest. |
| 12:58 |
gmcharlt |
e.g., https://dev-galen.esilibrary.com/~gmc/changes_report.html |
| 12:59 |
bos20k |
Dyrcona: Hmmm, it looked to me like your pingest.pl would be able to do what is called for in the upgrades but in parallel. I am stuck doing what is in the upgrade scripts which means reingest sequentially? |
| 13:01 |
Dyrcona |
pingest.pl only does the record attribute and field entry ingest. It will not cover things like then 901 subfield s or changes to the fingerprints or similar. |
| 13:01 |
jeff |
gmcharlt: neat tool. |
| 13:03 |
bos20k |
Dyrcona: The only things I;m seeing in the upgrade scripts (from where we are upgrading from which is 0944) for reingesting are the attribute and field entry ingest. Then there's this 901$s thing. I was thinking use your pingest.pl to do the reingests that were called for in the upgrade scripts, then hopefully start the 901$s in parallel with that. |
| 13:08 |
jeff |
doing an id=id or marc=marc style reingest against biblio.record_entry (with the usual / requisite flags to ingest on same marc) is going to do a lot of the same work, if not 100% of the same work that pingest style reingests do. |
| 13:09 |
Dyrcona |
Right, but many places have those flags off by default. You'd need to check, first. |
| 13:09 |
miker |
bos20k: you need to do a "full" ingest of each record, which you can do in parallel if you disable browse ingest via the flag (and and the others jeff mentions), and then, after, do the browse reingest /if needed/ |
| 13:09 |
jeff |
so while it might be useful to use pingest to get a fast(er) ingest of most things, then use a full reingest later to update 901$s, you probably don't want to do both of those things at the same time, and you should at least be aware that you're re-doing the work (in the case of the bibs with a non-null source). |
| 13:09 |
miker |
but if browse data is not affected by the upgrade, you can skip doing that |
| 13:10 |
Dyrcona |
miker: Browse is affected. Search, is not. |
| 13:10 |
Dyrcona |
Browse and facets need ingest. |
| 13:10 |
jeff |
and yes, there are enough variables here that even a fairly verbose set of sentences is still not going to cover all the bases. i'd recommend re-reading the conversation up to this point and asking more questions if you have any. :-) |
| 13:11 |
bos20k |
Hmmm, maybe i'm not understanding what 'full' reingest means. Are you referring to metabib.reingest_full_rec()? |
| 13:11 |
Dyrcona |
Nope. |
| 13:12 |
bos20k |
er, metabib.reingest_metabib_full_rec() that is |
| 13:12 |
jeff |
in the above, my "full" was referencing the style of ingest where you set appropriate flags and execute a query or queries that cause the triggers on biblio.record_entry to fire for all records. |
| 13:12 |
Dyrcona |
update biblio.record_entry set marc = marc where.... |
| 13:12 |
Dyrcona |
Or similar. |
| 13:12 |
bos20k |
Oh, so activating all the triggers there... |
| 13:13 |
bos20k |
Hmmm, so like the 901$s update but not for only those with a source set. |
| 13:13 |
Dyrcona |
yes, but there are internal flags in config.internal_flag that can control which fire or don't fire and under what conditions. |
| 13:14 |
jeff |
not having looked at the exact set of upgrades you're doing, a pingest across your full set of records combined with a WHERE source IS NOT NULL reingest might be sufficient. |
| 13:14 |
Dyrcona |
pingest won't be sufficient. |
| 13:14 |
Dyrcona |
I've done the upgrade from 2.10 to 2.12. |
| 13:15 |
jeff |
I'm not sure we've standardized enough on terminology have this conversation without using very specific sentences. :-) |
| 13:15 |
bos20k |
Now that I understand what a full reingest really is I think I know how to proceed. Thanks again for all your help! |
| 13:15 |
Dyrcona |
I mean, it can be sufficient if you don't care about the 901$s right away. |
| 13:16 |
Dyrcona |
I should really look at the upgrade script again to be sure, but I've got other things I should be working on right now. :) |
| 13:17 |
bos20k |
Dyrcona: no worries, I just didn't understand that a 'full reingest' meant triggering everything in biblio.record_entry (with possible flags set). |
| 13:18 |
Dyrcona |
OK. That's why I asked miker to clarify earlier. :) |
| 13:18 |
Dyrcona |
I'm not always sure what someone means by things, either. |
| 13:19 |
Dyrcona |
You can use pingest.pl, if you don't care about the 901$s field. It will get added as records are updated. |
| 13:20 |
bos20k |
I might also look and see what percentage of records have a source set and see if it is worth it to do them separately. |
| 13:20 |
bos20k |
I'm guessing not but who knows. |
| 13:21 |
Dyrcona |
From 2.10.7 to 2.12.1, a facet and browse ingest are needed. The 901$s is optional. |
| 13:22 |
Dyrcona |
Fingerprints are recalculated, but that is done by the specific upgrade script. |
| 13:23 |
bos20k |
Does that fingerprinting take a long time? |
| 13:23 |
Dyrcona |
Depending on the number of records and the server, it can take a few hours. |
| 13:24 |
Dyrcona |
Oh, and you'll want to use -P pager when you that scripts. |
| 13:24 |
Dyrcona |
From 2.9.3 to 2.10.0, a record attribute reingeest is required and a search reingest of records with 655 tags is required. |
| 13:25 |
Dyrcona |
So, you could get away with just running pingest.pl if you don't care about the 901$s. |
| 13:25 |
* Dyrcona |
decided to look at the scripts after all. |
| 13:25 |
bos20k |
Dyrcona: I figured that 655 thing would be covered by the other reingesting going on? |
| 13:26 |
Dyrcona |
Yes, normally. It will be done by pingest unless you tell it to skip search. |
| 13:26 |
Dyrcona |
I'm thinking I may just do pingest when I upgrade production. The full ingest is taking days on my training system. |
| 13:27 |
jeff |
Dyrcona: for the full ingest on your training system, are you running it in parallel at all? |
| 13:27 |
|
khuckins_ joined #evergreen |
| 13:27 |
bos20k |
Alright, yes, now I really think I have a handle on what to do. Thanks again to everyone for all the input! This is my first upgrade and it's a pretty big jump. |
| 13:27 |
Dyrcona |
jeff: No. It's 1 record at a time with a transaction to lock that row and to set flags for just that update. |
| 13:28 |
Dyrcona |
bos20k: Good luck. I've never skipped over two versions before, just one. |
| 13:29 |
Dyrcona |
It's also checking the last_xact_id before doing anything. |
| 13:29 |
Dyrcona |
If the record changed since the list of ids was pulled, it skips it. |
| 13:29 |
bos20k |
Dyrcona: Thanks! Should be fun. Fasten your seatbelts everyone! |
| 13:31 |
Dyrcona |
Nooo! Why won't this EDI error go away!? |
| 13:33 |
berick |
Dyrcona: did you reset and reprocess the A/T event? |
| 13:35 |
Dyrcona |
No, but I tried updating the template output and apparently that isn't working. |
| 13:37 |
Dyrcona |
Well, I botched another event's output.....Typos.... |
| 13:37 |
Dyrcona |
Had the wrong id number. I knew I should have copy/pasted. |
| 13:38 |
berick |
IIRC, you can do something like this in srfsh: request open-ils.trigger open-ils.trigger.event.fire <event_id> |
| 13:38 |
berick |
after it's reset to 'pending' |
| 13:39 |
Dyrcona |
Don't think I need to reset it. |
| 13:39 |
Dyrcona |
I think whatever runs next, just needs the clean output. |
| 13:40 |
berick |
i just meant that to me reset+fire is simpler than manually cleaning up the event_output.data |
| 13:41 |
Dyrcona |
Well, it's a bit late now. :) |
| 13:42 |
berick |
fair enough :) |
| 13:43 |
Dyrcona |
Well, the other event was a bibliographic.record_entry.print that completed yesterday, so don't think I messed anything up too bad. |
| 13:44 |
Dyrcona |
All of this trouble for a tab character..... |
| 13:45 |
* Dyrcona |
has to find a new line of work. :) |
| 13:45 |
berick |
yeah, those prints are single-use |
| 13:46 |
* berick |
hopes we can make some progress on bug 1672775 soon -- keep those print template outputs (etc) from lingering |
| 13:46 |
pinesol_green |
Launchpad bug 1672775 in Evergreen "Action trigger data grows quickly, would benefit from cleanup" [Undecided,New] https://launchpad.net/bugs/1672775 |
| 13:47 |
Dyrcona |
Maybe I'll get to looking at that sometime soonish. |
| 13:56 |
|
kaffenkj joined #evergreen |
| 14:01 |
|
khuckins__ joined #evergreen |
| 14:07 |
Dyrcona |
Looks like it is finally fixed. |
| 15:00 |
Dyrcona |
Ah, he just left. |
| 15:06 |
Dyrcona |
Anyway, a full ingest as I described earlier had been running for 16 days on a test vm before I just stopped it. |
| 15:06 |
Dyrcona |
I'm updating the test db server software. |
| 15:06 |
Stompro |
cesardv++, thanks for working on bug 1098685. |
| 15:06 |
pinesol_green |
Launchpad bug 1098685 in Evergreen "User can select SMS notify without providing a valid address" [Undecided,Confirmed] https://launchpad.net/bugs/1098685 - Assigned to Cesar V (cesardv) |
| 15:08 |
cesardv |
Stompro: hi! sure np |
| 15:10 |
cesardv |
Stompro: currently trying out a html5 version of that fix, and seeing if we can have the best of both while keeping browser compatibility |
| 15:16 |
Dyrcona |
HTML5 in ttopac? The files are xhtml1.0. I don't think that should be done. I was thinking to open a bug at some point to suggest that we move everything to HTML5. |
| 15:16 |
Dyrcona |
I will also confirm that Chrome will work with the HTML5 elements if you add them to ttopac. |
| 15:17 |
Dyrcona |
It will kill any "standards compliance" that we may (or may not) be aiming for. |
| 15:17 |
Dyrcona |
The pages become invalid. |
| 15:18 |
Dyrcona |
On a related note, I swear the SuperBus company is using the HTML 5 logo, or a variant as their own. |
| 15:22 |
Stompro |
cesardv, that looks simple enough to add to our 2.10 system... I'll try it out as soon as I can. |
| 15:25 |
Stompro |
cesardv, One thing that is in the back of my mind about this though... if we setup a non email gateway SMS provider... how hard will it be to remove the carrier part from the system. Before a change like this I could have just hid the carrier dropdown, but now I'll also need to modify the validation function. |
| 15:27 |
Stompro |
cesardv, but I'll worry about that when/if I ever get there. |
| 15:31 |
Dyrcona |
Another con for gitlab, the ce package is huge and takes several minutes to upgrade. |
| 15:31 |
cesardv |
Stompro: yeah, if you dont need the carrier selection, just making it not visible would make it default to "none", which would require a change in the validation js, as it'd prevent the form submit. It's an easy js though, and hopefully, the html5 fix for this is more robust |
| 15:32 |
Dyrcona |
cesardv: Please, see what I said above about HTML5. |
| 15:32 |
jeff |
Dyrcona: i believe that is specific to the "omnibus" package, which is indeed recommended, but since we treat our gitlab instance as a standalone thing i've not found the time it takes to upgrade to be a detriment. the package has been very solid for us. |
| 15:33 |
Dyrcona |
jeff: Duly noted. :) |
| 15:33 |
jeff |
client-side validation is for UX and should rarely be relied on without server backing. :-) |
| 15:34 |
jeff |
Dyrcona: do you have it installed on a workstation or on a vm that's doing dual duty, and thus the time taken to download and upgrade was an annoyance? |
| 15:34 |
Dyrcona |
jeff: I'm not sure I follow your last comment. I assume it is in reference to what I said about not mixing HTML5 and XHTML 1.0. |
| 15:34 |
* jeff |
points out an incomplete certificate chain to ProQuest |
| 15:34 |
Dyrcona |
jeff: It's installed on a dedicated VM. |
| 15:34 |
jeff |
Dyrcona: no, it was more directed at what cesardv was saying. :-) |
| 15:35 |
Dyrcona |
oh. |
| 15:35 |
jeff |
``Thank you for contacting ProQuest Technical Support. I'll forward this to Newspaper Archive to investigate further.'' |
| 15:35 |
gmcharlt |
Dyrcona: eh, while it's of course worth having a discussion about an official transition to using some of the fancier bits HTML5 - or at least one that occurs in an organized fashion... |
| 15:36 |
gmcharlt |
we haven't advertised that the OPAC is HTML5 for over four years |
| 15:36 |
gmcharlt |
commit cb238428 |
| 15:36 |
pinesol_green |
gmcharlt: [evergreen|Dan Scott] TPAC: Let there be HTML5 - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=cb23842> |
| 15:36 |
cesardv |
jeff: understood :) |
| 15:37 |
Dyrcona |
gmcharlt: S'pose I've been looking at the wrong base.tt2. |
| 15:38 |
Dyrcona |
http://git.evergreen-ils.org/?p=Evergreen.git;a=blob;f=Open-ILS/src/templates/base.tt2;h=efdee63755dae08e079e265a3324fec1cef1f7e7;hb=cb23842 |
| 15:38 |
pinesol_green |
Dyrcona: [evergreen|Dan Scott] TPAC: Let there be HTML5 - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=cb23842> |
| 15:39 |
Dyrcona |
So, should I use a date widget in Lp 1189989, then? |
| 15:39 |
pinesol_green |
Launchpad bug 1189989 in Evergreen "Suspend Holds at time of placement" [Wishlist,In progress] https://launchpad.net/bugs/1189989 - Assigned to Jason Stephenson (jstephenson) |
| 15:40 |
gmcharlt |
Dyrcona: yeah, I think now's the time to try it |
| 15:40 |
gmcharlt |
https://evergreen-ils.org/security-releases-evergreen-2-10-12-evergreen-2-11-5-and-evergreen-2-12-2/ |
| 15:41 |
Stompro |
Dyrcona, +1 to date widget... is there an option to have presets like "+2 weeks" "+1 month" etc? |
| 15:42 |
Dyrcona |
Stompro: I don't think so. You'd have to do the math in JS or Perl to fill it in. |
| 15:52 |
gmcharlt |
noting that we discovered an issue with the 2.12.2 tarball and will be generating a 2.12.2a shortly |
| 15:58 |
|
khuckins_ joined #evergreen |
| 16:02 |
pinesol_green |
[evergreen|Dan Scott] LP#1478128: Avoid XSS in public catalog - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=17210e0> |
| 16:02 |
pinesol_green |
[evergreen|Galen Charlton] update 2.12.2 release notes - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=e5dd0f2> |
| 16:02 |
pinesol_green |
[evergreen|Galen Charlton] update 2.11.5 release notes - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=1bbe3fb> |
| 16:02 |
pinesol_green |
[evergreen|Galen Charlton] release notes for 2.10.12 - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=b298bc4> |
| 16:02 |
pinesol_green |
[evergreen|Galen Charlton] 2.10.11-2.10.12 schema update - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=1fd5edf> |
| 16:06 |
pinesol_green |
[evergreen|Galen Charlton] forward-port 2.11.4-2.11.5 schema update - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=13aaf85> |
| 16:11 |
|
Jillianne joined #evergreen |
| 16:16 |
pinesol_green |
[evergreen|Galen Charlton] forward-port 2.12.1-2.12.2 schema update - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=02b95ed> |
| 16:21 |
gmcharlt |
Evergreen-ILS-2.12.2a.tar.gz is now in place and the downlaods page update |
| 16:21 |
gmcharlt |
d |
| 16:30 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
| 16:31 |
dbs |
re: input type=date, for some stupid reason Firefox on the desktop still falls back to plain text input (https://developer.mozilla.org/en-US/docs/Web/HTML/Element/input/date) |
| 16:31 |
dbs |
yay releases! |
| 16:33 |
dbs |
https://bugzilla.mozilla.org/show_bug.cgi?id=825294#c93 summarizes the unfortunate Firefox situation |
| 16:33 |
pinesol_green |
Mozilla bug 825294 in DOM: Core & HTML "Implement framework for using date/time input types on Desktop" [Normal,Resolved: fixed] - Assigned to jordandev678 |
| 16:35 |
Dyrcona |
dbs: Yeah. Can we stick a fork in Firefox, yet? |
| 16:35 |
Dyrcona |
I know about that situation. |
| 16:37 |
* Dyrcona |
ponders switching his default browser to Chromium again. |
| 16:39 |
gmcharlt |
kmlussier++ |
| 16:39 |
gmcharlt |
dbwells++ |
| 16:39 |
gmcharlt |
Bmagic++ # helping with today's releases |
| 16:40 |
Dyrcona |
Bmagic++ kmlussier++ dbwells++ gmcharlt++ |
| 16:41 |
phasefx |
not to be a downer.. different topic, just noticed our google custom search engines are showing ads now |
| 16:42 |
gmcharlt |
dbs: oy. I feel there's a psychology paper (or five) in exploring weird hangups that block resolution of certain types of bugs/enhs in open source projects |
| 16:42 |
Dyrcona |
gmcharlt | dbs: I think this is a case of "not perfect enough." |
| 16:43 |
jeff |
NPH: Not Perfected Here |
| 16:44 |
jeff |
though i think that's probably a bad abbreviation, since NPH has previously been used as recently as the late 1990s in network programming context to signify "non-parsed headers"... we should probably have a meeting to decide on a better name... |
| 16:45 |
gmcharlt |
jeff: but how can we have a meeting until we settle on the rules of the meeting |
| 16:46 |
gmcharlt |
... and the perfect voting system for making the decision? |
| 16:46 |
Dyrcona |
dbs++ # For security bug fix. |
| 16:46 |
gmcharlt |
dbs++ # indeed |
| 16:47 |
* Dyrcona |
remembers non-parsed headers and using it for something, but can't remember what or why.... |
| 16:47 |
|
khuckins__ joined #evergreen |
| 16:52 |
Dyrcona |
Ah, well. Calling it a day. |
| 16:54 |
dbs |
Bmagic++ kmlussier++ dbwells++ gmcharlt++ |
| 16:54 |
mmorgan |
phasefx: I noticed this in the console when loading evergreen-ils.org while troubleshooting a browser problem: |
| 16:54 |
mmorgan |
"This page is calling an old version of the Custom Search API, which is deprecated and will stop working soon. In order to avoid an outage for the search results, the call for search results must be updated to the current version of the Custom Search API https://developers.google.com/custom-search/docs/element." |
| 16:54 |
dbs |
phasefx: Google ended their paid search option, which means ads, we should probably roll our own. Another todo for the Web team? |
| 16:55 |
phasefx |
mmorgan: :( dbs: I think so; the adds take up most the screen the way we're doing it |
| 16:56 |
* dbs |
has had "roll a custom search solution for his university library site" on his todo list for the summer for the same reason |
| 16:57 |
phasefx |
just need to turn every page into a bib record and let EG index it :) |
| 17:10 |
|
mmorgan left #evergreen |
| 17:21 |
* dbwells |
isn't seeing ads on his Google CSE... yet |
| 17:21 |
dbwells |
hmmm |
| 17:29 |
dbwells |
In our CSE control panel, I am seeing under "Edition" "Nonprofit, ads optional." phasefx: not sure if it is reasonable to get evergreen-ils.org into Google's non-profit umbrella, but I would think we have several legitimate ways to pursue that angle. |
| 17:29 |
gmcharlt |
dbwells: good find -- we totally should be able to get under that umbrella |
| 17:37 |
dbwells |
dbs: ^^ certainly would apply to you as well. Obviously I'm not sure how long this will last, or if we are grandfathered into something. Maybe best to get out from under Google's thumb when you have the chance :) |
| 17:37 |
|
kmlussier joined #evergreen |
| 17:37 |
gmcharlt |
https://support.google.com/customsearch/answer/72361?hl=en |
| 17:38 |
gmcharlt |
and https://support.google.com/customsearch/answer/70354?topic=11497 |
| 17:40 |
|
jvwoolf left #evergreen |
| 17:40 |
kmlussier |
gmcharlt++ dbwells++ Bmagic++ |
| 17:41 |
dbwells |
dbs: ah, I guess not so certain for "outside the US", looking at the pages gmcharlt posted. I'm honestly not sure how exactly to interpret what they are saying in that case. Hope it works out for you! |
| 17:41 |
dbwells |
It still sound hopeful, I think. |
| 17:43 |
* dbwells |
does add "move to Custom Search Element V2" to his to-do list |
| 17:43 |
phasefx |
dbwells: the CSE's I have access to are under "non-profit, ads optional". I don't see the one that docs.evergreen-ils.org is using |
| 17:44 |
dbwells |
phasefx: so you were able to turn them off? |
| 17:45 |
phasefx |
dbwells: so it looks like ads are still off for the main website CSE; I had just assumed docs.evergreen-ils.org was among that set, but it's not. So it may very well not be under the non-profit aegis |
| 17:46 |
phasefx |
I don't know who set that one up |
| 17:46 |
dbwells |
phasefx: ah, gotcha |
| 17:46 |
kmlussier |
phasefx: I think rsoulliere may have set that one up. |
| 17:48 |
phasefx |
probably still worth moving to something we have better control of in the long run |
| 17:49 |
kmlussier |
Yes, it was Robert. http://markmail.org/message/gwfsz4jd3vbscpxr |
| 17:50 |
phasefx |
kmlussier++ |
| 17:51 |
kmlussier |
gmcharlt: Since I've been unavailable all day to help with the release, I'll volunteer to go into LP to do the updates. |
| 17:51 |
gmcharlt |
kmlussier++ |
| 17:52 |
gmcharlt |
thanks! |
| 18:20 |
|
Jillianne joined #evergreen |
| 20:30 |
|
jeff___ joined #evergreen |
| 22:20 |
|
genpaku joined #evergreen |
