| Time |
Nick |
Message |
| 01:12 |
|
bdljohn joined #evergreen |
| 04:30 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 06:29 |
|
yar_ joined #evergreen |
| 07:01 |
|
agoben joined #evergreen |
| 07:08 |
|
rjackson_isl joined #evergreen |
| 07:31 |
JBoyer |
gmcharlt++ # OSRF 3.1 |
| 08:07 |
|
RMiller joined #evergreen |
| 08:09 |
RMiller |
Good morning/local time of day. Is there a simple way to nuke the catalog, just the catalog, and start fresh? :) |
| 08:10 |
RMiller |
I think I've got the Vandelay mess sorted out, but my various attempts at importing have left me with an awful lot of cleanup |
| 08:16 |
JBoyer |
Just setting deleted=true,active=false on every bib with an id > 0 should do it. It's extremely hard to actually remove them from the database, but that's close enough.' |
| 08:17 |
JBoyer |
(There is a record with an id of -1 though that's important to leave alone) |
| 08:23 |
rhamby |
Just echoing what JBoyer said, while technically to remove all the bits and pieces created by bibs it's a rough slough, not recommended. I'd recommend overlaying them with empty/brief bibs if their presence is really offensive and then marking them deleted as jboyer said. |
| 08:24 |
JBoyer |
I also forgot to mention that doing that doesn't touch call numbers or items if you have any of those loaded, but they can all have deleted=true also and *then* you're fine. (call numbers have a -1 that you need to leave alone also.) |
| 08:30 |
RMiller |
Is that something I would do server-side, or is this going to involve a very large bucket? |
| 08:31 |
JBoyer |
It's 3 SQL statements vs a lot of work in buckets. |
| 08:32 |
JBoyer |
You'll want to do that on the server if you're able to. |
| 08:32 |
RMiller |
3 SQL statements sounds promising |
| 08:32 |
RMiller |
I can, I just don't know how... yet |
| 08:33 |
RMiller |
Can you teach me? |
| 08:34 |
JBoyer |
Not a lot, but I can give you the three things you'll need to run. Once you login to the server console you need to run psql |
| 08:35 |
JBoyer |
It will want to know what database to connect to (usually evergreen) the username and password. "man psql" will tell you how to specify those. |
| 08:35 |
JBoyer |
then this will remove the items: delete from asset.copy; |
| 08:36 |
JBoyer |
and call numbers: delete from asset.call_number where id > 0; |
| 08:36 |
JBoyer |
and finally records: delete from biblio.record_entry where id > 0; |
| 08:37 |
JBoyer |
(Normally you would want to use database transactions when using things like insert, update, or delete, but if you're trying to delete everything anyway it's not such a big deal.) |
| 08:37 |
JBoyer |
does that help? |
| 08:38 |
RMiller |
Testing it now! |
| 08:39 |
JBoyer |
Since I didn't know where you were comfort-wise I tried to make it easy to follow, hopefully that didn't come across condescending. :) |
| 08:39 |
RMiller |
I'm an English teacher fumbling around. You cannot condescend too low :) |
| 08:42 |
RMiller |
The first two returned "DELETE 0" pretty quickly, and the third one is... still... thinking... Does that sound normal? |
| 08:43 |
|
mmorgan joined #evergreen |
| 08:44 |
rjackson_isl |
select count(*) from asset.copy where deleted; should verify deleted items |
| 08:44 |
rhamby |
RMiller: delete 0 is normal |
| 08:45 |
csharp |
RMiller: "delete" in this case means "keep the row, but mark the deleted column 'true'" |
| 08:45 |
rhamby |
RMiller: when you delete you're not really deleting because there's a database rule in place that says "when you delete these don't really delete them but do all this other stuff to make them inactive instead" |
| 08:45 |
csharp |
yeah, what rhamby said ;-) |
| 08:45 |
JBoyer |
yeah, there's a feature on those tables that basically says "if anyone tries to delete anything, do this instead" where the instead part is just setting the deleted field to true. Since nothing is actually deleted in the traditional sense, you get DELETE 0. |
| 08:45 |
RMiller |
It worked! |
| 08:45 |
JBoyer |
Ah, typing too slow :) |
| 08:45 |
rhamby |
what we all said :) |
| 08:45 |
RMiller |
Thank you so much! |
| 08:46 |
JBoyer |
RMiller++ # trying new things! |
| 08:46 |
RMiller |
You guys are great. :) |
| 08:48 |
mmorgan |
JBoyer++ |
| 08:48 |
mmorgan |
rhamby++ |
| 08:48 |
mmorgan |
csharp++ |
| 08:48 |
rhamby |
one of these days in my copious extra time I should do a youtube version of the SQL for librarians preconfernece I do sometimes |
| 08:48 |
* rhamby |
notes that he does not really have copious free time |
| 08:49 |
mmorgan |
copious free time is an oxymoron |
| 08:55 |
csharp |
@who is an oxymoron? |
| 08:55 |
pinesol |
troy__ is an oxymoron. |
| 09:08 |
|
aabbee joined #evergreen |
| 09:13 |
|
yboston joined #evergreen |
| 09:17 |
|
dkyle1 left #evergreen |
| 09:36 |
|
terran joined #evergreen |
| 10:20 |
pinesol |
[evergreen|Bill Erickson] LP1807764 Angular grid gets datePlusTime option - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=9b294be> |
| 10:26 |
JBoyer |
berick, I'm looking at adding a new workstation server setting and noticed most begin with eg. but a few added later don't. Is that just an artifact of their beginnings as browser localstorage items? |
| 10:26 |
JBoyer |
At 132 eg. vs 14 other I thought I'd ask before just picking one or the other. :) |
| 10:28 |
berick |
JBoyer: the grid configs have to start with eg.grid.* |
| 10:28 |
berick |
JBoyer: the others can be named whatever |
| 10:29 |
JBoyer |
Sounds good, no point sticking it on there since there arent' namespace collision concerns. |
| 10:29 |
JBoyer |
berick++ |
| 10:29 |
JBoyer |
(I'm not looking at a grid setting now but will keep that in mind.) |
| 10:40 |
|
jvwoolf joined #evergreen |
| 11:00 |
|
bos20k joined #evergreen |
| 12:06 |
JBoyer |
berick++ # best practices look good. |
| 12:07 |
JBoyer |
I'm extra happy to see the mention of using <label> properly, since I don't want to do a sweep of the whole thing to fix that like I did for autocomplete. :) |
| 12:10 |
berick |
yeah, and that's an easy one to (subconsciously) forget, since it adds work. |
| 12:11 |
|
jihpringle joined #evergreen |
| 12:16 |
mmorgan |
Since upgrading to 3.1.8, we've noticed fields with diacritics being stripped out when loading records in vandelay. |
| 12:16 |
mmorgan |
We see log entries like this: 2019-01-18 11:02:24 brick2 open-ils.vandelay: [WARN:22569:Application.pm:624:1547827174572487] open-ils.vandelay.bib.process_spool: no mapping found for [0xCC] at position 5 in GarciÌ<U+0081>a Lorca, Federico,g0=ASCII_DEFAULT g1=EXTENDED_LATIN at /usr/share/perl5/MARC/Charset.pm line 308. |
| 12:16 |
mmorgan |
Anyone else seen something similar? |
| 12:26 |
|
sandbergja joined #evergreen |
| 12:27 |
sandbergja |
Bmagic: Our branch librarian is interested in testing your fix to bug #1741299 |
| 12:27 |
pinesol |
Launchpad bug 1741299 in Evergreen "DYMO LabelWriter 450 Turbo Hatch Label print fails with margin error" [Undecided,Confirmed] https://launchpad.net/bugs/1741299 - Assigned to Blake GH (bmagic) |
| 12:27 |
Bmagic |
great! |
| 12:27 |
sandbergja |
I'm not very familiar with Hatch, though. Would we need to use a test server with that Evergreen branch enabled? |
| 12:28 |
Bmagic |
the changes to Evergreen are very very small |
| 12:28 |
sandbergja |
And would we have to compile Hatch ourselves? And if so, can it co-exist with Hatch installed from the Chrome store? |
| 12:28 |
Bmagic |
you could edit the single tt2 file manually without having to merge the branch, etc |
| 12:29 |
Bmagic |
compiling Hatch was not that easy. You can install the current hatch software, then overwrite the jar file with one that I could pre-compile |
| 12:29 |
sandbergja |
That sounds do-able! We'd appreciate a compiled Hatch! |
| 12:31 |
Bmagic |
so, install hatch like normal |
| 12:31 |
Bmagic |
then open task manager and make sure all "java" processes are killed |
| 12:32 |
Bmagic |
then download this file https://dropbox.mobiusconsortium.org/pickup/hatch.jar |
| 12:32 |
Bmagic |
and copy that into place at: C:\Program Files (x86)\Hatch\lib |
| 12:33 |
Bmagic |
I accept no repsonsibility for any loss of data/life/computers.... |
| 12:34 |
sandbergja |
hahahaha fair enough |
| 12:35 |
Bmagic |
:) |
| 12:35 |
sandbergja |
And just to check, instead of messing with tt2 files, our branch librarian can copy/paste this template into the label printing UI: https://bugs.launchpad.net/evergreen/+bug/1741299/comments/10 |
| 12:35 |
pinesol |
Launchpad bug 1741299 in Evergreen "DYMO LabelWriter 450 Turbo Hatch Label print fails with margin error" [Undecided,Confirmed] - Assigned to Blake GH (bmagic) |
| 12:36 |
Bmagic |
give it a try, sure |
| 12:36 |
sandbergja |
Cool! We'll report back. Thanks for working on this! |
| 12:36 |
Bmagic |
looking forward to it |
| 12:39 |
Bmagic |
You still need to edit the Evergreen file to match the patch mentioned in the bug |
| 12:39 |
Bmagic |
it gives you a new option in the print configuration that you need to have checked in order to activate the Dymo code within Hatch |
| 12:40 |
sandbergja |
Oh, I see. Thanks for pointing that out. We'll give that a try! |
| 13:54 |
jvwoolf |
Anybody know if the Classic Circulation View source in the reporter includes aged circs? |
| 13:59 |
|
yboston joined #evergreen |
| 14:01 |
csharp |
jvwoolf: it doesn't |
| 14:01 |
JBoyer |
jvwoolf, the definition of reporter.classic_current_circ says nol |
| 14:02 |
* csharp |
doesn't find that view very useful |
| 14:02 |
jvwoolf |
csharp: JBoyer: Thanks |
| 14:02 |
* JBoyer |
should probably see how hard it would be to integrate the dewey from from rccc into acn, since that's the only reason to use it... |
| 14:02 |
jvwoolf |
I only use it for the Dewey Block breakdowns |
| 14:02 |
csharp |
yeah |
| 14:03 |
jvwoolf |
JBoyer: Yes! |
| 14:08 |
JBoyer |
Ooh, the low-impact version would be a new view that only pulls things out of acn where label_class = dewey... Now I'm very interested in playing with this. |
| 14:16 |
|
beanjammin joined #evergreen |
| 14:24 |
csharp |
JBoyer++ |
| 14:25 |
csharp |
I'd be happy to work with you on that (or at least test whatever you come up with) after the dust settles from this weekend's upgrade |
| 14:31 |
JBoyer |
csharp++ |
| 14:31 |
JBoyer |
Good luck! We've been enjoying 3.2 so far. :) |
| 14:36 |
csharp |
thanks - all looks good |
| 14:49 |
|
bos20k_ joined #evergreen |
| 14:59 |
jeff |
mmorgan: regarding your "no mapping found" warnings above: what version were you on prior to this, where you didn't have the issue? |
| 14:59 |
jeff |
mmorgan: do you have a sample file that you can share that trips the issue? |
| 15:00 |
jeff |
mmorgan: and to answer your question instead of just asking more of my own, no -- not seeing similar here on a system running 3.1.x (but likely not 3.1.8). |
| 15:01 |
jeff |
mmorgan: Plenty of "no mapping found" errors from z39.50, but that could be poor records and/or a bad record encoding setting on the source def. |
| 15:07 |
mmorgan |
jeff: We upgraded from 3.0.9 to 3.1.8 |
| 15:10 |
* mmorgan |
will try and procure a sample file. |
| 15:13 |
jeff |
I'm intrigued but can't guarantee that I'll have time to look at it this weekend. Sounds like you have enough to start a bug. |
| 15:13 |
mmorgan |
Weird thing is, the record loads ok, but the marc field with the unmapped character is stripped out of the marcxml before the record gets created in the vandelay record queue |
| 15:14 |
jeff |
Linux distro and versions of relevant Perl modules might also be useful data. |
| 15:27 |
csharp |
jamesrf++ # bug 1783421 |
| 15:27 |
pinesol |
Launchpad bug 1783421 in Evergreen "Manage Copy Alert requires permission granted on consortium level" [Medium,Confirmed] https://launchpad.net/bugs/1783421 |
| 15:43 |
miker |
mmorgan: that sounds a lot like (and, based on your error paste, looks like) badly encoded records. specifically, marc8 encoded records. is that possible? |
| 15:44 |
|
beanjammin joined #evergreen |
| 15:44 |
miker |
as in, the xml related code thinks its dealing with utf8 data, but it's marc8 |
| 16:30 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 16:34 |
|
yboston joined #evergreen |
| 16:42 |
bshum |
Happy Friday everyone, and good luck to all the upgrading Evergreeners this weekend :) |
| 16:42 |
bshum |
I'll be excited to see your shiny upgraded catalogs on Tuesday :) |
| 16:51 |
mmorgan |
Looks like our loading errors are due to an encoding issue, now to track down what changed on 1/4, when it started. |
| 16:51 |
mmorgan |
jeff++ |
| 16:51 |
mmorgan |
miker++ |
| 17:00 |
csharp |
bshum: thanks! |
| 17:00 |
csharp |
who else is upgrading? |
| 17:00 |
mmorgan |
csharp: Good luck! |
| 17:00 |
csharp |
mmorgan: thanks! |
| 17:04 |
* mmorgan |
knows that c/w mars is upgrading. |
| 17:12 |
|
mmorgan left #evergreen |
| 17:50 |
|
sandbergja joined #evergreen |
| 23:00 |
|
sandbergja joined #evergreen |
