| Time |
Nick |
Message |
| 03:21 |
|
Jillianne joined #evergreen |
| 05:00 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
| 07:16 |
|
rjackson_isl joined #evergreen |
| 07:22 |
|
agoben joined #evergreen |
| 08:08 |
|
kmlussier joined #evergreen |
| 08:43 |
|
mmorgan joined #evergreen |
| 08:52 |
|
bos20k joined #evergreen |
| 09:01 |
|
_adb joined #evergreen |
| 09:03 |
|
Dyrcona joined #evergreen |
| 09:14 |
Bmagic |
@coffee [someone] |
| 09:14 |
* pinesol_green |
brews and pours a cup of Kenya AA Kiaora Estate Full City Roast, and sends it sliding down the bar to eady |
| 09:15 |
Bmagic |
@coffee [someone] |
| 09:15 |
* pinesol_green |
brews and pours a cup of Guatemala El Diamante, and sends it sliding down the bar to dbwells |
| 09:15 |
Bmagic |
@coffee [someone] |
| 09:15 |
* pinesol_green |
brews and pours a cup of Colombia El Castillo Micro-Lot Nelson Melo, and sends it sliding down the bar to sbrylander |
| 09:15 |
Bmagic |
@coffee [someone] |
| 09:15 |
* pinesol_green |
brews and pours a cup of Honduras David Mancia, and sends it sliding down the bar to wsmoak |
| 09:15 |
Bmagic |
@coffee [someone] |
| 09:15 |
* pinesol_green |
brews and pours a cup of Kenya Peaberry Muthunzunni Estate, and sends it sliding down the bar to ericar |
| 09:15 |
Bmagic |
Let's make it a round 5 cups |
| 09:16 |
Dyrcona |
Bmagic: Moonlighting as a barista? |
| 09:16 |
Bmagic |
yep! |
| 09:16 |
Dyrcona |
@coffee [band] |
| 09:16 |
* pinesol_green |
brews and pours a cup of Kenya Bourbon French Mission, and sends it sliding down the bar to Ejabberd and the Shapers |
| 09:16 |
Bmagic |
lol |
| 09:18 |
Dyrcona |
Ah, bterm=, Chazya is doing a browse. I should have suggested trying a regular search. |
| 09:20 |
|
Freddy_Enrique joined #evergreen |
| 09:23 |
csharp |
@oprah [coffee] |
| 09:23 |
* pinesol_green |
Ba ba ba dook Dook DOOK! |
| 09:24 |
|
jvwoolf joined #evergreen |
| 09:30 |
Freddy_Enrique |
<h1>Hi world!<h1> |
| 09:33 |
|
yboston joined #evergreen |
| 09:33 |
|
jvwoolf left #evergreen |
| 09:34 |
kmlussier |
pinesol_green never gives me coffee. zoia, on the other hand, gives me coffee or tea on a regular basis. |
| 09:34 |
pinesol_green |
kmlussier: PHRASING!!! |
| 09:35 |
csharp |
pinesol_green++ |
| 09:36 |
csharp |
@sing The Beatles : You Never Give Me Your Coffee |
| 09:36 |
pinesol_green |
csharp: http://cat.evergreen-ils.org.meowbify.com/ |
| 09:37 |
kmlussier |
@coffee [someone] |
| 09:37 |
* pinesol_green |
brews and pours a cup of Nicaragua SHG, and sends it sliding down the bar to dbs |
| 09:37 |
kmlussier |
@tea [someone] |
| 09:37 |
* pinesol_green |
brews and pours a pot of Bi Luo Chun Green Tea (Pi Lo Chun), and sends it sliding down the bar to Bmagic (http://ratetea.com/tea/teavivre/bi-luo-chun-green-tea-pi-lo-chun/6490/) |
| 09:39 |
Dyrcona |
@coffee kmlussier |
| 09:39 |
* pinesol_green |
brews and pours a cup of Kenya Peaberry Ruera Estate, and sends it sliding down the bar to kmlussier |
| 09:39 |
kmlussier |
Dyrcona: :) |
| 09:40 |
|
jvwoolf joined #evergreen |
| 09:42 |
JBoyer |
csharp: long lost Beatles hit, "I wanna hold your coffee" |
| 09:43 |
|
jvwoolf joined #evergreen |
| 09:43 |
Dyrcona |
"Baby, you can drink my coffee" |
| 09:44 |
Dyrcona |
All You Need Is Coffee! |
| 09:44 |
Dyrcona |
Sgt. Coffee's Lonely Beans' Club Band? |
| 09:45 |
Dyrcona |
We all live in a yellow coffee bean, a yellow bean... :) |
| 09:45 |
* Dyrcona |
waits for Dell's ecommerce site to load. |
| 09:45 |
JBoyer |
I ain't got nothin but coffee, babe, 8 days a week. |
| 09:46 |
JBoyer |
It feels like 8 days a week because now I experience time differently from you, I think you should call somebody. |
| 09:46 |
Dyrcona |
JBoyer: Stop drinking the espresso. :) |
| 09:46 |
|
maryj joined #evergreen |
| 09:46 |
|
maryj_ joined #evergreen |
| 09:46 |
Dyrcona |
And Dell says I have no saved items when I saved four or five carts last week.... |
| 09:47 |
Dyrcona |
They're supposed to last for 2 weeks. |
| 09:48 |
Dyrcona |
One more: I'd like to be under the sea, in a coffee plantation with you... |
| 09:48 |
mmorgan |
Dyrcona: I guess Dell doesn't want you to buy their computers. |
| 09:48 |
kmlussier |
All the coffee people. Where do they all come from? |
| 09:48 |
Dyrcona |
mmorgan: IIRC, they make a distinction between saved items and saved carts, and they make the latter difficult to find because....Dell. ;) |
| 09:48 |
Dyrcona |
mmorgan++ |
| 09:49 |
Freddy_Enrique |
So much coffee in here... |
| 09:49 |
mmorgan |
It must be "Talk like a barista day" |
| 09:49 |
Dyrcona |
@band add The Coffee Beatles |
| 09:49 |
pinesol_green |
Dyrcona: Band 'The Coffee Beatles' added to list |
| 09:49 |
Dyrcona |
:) |
| 09:50 |
kmlussier |
@praise [band] |
| 09:50 |
* pinesol_green |
National Donut Day is the very model of a modern major hacker |
| 09:50 |
Dyrcona |
Ah ha! The cart icon expands to a menu with the saved carts. |
| 09:51 |
mmorgan |
:) |
| 09:52 |
Dyrcona |
Now, if I can find where they hid the email cart feature. |
| 09:53 |
JBoyer |
Oh, mmorgan, I had a thought about the client upgrade issues you mentioned yesterday. You have multiple opac servers, yes? |
| 09:53 |
mmorgan |
Yes, we do. |
| 09:54 |
mmorgan |
And I remember more detail. Users would attempt the partial, and if that failed, they would attempt the Full. Many would get a message that the update could not be "verified" |
| 09:55 |
JBoyer |
Yup. /openils/var/updates/ has to be identical between all of the servers that a client might connect to. |
| 09:55 |
kmlussier |
gmcharlt++ #I knew that sticky flat text editor issue sounded familiar. |
| 09:56 |
JBoyer |
What's going on is that a client is asking server 1 for info on the updates (including some identifying information, a hash perhaps) but then downloads the update files from server 2, which has a different hash, and is rejected. |
| 09:59 |
mmorgan |
Makes sense, so it sounds like copying the contents of /openils/var/updates from one server to all the others should solve the issue? |
| 10:00 |
JBoyer |
Yeah. And after every rebuild. |
| 10:01 |
JBoyer |
May help with the partials, I'm less sure of that because I've never worried about them. |
| 10:01 |
mmorgan |
JBoyer++ # Good advice! |
| 10:02 |
kmlussier |
@praise JBoyer |
| 10:02 |
* pinesol_green |
JBoyer can run a report without assistance |
| 10:02 |
Dyrcona |
True dat! |
| 10:02 |
Dyrcona |
:) |
| 10:02 |
mmorgan |
That makes me hopeful for a smooth upgrade on the user end. |
| 10:03 |
Dyrcona |
mmorgan: We get around that by hosting /openils/var/updates on a NFS server. |
| 10:04 |
mmorgan |
Interesting. And the client knows where to find it? |
| 10:05 |
Dyrcona |
Yes, because the brick head load /openils/var/updates from NFS. |
| 10:06 |
Dyrcona |
I only build the clients once, on the machine hosting NFS. |
| 10:07 |
mmorgan |
Dyrcona++ # More good advice! |
| 10:07 |
Dyrcona |
Also, I never did look into why this happens. You'd think the same software would produce the same results on similar hardware and data, but apparently not. |
| 10:08 |
Dyrcona |
I also have a hunch why the Linux updates never work, but it's a bit late to try fixing that now. |
| 10:08 |
mmorgan |
Yes, xul client updates won't be necessary for much longer :) |
| 10:22 |
Freddy_Enrique |
Guys, If I were to ask which is more difficult about Evergreen.... Installation, configuration or (maybe I'm missing something else)? |
| 10:25 |
bshum |
Freddy_Enrique: It depends on a lot of different variables I think |
| 10:25 |
bshum |
Like who's doing the installation, what kind of experience they have |
| 10:26 |
bshum |
But I'm not sure what you mean when you ask "difficulty" comparing those two |
| 10:26 |
bshum |
Since there might be different goals or intentions behind either one |
| 10:26 |
Freddy_Enrique |
Well, since it was my first time, kind of difficult |
| 10:26 |
JBoyer |
Dyrcona, "reproducible" builds are actually extremely difficult to accomplish. I think someone recently tried to make this possible for NetBSD and it was an enormous hassle. |
| 10:27 |
Freddy_Enrique |
Now Im begining with the library unit types |
| 10:27 |
JBoyer |
(If nothing else, they put the build time in the kernel, so...) |
| 10:27 |
Dyrcona |
JBoyer: Yep. |
| 10:27 |
Freddy_Enrique |
In other words, just starting |
| 10:27 |
bshum |
For myself, the first time I tried to install Evergreen back in 1.4 era like 8 years ago, I thought it went perfectly easy |
| 10:27 |
dbs |
Debian was working on it for quite a while: https://wiki.debian.org/ReproducibleBuilds |
| 10:27 |
kmlussier |
Yeah, I was thinking the size of your library/consortium is another variable. |
| 10:30 |
Freddy_Enrique |
Say for example, Im gonna start with one library... but in the process little by little can I integrate other libraries or I need to anticipate which libraries are gonna be part of the consortium? |
| 10:30 |
Dyrcona |
JBoyer dbs: I think it would be a little easier with xul updates, since they are basically archives of bdiff information. |
| 10:30 |
csharp |
@band add Farmer Brown |
| 10:30 |
pinesol_green |
csharp: Band 'Farmer Brown' added to list |
| 10:30 |
csharp |
@band add Sea of Green |
| 10:30 |
pinesol_green |
csharp: Band 'Sea of Green' added to list |
| 10:31 |
* csharp |
had to get the Carrollton contingency represented |
| 10:31 |
Dyrcona |
Freddy_Enrique: You can add new libraries later, but it is easier if you anticipate that by making your hierarchy flexible. |
| 10:31 |
kmlussier |
Freddy_Enrique: Yes, you can integrate other libraries as they come on board. But as you grow, it will affect the hardware you need to support the system. |
| 10:31 |
Dyrcona |
Freddy_Enrique: The default hierarchy of Consortium -> System -> Branch is pretty flexible in that regard. |
| 10:31 |
dbs |
So what's the thinking on Ubuntu for EG 2.12 production - Xenial, or not yet? |
| 10:32 |
bshum |
dbs: I'm not that brave to recommend it yet. |
| 10:32 |
bshum |
But it depends... |
| 10:32 |
Dyrcona |
dbs: I believe Bmagic is using Xenial in production. |
| 10:32 |
bshum |
If you're not using Acq |
| 10:32 |
bshum |
Then it might be easier :) |
| 10:32 |
dbs |
Oh we're using Acq |
| 10:32 |
Dyrcona |
pfft. |
| 10:32 |
kmlussier |
What's the problem with acq and xenial? |
| 10:32 |
Dyrcona |
You think of the ruby stuff, bshum? |
| 10:33 |
bshum |
Dyrcona: That's kind of what I was afraid of. I know we've added some fixes for it, but having not tried it personally (having divorced myself from acq, yay!) I didn't want to make any calls there. |
| 10:33 |
dbs |
I don't like going through the effort to upgrade while remaining on a 3-year-old OS, but stable > newer |
| 10:33 |
dbs |
ah, we use acq but no edi |
| 10:33 |
Dyrcona |
It works, but you have to install the stuff manually and skip the rcov gem. |
| 10:34 |
|
cfarley joined #evergreen |
| 10:34 |
Dyrcona |
I'm considering moving to Xenial for production, but time may not allow it. |
| 10:34 |
csharp |
dbs: we're planning to move to 2.12/16.04 over Labor Day |
| 10:34 |
Freddy_Enrique |
Great! and finally, is there any recommendation which Library should be in charge of the server where the EG software is implemented? |
| 10:34 |
csharp |
we may keep our DBs on 14.04/PG 9.4 though |
| 10:35 |
jeff |
csharp: The Carrollton Contingency itself would probably make a good band name. |
| 10:35 |
bshum |
In the past, what I ended up doing was keeping our utility server and such on older Ubuntu distros since the upkeep tended to require more thorough testing |
| 10:35 |
csharp |
@band add The Carrollton Contingency |
| 10:35 |
pinesol_green |
csharp: Band 'The Carrollton Contingency' added to list |
| 10:35 |
dbs |
Well, for the first test upgrade I'll give Xenial a run and see what happens |
| 10:35 |
csharp |
jeff++ |
| 10:35 |
bshum |
But move the app servers and DB servers ahead to the latest Ubuntus |
| 10:35 |
dbs |
you people and your multiple app/utility servers :) |
| 10:35 |
Dyrcona |
I'm going to go with Xenial and Pg 9.5 on our new DB server that we should be ordering from Dell today. |
| 10:35 |
* berick |
used to play bongos in The Carrollton Contingency |
| 10:36 |
csharp |
we're about to create utility03 to handle A/T shi |
| 10:36 |
csharp |
stuff |
| 10:36 |
* dbs |
*was* the bongos in the Carollton Contingency |
| 10:36 |
Dyrcona |
ha! |
| 10:36 |
Dyrcona |
Look up Bongo's Trousers on youtube. Thank me later. :) |
| 10:37 |
Dyrcona |
Unless you can't stand a bit of profanity, then don't look it up. :) |
| 10:37 |
Bmagic |
dbs: yes Xenial all the way |
| 10:38 |
kmlussier |
Freddy_Enrique: In our case, we have a central consortium office that is not a library that hosts the server. If there is a library that has the space and has better technical skills among its staff, that would be a good first choice. |
| 10:38 |
dbs |
xenial was what I used for the master builds of my PWA efforts at EGConf and seemed fine, but the depths of A/T and such... who knows :) |
| 10:38 |
dbs |
Bmagic++ |
| 10:39 |
kmlussier |
Freddy_Enrique: Also, following up on what I said earlier about size of the consortium, I'll refer back to what dbs just said about multiple app/utility servers. In our consortium we have Evergreen running on several bricks. |
| 10:39 |
Bmagic |
dbs: It's been working just fine for us. The EDI stuff works too :) |
| 10:39 |
Dyrcona |
dbs: A/T seems to work fine, I've run them on test databases copied from production. |
| 10:39 |
dbs |
excellent! |
| 10:39 |
kmlussier |
Once you need to move to multiple servers, I think it increases the complexity of maintaining the system. But I'm not a systems person - that's just what I've observed. |
| 10:39 |
Dyrcona |
I use Xenial for my test and development vms, mostly. |
| 10:39 |
cfarley |
I'm trying to have evergreen start automatically after a reboot, but having an issue. |
| 10:40 |
cfarley |
When run from a cron job autogen.sh stalls out, but if I run the script manually, it doesn't have any issues. |
| 10:40 |
cfarley |
Anyone played with this before? |
| 10:40 |
Bmagic |
dbs: We did have a problem in the beginning, where I was theoretically thinking that the issue was xenial. It ended up being something else, but there were stages where I troubleshot on 14.04 |
| 10:40 |
Freddy_Enrique |
Thank you Kmlussier |
| 10:40 |
Dyrcona |
Freddy_Enrique: As an example of what kmlussier is talking about, we have over 100 member libraries, and run Evergreen services on over 20 virtual machines, with 2 dedicated database servers, 1 for live use, and a replicant for reporting only. |
| 10:40 |
|
collum joined #evergreen |
| 10:41 |
csharp |
cfarley: this is our init script (based on others efforts and customized for our needs) - might be a good start |
| 10:41 |
csharp |
http://git.evergreen-ils.org/?p=contrib/pines/genasys.git;a=blob;f=templates/init/eg_opensrf;h=e67ab04c7538704e989efad3e9f0e120d3664c25;hb=HEAD |
| 10:42 |
Dyrcona |
cfarley: autogen.sh makes some assumptions about the environment that are likely not true when run from cron. |
| 10:42 |
bshum |
Running autogen every restart seems unnecessary to me. But I guess it wouldn't hurt. |
| 10:42 |
Dyrcona |
And, no sourcing bashrc will not help.... |
| 10:42 |
csharp |
not sure about systemd compatibility :-/ but we're about to find out since we're moving to 16.04 :-) |
| 10:44 |
cfarley |
csharp: Thanks, I'll check it out. |
| 10:45 |
Dyrcona |
csharp++ |
| 10:45 |
cfarley |
Dyrcona: I assumed it has something to do with that, but my digging was mostly unhelpful. |
| 10:46 |
Dyrcona |
cfarley: That init script that csharp shared should help with getting it to work with cron. |
| 10:46 |
Dyrcona |
The variables set at the top, mainly. |
| 11:02 |
cfarley |
csharp,Dyrcona: that was exactly what I needed. Thank you both! |
| 11:03 |
JBoyer |
csharp, systemd isn't so bad, I just haven't found time to make what I put together available. They're sitting in my inbox, I should at least throw them in a paste I guess. |
| 11:08 |
pastebot |
"JBoyer" at 64.57.241.14 pasted "opensrf.service for csharp to experiment with" (23 lines) at http://paste.evergreen-ils.org/171 |
| 11:09 |
pastebot |
"JBoyer" at 64.57.241.14 pasted "clark-kent.service for csharp to experiment with" (16 lines) at http://paste.evergreen-ils.org/172 |
| 11:09 |
JBoyer |
I don't have service files for SIP or Z39.50 yet because I don't have those setup on my 16.04 laptop. |
| 11:13 |
berick |
JBoyer++ |
| 11:14 |
Dyrcona |
JBoyer: systemd is dah eebil! :) |
| 11:14 |
berick |
more than one person may profit from these pastes today |
| 11:14 |
Dyrcona |
Indeed. |
| 11:14 |
* berick |
goes back in time to save a hippogriff |
| 11:14 |
dbs |
branchify into Open-ILS/examples/systemd ! |
| 11:14 |
berick |
+1 to that |
| 11:15 |
dbs |
JBoyer++ |
| 11:15 |
JBoyer |
Since there's still a couple years left on 14.04 I should probably throw my upstart scripts in there too if versions of them haven't already made it. |
| 11:19 |
Freddy_Enrique |
Anyone ever tried to use HexChat? Cant get this thing to work |
| 11:20 |
Freddy_Enrique |
https://snag.gy/nHucCT.jpg |
| 11:24 |
berick |
JBoyer: did you manually create apache2-ws.service? |
| 11:24 |
JBoyer |
in 16.04 if you do the usual re: apache and the apache-websockets profile it just works automatically. (I just don't like -websockets) |
| 11:25 |
JBoyer |
There aren't any apache systemd files, but it's popular enough that it's handled specially by the default setup. |
| 11:25 |
berick |
ah, i was looking in the wrong place. /run/systemd/generator.late/apache2-websockets.service |
| 11:26 |
JBoyer |
Ah, yeah, if you do follow those instructions my service won't work as is. |
| 11:27 |
berick |
JBoyer: now i'm curious, where are you putting your service files? |
| 11:28 |
JBoyer |
The default system location I think, but I don't remember where that is. (my only 16.04 install is currently at home) |
| 11:29 |
berick |
i see most stuff in /lib/systemd/system |
| 11:29 |
berick |
JBoyer: *nod* |
| 11:29 |
JBoyer |
I remember having to do a lot more google searches than I thought were necessary. |
| 11:29 |
JBoyer |
That sounds right. |
| 11:37 |
Dyrcona |
Freddy_Enrique: I use Pidgin. |
| 11:48 |
|
csharp joined #evergreen |
| 11:52 |
Bmagic |
Just for a sanity check: Is there a way to delete pre-cat items from the staff client? |
| 11:53 |
JBoyer |
Bmagic, Item Status |
| 11:53 |
Bmagic |
shoot, it's not in the right click menu |
| 11:54 |
Bmagic |
"actions for catalogers" gotcha! |
| 11:56 |
kmlussier |
Freddy_Enrique: I use HexChat. It works for me. Like Dyrcona, I had also used Pidgin at one time. I don't remember why I switched. |
| 11:57 |
Freddy_Enrique |
Just in case..Im gonna try Pidgin. Dont really have an explanation why Hex doesnt work |
| 11:58 |
dbs |
Freddy_Enrique: sometimes known IRC ports are blocked by certain networks |
| 11:59 |
Freddy_Enrique |
T_T, not fair |
| 11:59 |
|
Christineb joined #evergreen |
| 12:00 |
dbs |
per https://freenode.net/kb/answer/chat try chat.freenode.net:7000 or chat.freenode.net:7070 instead perhaps? |
| 12:05 |
kmlussier |
Yes, that's true. When I work from the library, I can't use an IRC client. I have to use the web gateway. |
| 12:10 |
Freddy_Enrique |
Ok. its a fact. IRC app doesnt like me |
| 12:10 |
Freddy_Enrique |
and the library's network |
| 12:11 |
Freddy_Enrique |
Kmlussier, I'm pretty sure thats my case too. Gonna try again at home |
| 12:13 |
Freddy_Enrique |
thanks guys |
| 12:42 |
Dyrcona |
Freddy_Enrique: Freenode requires people on some IP address ranges to use SASL for authentication. |
| 12:43 |
Dyrcona |
If you're not in the USA, that is possibly the case for you. |
| 12:48 |
Dyrcona |
kmlussier: There are a number of reasons to switch from Pidgin. :) |
| 12:49 |
Freddy_Enrique |
One day... I'll be there in a visit :) |
| 12:49 |
kmlussier |
Dyrcona: Yeah, I originally used Pidgin because it was a nice way to bundle IM and IRC all in one place. Then I moved to Quassel and when I left Quassel, I realized I didn't really have a need for IM anymore. |
| 12:50 |
kmlussier |
Freddy_Enrique: Maybe for an Evergreen conference someday! :) |
| 12:50 |
Dyrcona |
I've never gotten SASL to work with Freenode and Pidgin, so I have to use web chat when tethered to my cell phone. |
| 12:50 |
Dyrcona |
I have considered switching. |
| 12:50 |
Freddy_Enrique |
for sure kmlussier |
| 13:11 |
|
jihpringle joined #evergreen |
| 13:31 |
JBoyer |
So, here's an "am I sane" Q: what if I want to delete everything about deleted bibs from metabib.*, (leaving reporter.simple_r_r alone, for reports obviously). |
| 13:32 |
JBoyer |
I'm thinking about this because well over half of the rows in metabib.keyword_field_entry are from deleted bibs. I know about #deleted, statistically speaking no one uses it, and I suspect it may be literally 0 here. |
| 13:33 |
JBoyer |
In a discussion about search speed at an old, established installation, that may be the first thing to look at. |
| 13:35 |
* berick |
has had similar thoughts |
| 13:35 |
berick |
never made it past the thought stage, though |
| 13:36 |
JBoyer |
I'm fairly sure it doesn't hurt anything to remove them, but the larger Q is really "when / do we start doing this automatically." |
| 13:36 |
JBoyer |
Ooh, one benefit of a dev server, I can start that now and see what effect it has on the pep without any worry. Hmm. |
| 13:37 |
berick |
if you put together a purge script, plz share :) |
| 13:38 |
JBoyer |
Day one is just going to be a bunch of by hand stuff followed up by doing the same KW search on prod and dev. If it does make a noticable diff I'll share that out and fingers crossed it'll be part of an upgrade script later... |
| 13:39 |
miker |
JBoyer: we could extend the use of tmp_bool in biblio.indexing_ingest_or_delete |
| 13:39 |
JBoyer |
miker, oh, that would be perfect. |
| 13:40 |
bshum |
Dyrcona wrote a delete bibs script for Biblio in the old days; it went through more exhaustive removal of deleted bibs that aren't connected to anything of importance |
| 13:41 |
JBoyer |
Since I'm assuming this may not be considered "The way things are now" a global flag makes more sense to me than a YOUS, because bre.owner doesn't mean anything yet. |
| 13:42 |
miker |
JBoyer: aye, global flag, indeed |
| 13:43 |
Dyrcona |
That script that bshum mentioned only removes bibs that had no copies, etc. |
| 13:45 |
JBoyer |
Huh. I guess I don't see the point in deleting the attrs if we're intentionally leaving the other stuff. Anyone remember why that is? (for instance, if you're searching for a #deleted bib and there are a lot of languages in your sys, you might prefer to include item_lang='eng', which won't work anymore) |
| 13:46 |
kmlussier |
I like the idea. |
| 13:47 |
JBoyer |
Dyrcona, I'm also not *too* worried about bre necessarily. I mean, there are a lot of dead bibs in there, but just having 1 copy of useless data is better than 4-5 copies of it clogging our field indexes. Though I suppose it did have to address these and other tables to do it's job. |
| 13:48 |
Dyrcona |
JBoyer: Staff can access deleted bibs, so if you remove the metabib info, they will not turn up in searches for staff. |
| 13:48 |
JBoyer |
(I hope this DELETE doesn't come back 2 hours after I leave with a "nope, you have to delete this table at the same time, etc.) |
| 13:49 |
Dyrcona |
JBoyer: It might. :) |
| 13:49 |
JBoyer |
Maybe I'll just cancel it and go for 1 bibid to test. I'd like to be able to test things this week. :p |
| 13:50 |
kmlussier |
Staff searches bring up deleted records? That doesn't sound right. |
| 13:50 |
JBoyer |
kmlussier, if you know to type #deleted into a search box. |
| 13:50 |
kmlussier |
Oh, yes. Ignore me. |
| 13:51 |
JBoyer |
Which almost no one does because we don't make a big deal out of it anywhere and there's no checkbox on the adv page. |
| 13:51 |
JBoyer |
So no loss, really. |
| 13:51 |
JBoyer |
(and gigs of gain...) |
| 13:52 |
csharp |
@band add Gigs of Gain |
| 13:52 |
pinesol_green |
csharp: Band 'Gigs of Gain' added to list |
| 13:52 |
Dyrcona |
@praise [band] |
| 13:52 |
* pinesol_green |
Shall I compare Ejabberd Confit to a summer's day? Ejabberd Confit is more lovely and more temperate. |
| 13:52 |
csharp |
haha |
| 13:53 |
kmlussier |
What's the use case for staff searching for deleted records and does this use case come up very often? Assuming that they know about it or that we make it easier for them to know about it. |
| 13:54 |
Dyrcona |
Library staff probably never do it. Central site might do it once in a while for {{reasons}}. :) |
| 13:54 |
Dyrcona |
I admit it would be extremely limited use cases. |
| 13:56 |
JBoyer |
I usually refer {{reasons}} to the helpdesk. |
| 13:58 |
Dyrcona |
@blame {{reasons}} |
| 13:58 |
pinesol_green |
Dyrcona: Forget it, Jake. It's just {{reasons}}. |
| 13:59 |
Dyrcona |
For most practical purposes, there's no reason to keep the meta data for deleted bibs. |
| 14:09 |
JBoyer |
I like to think Gigs of Gain's 1 hit is Filesystem Compression; a heavy metal song practically barked into the mic. Their experimental album, the classic rock styled Block Level Deduplication lead to the band's breakup 7 months later. |
| 14:10 |
berick |
It used to be about the free space, man |
| 14:13 |
csharp |
@quote add < JBoyer> I like to think Gigs of Gain's 1 hit is Filesystem Compression; a heavy metal song practically barked into the mic. Their experimental album, the classic rock styled Block Level Deduplication lead to the band's breakup 7 months later. |
| 14:13 |
pinesol_green |
csharp: The operation succeeded. Quote #168 added. |
| 14:13 |
JBoyer |
berick++ |
| 14:19 |
* miker |
reads up |
| 14:21 |
jeffdavis |
kmlussier: IIRC you can set a bib to be marked deleted automatically when all copies/volumes are deleted. If you subsequently buy another copy you might prefer to resurrect the deleted bib rather than re-cataloguing from scratch. |
| 14:22 |
miker |
JBoyer: the attr vector list is a required link for record to be found. we delete it when we don't care about #delete and insert it if the record comes back |
| 14:24 |
JBoyer |
Oh, then given the rarity and low volume of un-deletes, would it make sense to just add those deletes to that block in biblio.indexing_injest_or_delete rather than fool with another flag? |
| 14:25 |
miker |
we could do that, or teach metabib.reingest_metabib_field_entries the same internal flag trick |
| 14:26 |
kmlussier |
jeffdavis: Yes, we use that setting here. I wonder how often that really happens in a consortium where there usually is at least one other library that owns the item. I imagine it would mostly happen for specialized materials. But I could be wrong. |
| 14:26 |
kmlussier |
I often am. |
| 14:45 |
jeffdavis |
We've got almost a million bibs that have only one copy attached. Of course, the one that I manually verified was an edition of Ender's Game for which we have at least three separate MARC records... :( |
| 14:46 |
JBoyer |
miker, I suppose we could, but given that there's already a direct trigger on the table it seems like it would make the most sense for it to do all of the reasoning and the metabib.* functions to just charge ahead under the assumption that if they're called it's game on. |
| 14:48 |
miker |
JBoyer: I don't have a strong opinion, really. hopefully we'll be rebuilding ingest anyway :) ... if you've got an itchy git finger, I say KILL 'EM ALL (in the block with attrs) |
| 14:48 |
JBoyer |
jeffdavis, that's something else that may make it easier for us than some other groups, we run a fairly aggressive deduplication after every new migration, and roughly 6-8 months otherwise. If there's a single copy holding here odds are it's some local family history thing or a busted record. |
| 14:48 |
* JBoyer |
turns up the Metallica. |
| 14:50 |
kmlussier |
jeffdavis: Yes, I was also thinking many one-copy records might be ones that are for older titles where there may not be interest in replacement or maybe out-of-print editions where a replacement would require a new record anyway. But, yes, there are the unique and specialized titles as well. |
| 14:50 |
JBoyer |
(PS, tell me more re: rebuilding ingest) |
| 14:51 |
kmlussier |
It's funny how quickly I'm ready to kill a feature at the prospect of it shaving some milliseconds on search retrieval performance. |
| 14:53 |
JBoyer |
kmlussier, everything is milliseconds when there are only 1000 bibs. I'm hoping to shave at least 10,000 milliseconds. |
| 14:54 |
mmorgan |
Those milliseconds add up! |
| 14:54 |
kmlussier |
JBoyer: Even better! |
| 14:55 |
berick |
anyone in these parts outsourcing phone notifications? |
| 14:56 |
miker |
JBoyer: just my ardent desire to make ingest more flexible and to build queued ingest (background ingest) |
| 14:57 |
JBoyer |
Ah. +1 to that. I thought you meant it was an active project somewhere already. |
| 14:58 |
miker |
just a thing that I want to do ATM. but, tuits |
| 14:58 |
JBoyer |
I know all about tuits and the lack thereof. :/ |
| 14:59 |
kmlussier |
Maybe this is crazy talk, but could we change the reingest so that it only excludes deleted records if they were deleted more than x days ago? |
| 15:01 |
jeff |
kmlussier: and then have a maintenance job that purges bibs as the value of x increases over time? |
| 15:01 |
Dyrcona |
kmlussier: We have no idea when a record was deleted at the moment. |
| 15:02 |
Dyrcona |
I don't think the trigger changes the update time. |
| 15:02 |
jeff |
berick: phone / text notification here is asterisk with a SIP trunk and Twilio (mostly for SMS, but we use them for lots of things including SIP trunks)... so I think that's a "no" to your question. |
| 15:02 |
Dyrcona |
jeff: Good luck purging (as in actually deleting) bibs. |
| 15:03 |
kmlussier |
Dyrcona: OK, I was thinking it would be based on edit_date, but if the trigger doesn't change it, I guess that won't work. |
| 15:03 |
jeff |
Dyrcona: i suppose i meant "purges" in the sense of "does what ingest 'excluding deleted bibs' does" -- but maybe i misunderstand kmlussier's idea |
| 15:03 |
Dyrcona |
I might be wrong, but I recall looking and seeing that it does not. |
| 15:04 |
Dyrcona |
jeff: I see, as in remove the existing metadata. I misunderstood you, I think. |
| 15:04 |
berick |
kmlussier: Dyrcona: no reason it can't set the date going forward. new feature land! |
| 15:04 |
miker |
kmlussier: well, a wholesale reingest can skip deleted records already ... just don't touch them WHERE delete = TRUE |
| 15:04 |
berick |
jeff: thanks |
| 15:05 |
Dyrcona |
berick: Right. I should be more optimistic in my assessments. :) |
| 15:05 |
Dyrcona |
Most ingest scripts that I've written/seen do skip deleted records. |
| 15:07 |
jeff |
kmlussier: what did you have in mind with making a decision based on deleted x days ago? |
| 15:12 |
kmlussier |
jeff: Sorry, I was expanding on what JBoyer had been suggesting, but, to maintain the ability to find search some of those deleted records for a period of time, we only delete the metabib entries after a certain number of days. I guess reingest was the wrong word there. |
| 15:15 |
jeff |
it's a useful general term and got the idea across just fine. i think we had a discussion a few weeks ago about that. :-) |
| 15:16 |
jeff |
but yes, a middle ground in terms of hitting the use case of recently deleted bibs vs every deleted bib ever. |
| 15:22 |
JBoyer |
Oh. So, miker, a thought re: background reingest. What about a dirty flag (not worried about the name) in bre that is changed by a trigger on NEW.marc != OLD.marc, and the external process that only grabs X per sweep, does the deed and then sets that flag to false? |
| 15:23 |
JBoyer |
Could either be a proper service (we already had and deleted an ingest service at one point, yes?) or just a thing that happens on a utility server once a minute or so. |
| 15:23 |
jeff |
could even be a flag in an external table. |
| 15:23 |
JBoyer |
Could I suppose. |
| 15:26 |
miker |
JBoyer: well, one feature of queued ingest I think would be key would be a "reason" to let us define priority. update a bib via the marc editor? INGEST NOW! authority-propogation change? can delay a bit. wholesale reingest? whenever you're not ingesting for some other reason. |
| 15:27 |
JBoyer |
Ah, that could be interesting, yes. |
| 15:27 |
miker |
and, of course, compression. so you only reingest a record once, and at the highest requested priority |
| 15:27 |
miker |
so, yeah, external table |
| 15:27 |
miker |
and, also, imagining a NOTIFY-based service that is triggered on demand |
| 15:28 |
miker |
so ... I HAVE IDEAS! :) |
| 15:28 |
miker |
but no tuits |
| 15:28 |
JBoyer |
I don't get to do this that often, but is this on LP? ;p |
| 15:29 |
JBoyer |
(/me has a few to enter also, if memory serves...) |
| 15:29 |
miker |
JBoyer: no, but there's a proposal we've floated to several groups for funding |
| 15:29 |
miker |
it's ... nontrivial ;) |
| 15:29 |
* Dyrcona |
has heard of it before, and it sounds like a good idea to me. |
| 15:29 |
Dyrcona |
yes, definitely nontrivial. |
| 15:34 |
|
cfarley joined #evergreen |
| 16:04 |
|
Jillianne joined #evergreen |
| 16:04 |
kmlussier |
miker: Yeah, that proposal is something that's been sitting on our backburner for a while. I need to get focusing on that at some point. |
| 16:22 |
|
jihpringle joined #evergreen |
| 16:37 |
|
cfarley joined #evergreen |
| 17:00 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
| 17:06 |
|
mmorgan left #evergreen |
| 17:20 |
|
jvwoolf left #evergreen |
| 18:32 |
|
jihpringle joined #evergreen |
| 20:33 |
|
Freddy_Enrique joined #evergreen |
| 22:20 |
|
genpaku joined #evergreen |
