| Time |
Nick |
Message |
| 06:38 |
|
RBecker joined #evergreen |
| 07:34 |
|
Callender joined #evergreen |
| 07:53 |
|
Callender joined #evergreen |
| 07:59 |
|
akilsdonk joined #evergreen |
| 08:00 |
|
rjackson_isl joined #evergreen |
| 08:00 |
|
graced joined #evergreen |
| 08:07 |
|
collum joined #evergreen |
| 08:18 |
|
_bott_ left #evergreen |
| 08:21 |
|
_bott_ joined #evergreen |
| 08:41 |
|
maryj joined #evergreen |
| 09:06 |
|
ericar joined #evergreen |
| 09:13 |
remingtron |
gmcharlt: The security team wiki seems to have an incomplete sentence in the "restricted resources" section near the end |
| 09:13 |
remingtron |
First bullet: "membership in the private security group on LaunchPad, which will allow them to see and" [should continue?] |
| 09:13 |
gmcharlt |
remingtron: oops, yeah, copy and paste fail |
| 09:13 |
gmcharlt |
thanks for the heads up |
| 09:14 |
jeff |
remingtron: sorry, i don't think you're authorized to know the rest of that sentence... |
| 09:14 |
* jeff |
ducks |
| 09:14 |
remingtron |
gmcharlt: thank you for the proposal |
| 09:14 |
gmcharlt |
jeff: no, we can't let anybody know about the purple cats we have petting access to! |
| 09:14 |
gmcharlt |
... oops |
| 09:14 |
remingtron |
*jeff narrowly misses a plush angry bird |
| 09:15 |
remingtron |
gmcharlt: librarians everywhere would be jealous |
| 09:17 |
gmcharlt |
remingtron: not a copy and paste fail, just an incomplete thought :/ |
| 09:17 |
gmcharlt |
I've fixed it |
| 09:18 |
remingtron |
gmcharlt++ |
| 09:26 |
|
yboston joined #evergreen |
| 09:38 |
csharp |
"which will allow them to see and..." OOOH! A plush angry bird! |
| 09:43 |
|
jboyer-isl joined #evergreen |
| 09:44 |
|
dbwells_ joined #evergreen |
| 09:47 |
|
abowling joined #evergreen |
| 09:52 |
|
ericar_ joined #evergreen |
| 09:53 |
Bmagic |
Does evergreen check to see if a copy will fill a hold when you check it in even if that copy was not the target of the hold? We have a situation where a hold was on a pull list for library A and by the time they came back to check it in, it was filled by library B. The hold targeter hadn't changed the target copy in that time |
| 09:55 |
bshum |
Bmagic: Yeah, that's "opportunistic" hold capture at work. |
| 09:55 |
Bmagic |
bshum: ah! That explains it |
| 09:55 |
bshum |
Where lib B can fill a hold if the hold has been around too long (too long being if you use the settings) |
| 09:56 |
bshum |
We use the "soft stalling" option in the library settings to try to mitigate that. |
| 09:56 |
bshum |
Soft stalling will prevent opportunistic capture by other libraries before X time |
| 09:56 |
bshum |
So in our consortium, for example |
| 09:56 |
bshum |
We use an interval of "3 days" soft stalling |
| 09:57 |
Bmagic |
interesting |
| 09:57 |
Bmagic |
I need to bring this up |
| 09:57 |
bshum |
To give the pickup library up to 3 days to opportunistically capture the item |
| 09:57 |
bshum |
Before it's open season to any library that owns a copy and checks it in |
| 09:57 |
bshum |
This operates separately from the hold targeter. |
| 09:57 |
bshum |
Which may select any library anyways |
| 09:57 |
bshum |
But only the pickup lib can initiate an opportunistic capture with any copy initially. |
| 09:58 |
bshum |
If you haven't seen it, I highly recommend this powerpoint slides from an earlier Evergreen conference where folks from ESI tried to "explain" how holds work: |
| 09:58 |
bshum |
http://evergreen-ils.org/~corinne/Hippos_Final.ppt |
| 09:59 |
Bmagic |
bshum++ |
| 09:59 |
bshum |
It's a little older, but still helpful for the basic ideas. |
| 09:59 |
bshum |
Though things have evolved ever so much with all the newer features for hold targeting in 2.4+ |
| 10:00 |
bshum |
But in any case, the behavior you described is... "normal" |
| 10:00 |
bshum |
That's basically the "whoever is fastest wins" default. |
| 10:00 |
bshum |
Tell Library A to stop slacking, obviously.... |
| 10:00 |
bshum |
:D |
| 10:03 |
Bmagic |
lol |
| 10:03 |
jboyer-isl |
Bmagic: we have some experience messing with that. EI went from 2-3 days of soft stalling to 0, now we’re back at 1 day for specifically the reason you mentioned about the hold pull list. |
| 10:05 |
Bmagic |
So, if the hold is targeted on library's A's copy. Library A has 2 copies but they can't find the exact barcode that it calls for, then the other copy should fill the hold just fine? |
| 10:06 |
collum |
\me has a desire to write up a LP enhancement for a popup that reads "Stop Slacking" |
| 10:06 |
bshum |
Uh, it depends. |
| 10:06 |
bshum |
So if the pickup library is library A, then yes, any copy at Library A will work. |
| 10:06 |
bshum |
But if the pickup library is Library B, and it's a "targeted" hold at a specific copy at Library A, then it will only work with that specific copy. |
| 10:07 |
bshum |
Until the hold stalling period ends, and then any copy from anywhere will work. |
| 10:07 |
bshum |
Basically it's the least number of transits required idea |
| 10:07 |
bshum |
If you're going to pick it up at that library, any copy there shall do. |
| 10:08 |
bshum |
If you've got to send it somewhere, only send what we're asking for, no more. |
| 10:08 |
bshum |
Unless the hold has been waiting around too long, then please send the next available copy, anybody! |
| 10:09 |
|
Newziky joined #evergreen |
| 10:09 |
Bmagic |
3 days seems weird |
| 10:09 |
Bmagic |
because the hold targeter will pick a different copy anyway every 24 hours |
| 10:09 |
bshum |
It was the happy medium that worked for our consortium. |
| 10:09 |
bshum |
Originally, we were 5 days actually. |
| 10:09 |
bshum |
Because our first two pilot libraries were estimated to be about 5 days apart. |
| 10:10 |
Bmagic |
Your hold targeter doesn't change the target every 24 hours? |
| 10:10 |
bshum |
In terms of trying to calculate based on how often the delivery truck went to the libs in question. |
| 10:10 |
bshum |
We still need to play more with proximity to try grouping libs into better combinations for delivery. |
| 10:11 |
bshum |
But meh |
| 10:11 |
bshum |
It depends on the item. |
| 10:11 |
Bmagic |
so, you changed your hold targeter as well? |
| 10:11 |
bshum |
Nope, that's just what it is. |
| 10:11 |
bshum |
It doesn't *always* pick a new copy from elsewhere. |
| 10:11 |
bshum |
And not all libs check their pull list consistently every day. |
| 10:11 |
bshum |
So some will do it twice a week |
| 10:11 |
bshum |
And others will do it four times a day. |
| 10:11 |
Bmagic |
so, you see why I'm confused about a soft stall for any interval greater than 24 hours? |
| 10:12 |
bshum |
It gives the pickup library a few days to get their act together. |
| 10:12 |
bshum |
The hold target may shift constantly |
| 10:12 |
bshum |
But opportunistic capture at the pickup lib can happen at any time within those initial 3 days. |
| 10:13 |
bshum |
So if a hold is captured by target elsewhere in the consortium, then yeah whatever, it locks on that, and that's the copy you get. |
| 10:13 |
bshum |
Unless you use more settings to trump that and use the local copy first. |
| 10:13 |
Bmagic |
So it shows up on thier pull list even though it's targeted a different copy in the meantime? |
| 10:13 |
bshum |
No, it's not about the pull list |
| 10:13 |
bshum |
It's about check-in |
| 10:13 |
bshum |
You asked about during checkin, do holds get checked and filled |
| 10:13 |
bshum |
And yes, they do, opportunistically at the pickup lib level |
| 10:14 |
bshum |
These are separate things; opportunistic holds work at the same time as targeted holds |
| 10:14 |
csharp |
argh - we should really stop letting people clone and edit reports |
| 10:14 |
Bmagic |
csharp: I agree! |
| 10:15 |
csharp |
I spend literally hours getting a template just right, then someone clones and mangles it and I end up having to fix it |
| 10:15 |
csharp |
@tantrum |
| 10:15 |
pinesol_green |
csharp: No, you're a puzzleheaded kraken! |
| 10:15 |
bshum |
It's too microscopic to try defining the scenario, in reality, you've got dozens of copies and lots of holds at the same time. |
| 10:15 |
* csharp |
stops whining and gets back to it ;-) |
| 10:15 |
jeff |
csharp: what's that you say? you'd prefer that a smaller subset of people DESIGN the reports, and then there's an easier self-service means of running them? |
| 10:16 |
csharp |
jeff: haha |
| 10:16 |
* csharp |
knows what's coming |
| 10:16 |
jeff |
csharp: seems like there's a library doing something along thoes lines somewhere... |
| 10:16 |
* jeff |
grins |
| 10:16 |
csharp |
exactly |
| 10:17 |
collum |
jeff beat me too it ;-) |
| 10:17 |
bshum |
Bmagic: So the soft stall of 3 days is mainly to give the pickup library a good interval to get the book back and check it in, to capture the next hold and get it to fill for that. Instead of having any checkin at any library that has that copy to capture, transit, and fill the hold. |
| 10:17 |
bshum |
Bmagic: This is separate from the hold targeting process itself, which does try for a new target every 24 hours (based on when the hold was placed and how often you run hold_targeter) and that's what drives the pull lists and tells people what they should pull from the shelves to check in and see if it's still needed. |
| 10:18 |
Bmagic |
bshum: Back to my original scenario where library B filled A's hold opportunistically. With the soft stall in place for library A, this would not be possible? I'm confused because the hold targeter will target a different copy, and the other library might be commaned to pull it and fill it, during the stall interval for A |
| 10:18 |
|
afterl joined #evergreen |
| 10:18 |
bshum |
Bmagic: That is correct. It's whoever is faster in that scenario you describe then. |
| 10:18 |
csharp |
the soft stall was originally invented to deal with PINES courier delays, which were serious at the time, but those delays went away (probably before the feature was fully implemented) |
| 10:18 |
bshum |
*still whoever was faster |
| 10:19 |
csharp |
so people in our consortium who don't remember those days wonder why there's a 5 day stall |
| 10:19 |
bshum |
Even if we don't have courier delays, irregular hold pull list checking, etc., the perception of delays still makes people feel better knowing that they've got the chance to use their copy to fill the hold ahead of transit copies, if they're efficient about it. |
| 10:20 |
bshum |
So I go back to my earlier statement: "Tell Library A to stop slacking, obviously...." |
| 10:21 |
Bmagic |
Im still fuzzy on this. Let me ask another question that might help. If the hold is inside of the soft stall interval, nobody can fill the hold opportunistically except the library who has the soft stall? |
| 10:22 |
bshum |
Bmagic: To be honest, I've never used soft stalling settings except consortially. So I do not know what happens if you only apply it to a specific library. |
| 10:22 |
Bmagic |
OK, consortially then |
| 10:22 |
bshum |
If it's consortial, then only the pickup library can capture opportunistically. |
| 10:22 |
bshum |
Everyone else checks in normally |
| 10:23 |
bshum |
And only uses their copy for targeted holds |
| 10:23 |
bshum |
Or holds that are past the soft stalling and can be captured opportunistically. |
| 10:23 |
Bmagic |
I got it |
| 10:24 |
Bmagic |
bshum++ #OMG holds |
| 10:25 |
* bshum |
mostly gets it. |
| 10:26 |
|
Dyrcona joined #evergreen |
| 10:29 |
kmlussier |
I think soft stalling was the one setting we had the most trouble figuring out when we were learning about Evergreen holds. |
| 10:30 |
* kmlussier |
doesn't think any of the MassLNC consortia are using it. |
| 10:30 |
* bshum |
disappears to head over for his next meetings |
| 10:31 |
bshum |
Good luck, Bmagic++ # stay strong! |
| 10:31 |
Bmagic |
LOL! |
| 10:32 |
|
dreuther joined #evergreen |
| 10:48 |
|
ericar joined #evergreen |
| 10:51 |
|
mllewellyn joined #evergreen |
| 10:58 |
hopkinsju |
bshum++ |
| 10:58 |
hopkinsju |
Just got caught up on this. We should do a conference session titled #OMG HOLDS |
| 10:59 |
hopkinsju |
We can do the OMG part and bshum can explain everything |
| 11:09 |
csharp |
hopkinsju++ |
| 11:10 |
csharp |
@quote add < hopkinsju> Just got caught up on this. We should do a conference session titled #OMG HOLDS. We can do the OMG part and bshum can explain everything. |
| 11:10 |
pinesol_green |
csharp: The operation succeeded. Quote #108 added. |
| 11:16 |
|
vlewis joined #evergreen |
| 11:24 |
hopkinsju |
heh |
| 11:38 |
|
kbutler joined #evergreen |
| 11:39 |
|
bmills joined #evergreen |
| 11:45 |
jeff |
I swear I just saw the string "facepalm" in this SRU output... |
| 11:46 |
|
jihpringle joined #evergreen |
| 11:50 |
|
bmills joined #evergreen |
| 11:50 |
|
bmills1 joined #evergreen |
| 11:55 |
bshum |
Bleh |
| 11:55 |
bshum |
0898 hates me |
| 11:55 |
bshum |
Oh wait, I know why |
| 11:55 |
bshum |
Stupid restore |
| 11:56 |
bshum |
Darn search_path gets me every time |
| 11:57 |
jeff |
i want to kill those lingering issues. |
| 11:57 |
jeff |
the only good fix that i'm aware of is to fully qualify. |
| 11:58 |
bshum |
Right. |
| 12:02 |
|
sandbergja joined #evergreen |
| 12:05 |
Dyrcona |
Let me check my restore script, I think we fix it in a script we run after. |
| 12:07 |
Dyrcona |
Yep: ALTER DATABASE :db_name SET search_path=evergreen, public, pg_catalog; |
| 12:08 |
Dyrcona |
with -v db_name=actual_database_name on the command line |
| 12:09 |
Dyrcona |
And, I don't think it is necessary (or didn't used to be) if your database user's name is evergreen. |
| 12:09 |
Dyrcona |
IIRC, postgres looks in a schema named for the current user, then in public, then in pg_catalog by default, but as always, I could be wrong or misremembering. |
| 12:14 |
jeff |
pg_restore still breaks some things. |
| 12:14 |
jeff |
because it will explicitly set the search path. |
| 12:15 |
jeff |
so unless you're also hand-editing the pg_restore commands, you're going to be doing things like (at least) re-creating a few indexes that fail due to search path. |
| 12:15 |
jeff |
though it's possible that THAT was fixed and I just missed that it's been fixed in more-recent versions. |
| 12:15 |
jeff |
I'll try and bother to look. |
| 12:16 |
Dyrcona |
We haven't had trouble with indexes in quite a while. |
| 12:16 |
Dyrcona |
We do have trouble with config.z3950_index_field_map from time to time. |
| 12:17 |
Dyrcona |
So, we check if select * returns anything and if not, we insert the values that should be in the table in our script we run post-restore. |
| 12:18 |
Dyrcona |
Just below setting the path, actually. |
| 12:18 |
Dyrcona |
I believe the index problems were fixed at some point. |
| 12:20 |
bshum |
~search_path |
| 12:20 |
pinesol_green |
After restoring a database, make sure to reset the search_path accordingly with something like: alter database unpredicable_haxxors_go_away set search_path = evergreen, public, pg_catalog; |
| 12:20 |
bshum |
Yeah. |
| 12:20 |
pastebot |
"Dyrcona" at 64.57.241.14 pasted "MVLC's post restore SQL script." (22 lines) at http://paste.evergreen-ils.org/44 |
| 12:26 |
jeff |
Dyrcona: and you no longer have issues with the by_heading_and_thesaurus or by_heading indexes in the authority schema? |
| 12:28 |
|
mglass_ joined #evergreen |
| 12:28 |
jeff |
"issues" meaning "they break at pg_restore time due to oils_xpath_string not being in the search path" |
| 12:36 |
* csharp |
noticed that if he uses PGUSER=postgres that the restore drops things but doesn't with PGUSER=evergreen |
| 13:08 |
Dyrcona |
jeff: No, we don't have that one any more. Forget what fixed it. |
| 13:08 |
jeff |
Dyrcona: thanks. |
| 13:09 |
* Dyrcona |
was AFK for a bit. |
| 13:09 |
jeff |
the nerve. |
| 13:18 |
Dyrcona |
heh |
| 14:10 |
kmlussier |
gmcharlt / eeevil: Do you know if work is being done on webby at the moment? |
| 14:12 |
gmcharlt |
kmlussier: not at the moment; does it need a kick? |
| 14:12 |
kmlussier |
I'm not retrieving any results when I try catalog searches. |
| 14:13 |
jeff |
new feature. prevents "the result at position 2 should OBVIOUSLY be at position 1" complaints. |
| 14:13 |
Dyrcona |
:) |
| 14:13 |
jeff |
also, permanently ends argument about what the default search order should be! |
| 14:14 |
Dyrcona |
I tought it was to prevent DOS by running an insane search that returns the whole database. |
| 14:14 |
jeff |
that ability is now restricted to only GoogleBot |
| 14:15 |
jeff |
(and Yandex, if you set the proper OU setting) |
| 14:17 |
|
afterl joined #evergreen |
| 14:18 |
gmcharlt |
kmlussier: kick duly administered |
| 14:18 |
kmlussier |
gmcharlt++ |
| 14:18 |
gmcharlt |
Harry Potter retrieval service now restored |
| 14:19 |
kmlussier |
Ha! It's spooky how you said that just as I saw the harry potter search results filling the screen. |
| 14:19 |
Dyrcona |
:) |
| 14:21 |
* gmcharlt |
is now musing about organizing a super-library-geeky social event at #egconf15 that would have the effect of reshuffling all of our default catalog searches ;) |
| 14:22 |
kmlussier |
That would be fun. |
| 14:23 |
kmlussier |
My default search is "pugs", but I never use it on systems with test data because it rarely pulls up results. Interestingly, it does get a couple of hits on webby. |
| 14:28 |
|
bmills joined #evergreen |
| 14:39 |
bshum |
I need to add my own "star trek" bib record to the stock data :) |
| 14:40 |
bshum |
I usually do "mozart" as my concerto test. And "Harry potter" if I want that one sample :) |
| 14:40 |
Dyrcona |
We should add a bunch of "fictional" books written by community members, with notes extolling things they've done for Evergreen. |
| 14:41 |
bshum |
That would be hilarious |
| 14:41 |
bshum |
And awesome |
| 14:41 |
bshum |
Yeah, where is the book of Evergreen? That totally needs to be original cataloged... |
| 14:42 |
Dyrcona |
Yeah. |
| 14:42 |
kmlussier |
When I'm creating records in a test system, I usually do "Kathy's adventures in Evergreen." |
| 14:43 |
kmlussier |
There's also a serial version: "Kathy's journal of Evergreen." |
| 14:47 |
Dyrcona |
I've got some books on the shelf in my office with barcodes on them that I use if I need test copies. |
| 14:49 |
Dyrcona |
I don't usually create MARC data. |
| 14:50 |
Dyrcona |
We actually have a barcode prefix for our central site, though we do not have a circulating collection. |
| 14:52 |
Dyrcona |
Cataloged a Coca Cola bottle once, now that I think of it. |
| 14:54 |
dbs |
Hmm. Running through acquisitions PO notes, I had a use case for copying and pasting multi-line notes and hoping the formatting would stick |
| 14:55 |
dbs |
Munged it all onto one line, of course. |
| 14:55 |
dbs |
But, imagine my surprise and delight when sticking in <br> tags introduced linefeeds into the output! |
| 14:55 |
dbs |
So now I "just" need to teach the notes widget to convert line feeds to <br> tags and bob's my uncle |
| 14:58 |
Dyrcona |
small matter of programming. :) |
| 15:01 |
bshum |
Yay, open source! |
| 15:02 |
collinanderson |
just don't open up any xss holes :) |
| 15:09 |
dbs |
collinanderson: I wouldn't be opening up any that don't already exist. heh. |
| 15:09 |
gmcharlt |
dbs: good plan! |
| 15:09 |
gmcharlt |
;) |
| 15:46 |
Dyrcona |
Oh noes!!! |
| 15:50 |
|
maryj joined #evergreen |
| 15:53 |
|
bshum joined #evergreen |
| 15:55 |
jeff |
vague ticket is vague. |
| 16:01 |
Dyrcona |
Yes, it is. |
| 16:01 |
bshum |
csharp: I hate my email response already and want to add more supplemental asterisk with expanded explanations for everything I said about upgrade and version-upgrade scripts. |
| 16:02 |
bshum |
The whole thing is a mess :) |
| 16:02 |
bshum |
And I'm glad we run master instead where it's neatly sequential without any gaps. |
| 16:07 |
jboyer-isl |
@hate Launchpad search |
| 16:07 |
pinesol_green |
jboyer-isl: The operation succeeded. jboyer-isl hates Launchpad search. |
| 16:08 |
kmlussier |
@whocares Launchpad search |
| 16:08 |
pinesol_green |
kmlussier, Dyrcona and jboyer-isl hate Launchpad search |
| 16:08 |
bshum |
Launchpad search sucks. |
| 16:09 |
bshum |
My head is filled with the names and descriptions of so many bugs now... past, present |
| 16:09 |
Dyrcona |
I seriously think it only searches bug titles, even in advanced search. |
| 16:09 |
jboyer-isl |
my terms are unique, ugly, weird, and should only retrieve the one ticket I’m looking for, but no. |
| 16:09 |
bshum |
They haunt my dreams |
| 16:09 |
kmlussier |
Does it really, though? I sometimes find the problem has nothing to do with Launchpad, but everything to do with the fact that I describe problems in an entirely different way than somebody else. |
| 16:09 |
maryj |
Can the launchpad search be enhanced at all? |
| 16:10 |
maryj |
(or is that my hopeful optimism showing?) |
| 16:10 |
bshum |
kmlussier: Typos too. |
| 16:10 |
bshum |
:) |
| 16:10 |
Dyrcona |
"Why can't search work like [insert multi-billion dollar online corporation here]?" |
| 16:10 |
bshum |
maryj: To be honest, I usually just use google search and append whatever I'm looking for with "Evergreen launchpad" |
| 16:11 |
bshum |
And 90% of the time, that gets me a link to the real LP bug entry that I was hoping for ;) |
| 16:11 |
Dyrcona |
I just got to create a new bug. That usually finds the one I'm looking for. |
| 16:11 |
bshum |
Or I just search my email to find the reference too. |
| 16:11 |
bshum |
Which is also gmail, so, heh |
| 16:11 |
kmlussier |
I think it would help if the default search included more types of bugs. I know duplicates are automatically excluded as well as ones marked as opinion or invalid. |
| 16:12 |
Dyrcona |
yeah, I sometimes search my bug email folder. |
| 16:13 |
jboyer-isl |
git tells me the thing I’m searching for has not been changed. Does anyone know whatever happened to any discussion of the money.m_b_x_open_xacts_idx index? It’s only an index on money.billable_xact (usr) and doesn’t have anything to do with xact_finish being null (as the name implies) |
| 16:14 |
jeff |
jboyer-isl: do you recall discussion? |
| 16:15 |
jboyer-isl |
I could have sworn I saw someone ask about it at some point, but Google tells me I’m making it up. :-/ |
| 16:17 |
Dyrcona |
My email search tells me you're making it up, too. :) |
| 16:17 |
Dyrcona |
'Course, I'll have saved bug mails back to November 9, 2012. |
| 16:17 |
Dyrcona |
I only have... |
| 16:17 |
jboyer-isl |
Anyway, I find myself needing such an index and didn’t know if I had missed a fix for it. Apparently not. |
| 16:17 |
Dyrcona |
I could check the dev list. |
| 16:19 |
Dyrcona |
Nothing on the dev list back to 2008 either. |
| 16:20 |
Dyrcona |
I hate to start a flame war, but I don't think we should be mucking with the schema on point (i.e. bug fix) releases. |
| 16:23 |
jboyer-isl |
Oh well. Thanks for the sanity check everyone. I’ll look into my project a little more and then probably hit launchpad so no one can find my bug later. ;) |
| 16:23 |
jboyer-isl |
Dyrcona: agreed (re: schema) |
| 16:24 |
jonadab |
As a general principle, I (in complete and total ignorance of the specific thing being referred to) would tend to agree with that. |
| 16:24 |
Dyrcona |
The schema is the database layout, including tables and columns. |
| 16:25 |
jonadab |
Right, I know what a schema is. |
| 16:25 |
jonadab |
I meant I don't know of the specific schema mucking that is being discussed. |
| 16:25 |
Dyrcona |
I think if a bug fix requires a change to the schema, then it should not go into a point release. |
| 16:25 |
Dyrcona |
I'm speaking in general terms, not to anything specific. |
| 16:25 |
jonadab |
Oh, I see. |
| 16:25 |
jonadab |
In that case I would tend to agree. |
| 16:25 |
Dyrcona |
A discussion of running database upgrade scripts came up on the general mailing list. |
| 16:26 |
* csharp |
hates when he drops closing quotes and parens |
| 16:26 |
jonadab |
Unless the bug is extremely important (think: data loss crash) and the schema change can be done in a backward-compatible way. |
| 16:26 |
* Dyrcona |
hates when he makes any kind of typo. |
| 16:27 |
* Dyrcona |
usually lets it go when others do. |
| 16:27 |
csharp |
jboyer-isl: you may be remembering when I learned the need for m_b_voider_idx to speed up patron merge |
| 16:29 |
csharp |
Dyrcona: in theory, I agree with you - it would be great if the DB was static throughout a major release's lifetime and point releases just fixed EG application-level stuff |
| 16:29 |
jboyer-isl |
csharp: Possibly. There doesn’t appear to be a whole lot else I could be remembering at this point. |
| 16:30 |
csharp |
jboyer-isl: I mention it because it wasn't in email and I know you were there when I was working on it ;-) |
| 16:31 |
csharp |
but since so much app logic has moved to the DB, I can see that it's probably necessary to add DB stuff to even point releases |
| 16:32 |
gmcharlt |
well, a distinction could be made between changing table structures and changing stored procedures |
| 16:33 |
csharp |
true |
| 16:33 |
gmcharlt |
the latter being (oftne, but not always) easier to backport |
| 16:33 |
gmcharlt |
as long, of course, as tables that they use haven't changed |
| 16:33 |
gmcharlt |
:) |
| 16:37 |
|
afterl joined #evergreen |
| 16:38 |
|
dreuther_ joined #evergreen |
| 16:38 |
|
mglass joined #evergreen |
| 16:38 |
bshum |
gmcharlt: You know I've often wondered about that |
| 16:38 |
|
chatley_ joined #evergreen |
| 16:38 |
|
vlewis_ joined #evergreen |
| 16:38 |
bshum |
In terms of seeing whether we can minimize the actual changes in minor versions vs. major versions. |
| 16:39 |
bshum |
I've been told before by postgresql developers that they've found our schema changes in even minor versions of Evergreen to be a little weird. |
| 16:41 |
gmcharlt |
FWIW, Koha has a reasonably strict policy that new stuff goes in master and only bugfixes get backpatched |
| 16:41 |
Dyrcona |
Do bugfixes include schema changes in Koha, or is that always considered new stuff? |
| 16:41 |
|
vlewis joined #evergreen |
| 16:41 |
gmcharlt |
there are exceptions, of course, but there's rather less DB schema churn during maintenance release cycles as a consequence of that policy |
| 16:41 |
|
mglass joined #evergreen |
| 16:42 |
|
chatley joined #evergreen |
| 16:42 |
Dyrcona |
We are supposed to have a similar policy, but I think we elide the definition of bug fix a bit. |
| 16:42 |
|
dreuther joined #evergreen |
| 16:42 |
gmcharlt |
Dyrcona: there's some of that elision in Koha too, but less |
| 16:44 |
Dyrcona |
It's kind of funny that bshum and I would be pushing this, since we both run master and therefore shouldn't care. :) |
| 16:44 |
gmcharlt |
looking at the changes in the Koha 3.18.x maint cycle so far, the only actual schema changes as such are one change of a column type and adding an index |
| 16:44 |
Dyrcona |
I'd have no problem with adding an index. |
| 16:46 |
gmcharlt |
yeah |
| 16:46 |
Dyrcona |
The question of how to run the upgrade scripts or problems with them come up often enough, though. |
| 16:46 |
bshum |
Heh, CREATE INDEX IF NOT EXISTS, it's fun reading threads that google throws at you |
| 16:47 |
gmcharlt |
idempotence is a virtue :) |
| 16:47 |
Dyrcona |
eeevil's deprecates idea sound like it would help. |
| 16:48 |
gmcharlt |
Dyrcona: I AM THE ONE TRUE REINGEST. ALL OTHERS ARE DEPRECATED BEFORE ME |
| 16:48 |
gmcharlt |
;) |
| 16:49 |
* bshum |
should look again at sqitch |
| 16:49 |
* bshum |
saw a presentation about it once at a PGCon |
| 16:49 |
bshum |
http://sqitch.org/ |
| 16:49 |
Dyrcona |
gmcharlt: haha. But my reingest forks. ;) |
| 16:50 |
gmcharlt |
your reingest is legion? /me ducks |
| 16:50 |
Dyrcona |
ha |
| 16:54 |
|
afterl left #evergreen |
| 16:58 |
Dyrcona |
Have a good weekend, everybody! |
| 17:01 |
|
phasefx_ joined #evergreen |
| 17:03 |
kmlussier |
Hooray - it's quitting time! See y'all on Monday! |
| 17:05 |
berick |
It's 5 o'clock somewhere! Oh yeah, here. |
| 17:07 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 17:20 |
* berick |
calls 0915 |
| 17:24 |
* csharp |
answers "Hello? Hello, this is 0915, is anyone there?" |
| 17:26 |
berick |
"have you checked the children?" |
| 17:26 |
csharp |
heh |
| 17:32 |
pinesol_green |
[evergreen|Bill Erickson] LP#1234220 Improve hold/copy ratio renewal messages - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=06a35b3> |
| 17:32 |
pinesol_green |
[evergreen|Bill Erickson] LP#1234220 hold ratio renewal override perms - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=919a07d> |
| 17:32 |
pinesol_green |
[evergreen|Bill Erickson] LP#1234220 Stamping DB upgrade copy/ratio messages - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=2acd1c2> |
| 17:51 |
|
Newziky left #evergreen |
| 17:59 |
|
akilsdonk joined #evergreen |
| 19:27 |
|
bmills joined #evergreen |
| 21:25 |
|
akilsdonk joined #evergreen |
| 22:34 |
|
book` joined #evergreen |
