Evergreen ILS Website

IRC log for #evergreen, 2014-04-08

| Channels | #evergreen index | Today | | Search | Google Search | Plain-Text | summary | Join Webchat

All times shown according to the server's local time.

Time Nick Message
00:27 zerick joined #evergreen
01:05 timlaptop joined #evergreen
05:14 pinesol_green` Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html>
05:39 jboyer-isl joined #evergreen
05:39 wjr joined #evergreen
05:39 wjr joined #evergreen
05:39 ldwhalen joined #evergreen
05:40 mceraso joined #evergreen
05:40 csharp joined #evergreen
05:40 phasefx joined #evergreen
05:40 bwicksall joined #evergreen
05:40 jboyer-isl joined #evergreen
05:40 jl- joined #evergreen
05:40 Sato`kun joined #evergreen
05:41 BigRig joined #evergreen
05:41 rri joined #evergreen
05:41 b_bonner joined #evergreen
05:41 robbat2 joined #evergreen
05:41 robbat2 joined #evergreen
05:42 wjr joined #evergreen
05:43 dcook joined #evergreen
05:43 gdunbar joined #evergreen
05:43 phasefx2 joined #evergreen
05:43 eeevil joined #evergreen
05:44 tfaile joined #evergreen
05:44 dreuther joined #evergreen
05:44 ktomita joined #evergreen
05:44 Polonel joined #evergreen
05:44 pinesol_green joined #evergreen
05:46 mtate joined #evergreen
05:46 mtj_ joined #evergreen
05:46 book` joined #evergreen
05:46 mtcarlson_away joined #evergreen
05:48 b_bonner joined #evergreen
05:49 RBecker joined #evergreen
05:49 bradl joined #evergreen
05:49 ldwhalen joined #evergreen
05:57 wjr joined #evergreen
06:04 serflog joined #evergreen
06:04 Topic for #evergreen is now Welcome to the #evergreen library system channel! | We are publicly logged. | Large pastes at http://paste.evergreen-ils.org
06:04 pastebot joined #evergreen
06:14 mceraso joined #evergreen
06:15 bshum joined #evergreen
06:27 csharp joined #evergreen
06:27 DPearl joined #evergreen
06:27 jventuro joined #evergreen
06:27 dconnor joined #evergreen
06:27 gsams joined #evergreen
06:28 mtj_ joined #evergreen
06:29 eby__ joined #evergreen
06:30 wjr joined #evergreen
06:32 gmcharlt joined #evergreen
06:39 ldwhalen joined #evergreen
06:40 DPearl joined #evergreen
06:40 dcook joined #evergreen
06:40 jboyer-isl joined #evergreen
06:40 jventuro joined #evergreen
06:40 phasefx2 joined #evergreen
06:40 eeevil joined #evergreen
06:40 gdunbar joined #evergreen
06:40 ktomita joined #evergreen
06:40 timlaptop joined #evergreen
06:43 pinesol_green joined #evergreen
06:44 shadowspar joined #evergreen
08:00 collum joined #evergreen
08:03 akilsdonk joined #evergreen
08:17 wjr joined #evergreen
08:18 mceraso joined #evergreen
08:18 bshum joined #evergreen
08:20 robbat2 joined #evergreen
08:20 robbat2 joined #evergreen
08:27 RoganH joined #evergreen
08:39 Shae joined #evergreen
08:48 mmorgan joined #evergreen
08:49 ericar joined #evergreen
08:59 mrpeters joined #evergreen
08:59 tsbere joined #evergreen
09:03 Dyrcona joined #evergreen
09:26 yboston joined #evergreen
09:44 kbeswick joined #evergreen
09:51 mceraso joined #evergreen
09:51 bshum joined #evergreen
09:51 asimon joined #evergreen
09:52 asimon What is the best way to delete all patrons from the database and load them again (with the same barcode numbers)?
09:53 bshum asimon: Out of curiousity, what are you attempting to gain by doing so?
09:53 Dyrcona asimon: Blow the database out and start over.
09:54 asimon bshum: I'm trying to replace a test set of patrons with the latest information.
09:54 asimon Dyrcona: I can't do that because of all the other information in the database.
09:55 Dyrcona asimon: Then, you're mostly stuck because of referential integrity triggers.
09:55 Dyrcona asimon: Assuming the patrons are tests, shouldn't the rest of the data be test data, too? [Though I guess not.]
09:56 atlas__ joined #evergreen
09:57 bshum In our system, we load student data during new schoolyears and overlay the original entry in Evergreen with new data based on a matching identifier (like student ID or barcode)
09:59 asimon Dyrcona:  No.  I have deleted the sample bib and copy records and I am loading a new set beginning with a different id range, and I want to do the same thing with the patron records, but I'm getting: ERROR:  duplicate key value violates unique constraint "usr_usrname_key"
09:59 Dyrcona asimon: There's a method to obliterate the "deleted" patrons data. I forget what it is off the top of my head.
10:00 Dyrcona Is this a production server, too?
10:00 asimon Dyrcona: It is a new production server and I am loading the initial records.
10:01 Dyrcona asimon: If no one is using it, blow it all out and start over.
10:01 asimon Dyrcona:  I can't.  There are many configuration changes that would be lost.
10:01 Dyrcona asimon: Dump the configuration tables and reload them after.
10:03 asimon Dyrcona:  I am looking for a different solution.
10:03 bshum asimon: I generally prefer advising you the same way Dyrcona is.  It's not good to carry over too much cruft if you can avoid it (you're just setting yourself up for more pain later on, perhaps...)
10:03 bshum But there is the actor.usr_purge_data function
10:04 bshum Which should be what's used by the "obliterate" patron in the staff client side
10:04 asimon bshum:  Please elaborate. How would I use that?
10:05 * mmorgan is interested, too.
10:05 Dyrcona asimon: Look up the function definition in PGAdmin, that should give you the information that you need.
10:05 denishpatel joined #evergreen
10:06 bshum It's good to review what the function does.
10:06 Dyrcona mmorgan: There is a way to trigger it from the staff client.
10:06 Dyrcona ...for an individual patron, at least.
10:06 bshum mmorgan: What it'll do is remove most of the identifying data from a given row in actor.usr and transfer any connecting data to another destination user (like circs, holds, acq, whatever)
10:06 mmorgan Dyrcona: We're interested in doing this for batches of patron records. The one by one thing we use all the time.
10:07 bshum So you specify a source user and the destination user and it'll move all connecting data to the next user before it kills off the first one.
10:07 bshum I'm not sure it's the tool you really want.
10:07 bshum Really depends on the use case
10:08 Dyrcona There's a backend call isn't there, in open-ils.actor or open-ils.circ?
10:08 bshum More than likely
10:08 Dyrcona mmorgan: You'd have to do some programming to obliterate patrons in batches like that.
10:08 bshum I know in the staff client, it'll ask me what user I want to transfer data to
10:09 bshum Or maybe that's only if it's a staff member
10:09 mmorgan figured we'd need a script.
10:09 bshum And otherwise, it'll just move content to the 1 user
10:09 mmorgan bshum: yes, that's only for staff.
10:09 asimon bshum:  How about if I change the username data for each of the old patrons, which would change the usr_username_key values, which would then allow me to load the patrons with the valid usernames (=barcodes)?
10:09 bshum Either way, it's the shotgun approach to things.  I highly dislike it because people mis-use it all the time
10:10 Dyrcona Ah, if it wasn't for those pesky users, our databases would be clean.
10:10 Dyrcona Useless, but clean. :)
10:10 bshum asimon: I would imagine that approach would also work.  But I would encourage you to check also that you've removed any entries from actor.card related to those users or will relink them to the next batch you load accordingly.  Or else I suspect that you'd get conflicts there too for existing barcodes.
10:11 rjackson-isl joined #evergreen
10:11 mmorgan asimon: Are you trying to preserve transactions, and just update patron information? Or just load a new batch of clean patrons?
10:11 Dyrcona Nuke it from orbit. It's the only way to be sure.
10:11 bshum Dyrcona: +1
10:11 bshum Dyrcona++
10:11 asimon bshum:  I have already removed the entries from actor.card.
10:12 asimon mmorgan:  I am not trying to preserve transactions.
10:12 * dbs has some revamping to do to the Library structured data pages to get phone number in the format desired by https://support.google.com​/webmasters/answer/4620709 (just published yesterday)
10:13 asimon bshum:  How about a TRUNCATE CASCADED on actor usr?
10:13 bshum asimon: I wouldn't do that.
10:13 dbs minor, just need to introduce a "ContactPoint" entity
10:14 bshum asimon: Or at least... I would do that with alot of good WHERE clauses limiting what users you're deleting. And you'd better be sure none of them are connected to any bib loading, item editing or whatnot
10:14 bshum But uh, I might have been overzealous in my approaches when I was a newbie admin back then trying to do things the quick and dirty way instead.
10:15 * bshum once deleted his 1 admin user and watched all his bibs and basically everything else vanish too.
10:16 Dyrcona CASCADE will do that, but it depends on triggers, too.
10:16 asimon bshum:  I only need to protect the first three users.
10:17 Dyrcona dbs: I wanted to bug you about schema.org stuff, but maybe later.
10:17 bshum asimon: If we're not laying it on thick enough that there's alot of potential "gotcha's" in all the things you're asking, I'll say it again that what you're asking to do might not be the safest course of action.
10:17 * bshum steps back from the bomb
10:17 Dyrcona dbs: We added some RDA stuff to our record summary, and before I make a Launchpad bug, I wanted to add the necessary linked info attributes.
10:17 dbs Dyrcona: bug me any time you like about schema.org, always happy
10:18 Dyrcona dbs: It may be easier if I post a branch first so you can look at what I'll be asking about.
10:18 dbs Dyrcona: sure, or if you make the Launchpad bug and push your branch I can sprinkle in some schema.org bits while signing off on it
10:18 dbs Dyrcona++
10:18 Dyrcona dbs++
10:18 Dyrcona :)
10:20 bshum Dyrcona++ # wading through RDA
10:20 bshum dbs++ # schema.org bits!  :)
10:21 Dyrcona Now that I mention it, I'm not even 100% sure its all RDA-related.
10:21 ldwhalen joined #evergreen
10:28 dluch joined #evergreen
10:29 kmlussier joined #evergreen
10:32 Dyrcona dbs: I made lp 1304462 for you and everyone else.
10:33 pinesol_green Launchpad bug 1304462 in Evergreen "Add 264 tag values to Record Summary" (affected: 1, heat: 6) [Wishlist,New] https://launchpad.net/bugs/1304462
10:34 Auth-User_ joined #evergreen
10:41 serflog joined #evergreen
10:41 Topic for #evergreen is now Welcome to the #evergreen library system channel! | We are publicly logged. | Large pastes at http://paste.evergreen-ils.org
10:47 jl- joined #evergreen
10:47 dreuther joined #evergreen
10:47 rri joined #evergreen
10:47 bwicksall joined #evergreen
10:48 egbuilder joined #evergreen
10:48 remingtron joined #evergreen
10:48 berick joined #evergreen
10:48 Callender joined #evergreen
10:50 edoceo joined #evergreen
10:52 tfaile joined #evergreen
10:55 phasefx joined #evergreen
10:56 jwoodard joined #evergreen
10:57 Sato`kun joined #evergreen
11:00 yboston Dyrcona++ # wading through RDA
11:01 ericar joined #evergreen
11:03 yboston Dyrcona: let me know how I can help. I don't have a 2.6.x VM set up right now but I can set one up to test RDA or authority code out, etc.
11:06 pmurray_away joined #evergreen
11:10 Dyrcona yboston: That branch should apply to 2.5 at least.
11:10 yboston Dyrcona: that is what I was hoping as I looked at the code
11:11 yboston Dyrcona: would you like me to try it out on my test 2.5.x server?
11:11 Wyuli joined #evergreen
11:11 Dyrcona yboston: If you want to, just cherry-pick the top commit.
11:12 yboston Dyrcona: I will have to do it manually since the tests ervers I have are not git based, but it should not be too hard
11:20 kmlussier joined #evergreen
11:27 Guest25194 joined #evergreen
11:34 Dyrcona Is the dev. meeting today?
11:34 kmlussier Dyrcona: Yup. 2 p.m. EDT
11:34 Dyrcona kmlussier: Thanks. It is not on the community calendar.
11:34 kmlussier I just added it to the developers calendar.
11:35 kmlussier Sorry, I forgot.
11:35 Dyrcona There's a developers' calendar?
11:38 kmlussier Dyrcona: Yes, but all of the Evergreen Google calendars display on that community calendar that's on the wiki. I didn't add it until after you asked the question.
11:40 gerson joined #evergreen
11:45 kmlussier Is Primary Identification Type one of those fields that can't be hidden from the patron registration screen using an OU setting?
11:45 kmlussier I know there are a couple of fields that can't be hidden, but I forget which ones.
11:47 mmorgan kmlussier: I see library settings for ident_value and ident_value2, so I think you can hide that (ident_value)
11:48 kmlussier mmorgan: Yes, I was looking at that. But I think the ident type still displays.
11:49 ktomita joined #evergreen
11:49 kmlussier Looks like Internet Access level is another field that can't be hidden.
11:52 mmorgan ok, I see, you're right. They're both dropdown fields, maybe that's why?
11:54 mcooper joined #evergreen
11:54 * kmlussier shrugs
11:54 jeff it might have more to do with them both being required values at the underlying database layer. it might have been thought better to not hide something that was going to be set anyway.
11:54 kmlussier jeff: That makes sense. Is there a reason they are required in the underlying database?
11:56 eeevil asimon: you could look at using the staged users stuff ... I don't recall if that includes the "merge from staging" functionality or now
11:56 eeevil not
11:56 Christineb joined #evergreen
11:56 jeff i don't believe that there is currently a merge from staging -- you'd create a user from staged, then merge that user with another user.
11:57 jeff (which is a few steps.)
11:57 eeevil asimon: it does not. jeff: right
11:57 * eeevil looks for that code...
12:15 jihpringle joined #evergreen
12:22 bshum kmlussier: I think they're required because PINES required them :)  So we inherit that from them.
12:25 bshum jihpringle: Huh... have you guys updated your test server to 2.6-rc yet?
12:25 ningalls joined #evergreen
12:26 bshum jihpringle: I've got some reports on our test system that the acq/cataloging loader (vandelay) isn't matching anymore and basically just running forever with no results.
12:26 jihpringle bshum: not yet, but we're hoping to have a test server running 2.6rc soon
12:27 bshum jihpringle: All good, I'm digging through things on my end to try figuring out what's happening with our system and if maybe we're just on the tail end of some bad setup
12:27 bshum jihpringle: I'm crossing my fingers that it's something small and we didn't break acq and cataloging before 2.6.0 :\
12:27 jihpringle fingers crossed
12:28 jihpringle I'll find out when we're getting our new test server and take a look at this as soon as we do
12:41 Dyrcona bshum: I've emailed our catalogers to ask them to test Vandelay on our training server. It is up to date as of Friday.
12:41 bshum Dyrcona: Cool, that's appreciated.
12:41 eeevil asimon: http://pastebin.com/nDj80KVW ... that's from a pre-staging schema, custom thing, but I think it's close. it'll update or insert staged patrons, matching on the barcode
12:42 kmlussier bshum / jihpringle / Dyrcona: I just loaded order records on Dyrcona's dev system without any problems.
12:42 bshum kmlussier: Hmm, hmm, that makes me wonder
12:42 bshum I was just musing if it has anything to do with the merge profiles we're employing
12:43 Dyrcona My dev system was updated last Wednesday.
12:43 kmlussier bshum: Let me give it another try. I didn't use a merge profile that would typically be used when loading order records.
12:44 RoganH joined #evergreen
12:45 atlas__ joined #evergreen
12:49 gerson left #evergreen
12:56 kmlussier bshum / jihpringle: I take it back. When using a merge profile that replaces the 901c (match-only merge), I'm seeing a similar issue.
12:56 kmlussier It just keeps spinning. Nothing gets processed and a queue isn't created.
12:57 kmlussier bshum: If you file a bug, I'll be happy to confirm.
12:57 bshum kmlussier: Yeah, that's what mllewellyn reported to me too.  Gah :(
12:57 bshum So I guess if we can't load records in acq or cataloging, this could be a big blocker for 2.6?
12:58 kmlussier +1
12:58 dbs +1
12:59 dbs Even the bestest RDFa in the world isn't going to smooth that over.
13:01 kmlussier Dyrcona: How recent is master on your training server? I know this was working a couple of weeks ago, but if you've updated it since then, it might affect your acq pilots.
13:04 Dyrcona kmlussier: I updated it Friday.
13:05 Dyrcona kmlussier: I reloaded the database, too, forgetting that it would blow out their test acquisitions data.
13:05 Dyrcona On the plus side, they get more acquisitions practice. :)
13:06 Dyrcona +1 to release blocker status
13:06 kmlussier Dyrcona: Heh. I'll send them a quick e-mail asking them to hold off on trying order record uploads for a while.
13:09 Dyrcona kmlussier: OK. Laurie and Regina know about the matching problem.
13:20 mrpeters left #evergreen
13:24 bshum Dyrcona: kmlussier: https://bugs.launchpad.net/evergreen/+bug/1304559
13:24 pinesol_green Launchpad bug 1304559 in Evergreen "acq and cataloging loader broken in 2.6-rc" (affected: 1, heat: 6) [Critical,Confirmed]
13:24 bshum I'll start looking for what's broken next, but I've filed the bug to start
13:24 bshum Well, maybe right after lunch
13:34 * jeff exploits a test wheezy system
13:34 jeff yup.
13:34 jeff that easy.
13:46 bshum 14 minutes till the dev meeting
13:46 bshum There's a few action items on the list from past meeting
13:46 bshum See agenda:  http://wiki.evergreen-ils.org/dok​u.php?id=dev:meetings:2014-04-08
13:46 kmlussier Do we have a volunteer to run the meeting?
13:48 jeff i'll run.
13:49 kmlussier jeff++
14:01 jeff alrighty.
14:01 * berick hears knuckles cracking
14:01 dbs jeff++
14:01 jeff #startmeeting 2014-04-08 - Developer Meeting
14:01 pinesol_green Meeting started Tue Apr  8 14:01:55 2014 US/Eastern.  The chair is jeff. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:01 pinesol_green Useful Commands: #action #agreed #help #info #idea #link #topic.
14:01 pinesol_green The meeting name has been set to '2014_04_08___developer_meeting'
14:02 jeff #info Agenda is at http://wiki.evergreen-ils.org/dok​u.php?id=dev:meetings:2014-04-08
14:02 jeff #topic Introductions
14:02 jeff #info jeff is Jeff Godin, Traverse Area District Library (TADL)
14:02 berick #info berick Bill Erickson, ESI
14:02 RoganH #info RoganH Rogan Hamby, SCLENDS
14:02 kmlussier #info Kathy Lussier, MassLNC
14:03 gmcharlt #info Galen Charlton, ESI
14:03 dbs #info Dan Scott, Laurentian University
14:03 bshum #info Ben Shum, Bibliomation
14:03 dbwells #info dbwells = Dan Wells, Hekman Library (Calvin College)
14:03 remingtron #info remingtron = Remington Steed, Hekman Library (Calvin College)
14:03 eeevil #info eeevil is Mike Rylander, ESI
14:04 jeff While people are making introductions, a small PSA: if you've not read and digested the OpenSSL security advisory from yesterday, go do that instead. Debian Squeeze is unaffected, but if you're running Wheezy or most LTS versionf of Ubuntu, you're probably in need of an openssl upgrade and Apache restart.
14:04 dkyle #info
14:04 gmcharlt jeff++
14:05 jeff #topic Past Action Items
14:05 jeff #action bshum to summarize bug tracking based on feedback from developers
14:06 jeff (based on bshum's status, this is deferred -- anything else to add, ben?)
14:06 bshum Since we decided at the conference to stick with LP, nothing new on that.  Other than it will get done.
14:06 jeff thanks!
14:06 jeff #info eeevil After 2.6.0 is cut, eeevil to publish detailed plan about freezing baseline schemas between EG releases and using deprecates/supersedes in database upgrade scripts. This will go on the mailing list and the thread should structure further discussion of pros and cons of eeevil's plan.
14:06 jeff eeevil: I'm guessing that's holding on 2.6.0 being cut?
14:06 eeevil aye
14:06 jeff #action eeevil After 2.6.0 is cut, eeevil to publish detailed plan about freezing baseline schemas between EG releases and using deprecates/supersedes in database upgrade scripts. This will go on the mailing list and the thread should structure further discussion of pros and cons of eeevil's plan.
14:06 jeff #info dbwells to backport bugfix for Encode.pm (bug 1242999) issues to rel_2_5, feedback requested on backporting to earlier releases
14:06 pinesol_green Launchpad bug 1242999 in Evergreen "Encode.pm 2.54 breaks database functions (naco_normalize, maintain_control_numbers, others)" (affected: 1, heat: 12) [High,Fix committed] https://launchpad.net/bugs/1242999
14:07 dbwells #info done
14:07 jeff #info bshum to go through and update the bug statuses to ?fix released? for things that are done in milestones for 2.4.5 and 2.4.6
14:07 jeff bshum: done and done?
14:08 bshum Yes, though dbwells++ for getting us the LP bugmaster account now for that stuff
14:08 jeff dbwells++ bshum++
14:08 jeff #info done
14:08 jeff #info dbwells to add RM dates to dev calendar
14:08 dbwells #info done, but in a lazy and lackluster fashion
14:09 jeff #info dbwells to summarize Evergreen 2.6 aspects of PostgreSQL 9.3 support in future 2.6 RM reports
14:09 jeff i think that's been addressed as well, and 9.3 blockers dealt with, yes?
14:09 dbwells yes
14:09 jeff #info done!
14:09 jeff #info jeff to start dev:hackfest:eg2014 wiki page and announce on dev list, solicit ideas and further discussion
14:10 jeff #info not done, no longer relevant
14:10 dbwells I didn't even know that was an action item :) http://evergreen-ils.org/dokuwiki​/doku.php?id=dev:hackfest:eg2014
14:10 jeff (my fault -- it was my action item!)
14:10 dbwells Well, it was what it is
14:10 jeff #topic Release info - OpenSRF
14:11 jeff gmcharlt: want to cover this?
14:11 gmcharlt #info OpenSRF 2.3.0 is now available
14:11 jeff gmcharlt++
14:11 dbwells gmcharlt++
14:12 gmcharlt my general thinking is to not pour much effort into rel_2_3 -- specifically, only cut a 2.3.1 if a major bug warrants it, or if timing of Debian Jessie warrants it
14:12 gmcharlt and focus on 2.4.0 for the early summer
14:12 jeff #info OpenSRF 2.3.0 required for Evergreen 2.6, functionality release that introduces a new control script, osrf_control, and significantly improves one?s ability to stop, start, reload, and manage OpenSRF services. It also adds the ability to run multiple OpenSRF instances simultaneously on a single server.
14:12 gmcharlt and provisionally, it looks like the big chagnes for 2.4.0 will be
14:12 jeff #link http://evergreen-ils.org/documentation/r​elease/OpenSRF/RELEASE_NOTES_2_3_0.html OpenSRF 2.3.0 Release Notes
14:12 gmcharlt - web sockets support
14:12 gmcharlt - acting on the CORS support pullrqeuest
14:13 gmcharlt - removal of osrf_ctl.sh
14:13 gmcharlt - general improvements relfecting higher Perl versions in distros and stricter C compiler settings
14:14 jeff #info OpenSRF rel_2_3 branch maintenance-only, focus is on 2.4.0 for early summer 2014: web sockets, CORS, removal of deprecated osrf_ctl.sh, improvements for recent Perl versions and stricter C compiler settings
14:14 gmcharlt a question for the peanut gallery - is anybody inclined to look at the PHP client library pullrequest and try to beat it into shape?
14:15 eeevil gmcharlt: also, hopefully, improved chunking/bundling, to avoid some currently required ejabberd config changes
14:15 gmcharlt eeevil: thanks, I knew I'd missed something
14:15 Sato`kun joined #evergreen
14:15 jeff I can give the PHP client pullrequest a look-see, and solicit others to do so as well.
14:15 jboyer-isl I'd rather it be taken behind the barn, but my distaste for php isn't strictly rational.
14:15 Dyrcona gmcharlt: I looked at the PHP and thought it was in the wrong base repo.
14:15 jeff #info OpenSRF 2.4 also to focus on improved chunking/bundling, to avoid some currently required ejabberd config changes
14:16 Dyrcona My memories of it are fuzzy as that was last year sometime before my brain turned to mush.
14:16 jeff #action jeff to review OpenSRF bug 1109301 for consideration, may solicit the review of others as well
14:16 pinesol_green Launchpad bug 1109301 in OpenSRF "New submission for a client library in php for openSRF" (affected: 1, heat: 6) [Wishlist,Triaged] https://launchpad.net/bugs/1109301
14:16 gmcharlt jeff++
14:16 jeff anything else for OpenSRF release news?
14:17 gmcharlt not from me
14:17 jeff #topic Release Info - Evergreen
14:17 bshum gmcharlt++ # nice summary of cool things to come
14:18 jeff #info Evergreen 2.6 release status
14:18 jeff dbwells: over to you!
14:19 dbwells I my goal is to make as few commits as we can to get to 2.6.0 as soon as possible.
14:19 dbwells Here is a list of outstanding bugs for .0 https://bugs.launchpad.net/​evergreen/+milestone/2.6.0
14:19 pinesol_green dbwells: Error: malone bug 2 not found
14:19 dbwells uh, okay
14:19 jeff #link https://bugs.launchpad.net/​evergreen/+milestone/2.6.0 Outstanding bugs targeted at Evergreen 2.6.0
14:20 bshum Well that was unexpected
14:20 dbwells 8 of those 10 bugs are really simple polishing bugs
14:20 dbwells 2 are big problems which are effectively blockers.
14:21 jeff #info Blockers
14:21 dbwells 1 was just added a few hours ago
14:21 jeff #link https://bugs.launchpad.net/evergreen/+bug/1304559 acq and cataloging loader broken in 2.6-rc
14:21 pinesol_green Launchpad bug 1304559 in Evergreen "acq and cataloging loader broken in 2.6-rc" (affected: 3, heat: 18) [Critical,Confirmed]
14:21 jeff #link https://bugs.launchpad.net/evergreen/+bug/1303940 Bogus data can lead to null values, breaking indexing
14:21 pinesol_green Launchpad bug 1303940 in Evergreen "Bogus data can lead to null values, breaking indexing" (affected: 2, heat: 10) [High,New]
14:21 jeff those two, right?
14:21 kmlussier Not that I consider it close to critical, but is there any chance bug 1301567 could get in 2.6.0? It makes the MVF work a little more useful.
14:21 pinesol_green Launchpad bug 1301567 in Evergreen "Catalog needs more format icons" (affected: 1, heat: 8) [Undecided,New] https://launchpad.net/bugs/1301567
14:22 dbwells Yes, thanks jeff.  I had 2.6.0 provisionally on the calendar for tomorrow.
14:22 dbwells Then 2.6.1 just two week after that.
14:24 dbwells kmlussier: I'll take a look at that bug.  I don't think I considered it because it wasn't targetted at all.
14:24 jeff are the blockers likely to push 2.6.0 past tomorrow?
14:24 asimon eeevil:  TY.  I think that this function will work.
14:24 kmlussier dbwells: Yes, looks like I fogot to do that. I can target it now.
14:24 dbwells kmlussier: thank you!
14:25 eeevil I'll raise my hand for 1304559 ... I think dbwells is on the right track in the bug comment
14:25 bshum fwiw, we added the icons kmlussier mentions in the branch to our test system and it seemed fine.  So I'd be happy to push things along.
14:25 gmcharlt jeff: I think 1303940; since it looks like Dyrcona has reviewed it and given a (virtual) signoff, I'll do a final test and push it today
14:25 gmcharlt s/1303940/1303940 is/
14:26 dbwells jeff: I guess we'll see :)
14:26 Dyrcona I'd like to see some thought given to dbwells' suggestion on 1303940.
14:26 gmcharlt (and look at dbwells comment)
14:26 Dyrcona heh
14:26 jeff #info Evergreen 2.6.0 provisionally on calendar for tomorrow, April 9 with 2.6.1 to follow two weeks later.
14:27 jeff Anything more to add on 2.6?
14:28 dbwells no, I think we are good
14:28 jeff dbwells++ # RM2.6
14:28 bshum dbwells++ # wrangling and moving things forward
14:28 * gmcharlt issues final reminder re bug 1302113
14:28 pinesol_green Launchpad bug 1302113 in Evergreen 2.6 "acknowledgments in release notes" (affected: 1, heat: 6) [Undecided,New] https://launchpad.net/bugs/1302113
14:28 kmlussier dbwells++
14:28 gmcharlt namely, now's your chance to push any final ack updates to the collab branch
14:28 Dyrcona dbwells++
14:29 jeff #info Please review the acknowledgements for Evergreen 2.6 and make any additions/updates
14:29 jeff #link https://bugs.launchpad.net/evergreen/+bug/1302113 bug 1302113 - acknowledgments in release notes
14:29 pinesol_green Launchpad bug 1302113 in Evergreen 2.6 "acknowledgments in release notes" (affected: 1, heat: 6) [Undecided,New]
14:29 dbwells eeevil: I did a very quick test of subbing in record_attr_flat for record_attr in vandelay._get_expr_push_jrow().  So far, nothing exploded, but I haven't tested it very hard yet.
14:29 jeff #info Evergreen 2.5 bug fixes?
14:30 jeff dbwells: you're still wearing the release maintainer hat for 2.5, correct?
14:30 eeevil dbwells: that will work fine, I'm only concerned about performance ... my plan is to look directly at the vector
14:31 dbwells eeevil: that would be even better
14:31 dbwells jeff: yes
14:32 dbwells jeff: I don't have much to say about though, other than to say the maintenance release was skipped for March, but is planned for the regular date next week.
14:32 jeff #info Evergreen 2.5 maintenance release planned for April 16
14:32 jeff dbwells++ # double duty
14:33 jeff #info Evergreen 2.4 - final release?
14:33 eeevil I'll align that with dbwells' next week
14:33 eeevil after pushing in as many fixes as we can safely
14:34 jeff #info Final planned Evergreen 2.4 maintenance release scheduled for April 16
14:35 jeff eeevil, dbwells: any specific things that either of you would like to call attention to in terms of things that you'd like more testing/eyeballs on for any of the above releases?
14:35 dbwells jeff: nothing I can think of, thanks
14:36 eeevil nothing specific
14:37 jeff moving on!
14:37 * bshum hijacks the agenda
14:37 jeff before we move on to "Feedback for New Features Under Development
14:38 jeff ", I wanted to stick in an agenda item for bshum's RM 2.7 proposal, since that's where the "feedback for new features" part of the meeting idea came from (iirc)
14:39 jeff #topic New Business
14:39 jeff #info Release Manager proposal for Evergreen 2.7
14:39 bshum #link RM 2.7 email - http://markmail.org/message/b23u62e6rhebjkhk
14:40 bshum So as promised at the in-person dev meeting, I did do a short writeup of some of the general plans or ideas on the table for 2.next (or 2.7 or whatever we're going to call it)
14:41 bshum I was curious if we have any further feedback on that before we get started with laying out the next steps.
14:43 kmlussier It all looks great to me.
14:43 kmlussier bshum++
14:43 dkyle item 1 from that is why I'm here
14:44 dkyle plus just looking to get involved again in general
14:44 jeff I like a number of aspects about the proposal, especially those aspects that deal with communication, focused bug efforts, and deprecation / removal of dead things. :-)
14:44 jeff bshum++
14:44 jeff dkyle++
14:44 kmlussier dkyle++
14:45 bshum Yeah, regarding deprecation, I think that'll be one of the things we'll have to make a point to announce broadly as gmcharlt suggested in the email thread.
14:45 dkyle so.. do we mention new features at this point?
14:45 bshum I know one of the other things we talked about removing is all the leftover code from JSPAC.
14:45 jeff I don't have notes from the dev meeting in-person at the conference, but bshum's email states that we intended to vote on RM proposals during this dev meeting. Do we intend to do that here, on the list, or are we holding off for now?
14:46 jeff Looking at the last time we did this, we voted on open-ils-dev.
14:47 dbwells bshum++ # plan looks good
14:47 jeff if there's no objection or further comment, I'll give myself an action item for calling for a RM vote on open-ils-dev within the next few days.
14:48 kmlussier dkyle: We should be getting to that agenda item shortly.
14:49 jeff #action jeff to call for RM 2.7 vote on open-ils-dev within the next few days
14:49 jeff #topic Feedback for New Features Under Development
14:49 dbwells bshum: my only suggestion would be to schedule at least one bug wrangling day in the April/May window.  The bugs pile up fast without somebody banging the drum.
14:49 jeff #info Metabib display fields
14:49 bshum dbwells: That's probably a good idea.  I was thinking about early May myself.
14:49 jeff #link https://launchpad.net/bugs/1251394 Metabib Display Fields
14:49 pinesol_green Launchpad bug 1251394 in Evergreen "Metabib Display Fields" (affected: 3, heat: 14) [Undecided,New] - Assigned to Bill Erickson (erickson-esilibrary)
14:49 dbwells bshum: cool, sounds good
14:50 bshum So I added that as an example of a bug that's been lost in the wilds that probably should see the light of day during 2.next as part of these feature discussion part of the agenda.
14:51 jeff Metabib Display Fields has benefit for the staff client, reporting, and more. I'm very excited to see it get attention. :-)
14:51 bshum What I should have done was to email the list ahead of time to ask folks to weigh in on these kinds of bugs.
14:51 bshum Just a nudge forward kind of thing.
14:51 dbwells I'll take the blame for any delay on the display fields stuff.  I through a big monkey wrench in, then completely turned my attention to 2.6 management and forgot all about it.
14:52 bshum I'll try to do that next time.  And I highly encourage other folks to bring up bugs that are important to them to the attention of the group and me (assuming I win the vote ;))
14:52 hbrennan joined #evergreen
14:52 jeff bshum: going forward, how much time do you envision spending on new feature attention in dev meetings, and what would you like to see happen in this portion of the meeting?
14:53 dbwells I think berick's approaching of simply materializing the display fields during ingest is a tried-and-true path.
14:53 jeff bshum: General "hey! this is coming! feedback welcome!", or something else?
14:54 bshum jeff: That's a good summary for my part of it.  I mainly would like to see more early communication if possible of ideas / plans for development; especially with regards to 2.next.  I'd like to make sure that we're aware of any potential game-changers before we get too far along.
14:54 kmlussier I think a general "feedback is welcome" is useful to make sure big changes receive proper attention before anyone starts coding.
14:54 jeff berick++ eeevil++ dbwells++ work so far on Metabib Display Fields
14:55 bshum The time requested would be for that sort of "this is coming!" but also if we needed to hash out a specific area, there's always room too for that in the regular chat day or post-meeting.
14:56 kbutler joined #evergreen
14:56 jeff #info Smart Float
14:57 jeff #link http://markmail.org/message/736mp25legftvjld [OPEN-ILS-DEV] Smart Float: Self balancing floating collections
14:57 dkyle yeah, Smart Float, was looking for any interest, collaboration, and how to go about maybe getting it rolled into a release
14:58 dkyle should I put something on LP?
14:58 jeff dkyle: do you have a launchpad account, and have you had a chance to open a wishlist bug for Smart Float?
14:58 gmcharlt dkyle: yes
14:58 dkyle jeff: I do. I did create a working branch last week, but no wishlist item yet
14:59 jeff dkyle: if you can create a launchpad bug against Evergreen with a link to the working branch, etc, that's going to enable the feature to be targeted at an upcoming release. give a shout in here if you run into any issues or have questions.
14:59 jeff dkyle: judging from the list conversations, people were interested and i think some had some feedback.
14:59 * bshum will keep an eye out for it too
14:59 dkyle jeff: will do, thanks.
14:59 jeff dkyle++ grpl++
15:00 jeff #link https://launchpad.net/evergreen/+milestone/2.next bugs currently targeting Evergreen 2.next
15:01 jeff I'd encourage everyone to review the bugs currently listed there, and to offer feedback, provide review, or even target new bugs.
15:01 jeff Since we've hit the 3 PM mark, I'm inclined to leave it at that unless anyone else has something they'd like to go over.
15:02 bshum Just a small thing, berick++ for getting good feedback from the community on the path for the web client work.
15:02 jeff Does anyone else have a specific upcoming new feature they'd like to bring attention to, or a non-new-feature topic for the meeting?
15:02 lcathenry joined #evergreen
15:02 jeff berick++
15:02 jeff #link http://wiki.evergreen-ils.org/doku.​php?id=dev:browser_staff:dev_notes Browser Staff Client Development Notes
15:03 jeff I would also encourage everyone to read up on the work being done on the web based staff client, and to offer feedback in the various mailing list threads.
15:03 * berick is always happy to respond to questions, etc.
15:03 jeff pester berick!
15:04 jeff #endmeeting
15:04 pinesol_green Meeting ended Tue Apr  8 15:04:22 2014 US/Eastern.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
15:04 pinesol_green Minutes:        http://evergreen-ils.org/meetings/evergr​een/2014/evergreen.2014-04-08-14.01.html
15:04 pinesol_green Minutes (text): http://evergreen-ils.org/meetings/evergr​een/2014/evergreen.2014-04-08-14.01.txt
15:04 pinesol_green Log:            http://evergreen-ils.org/meetings/evergree​n/2014/evergreen.2014-04-08-14.01.log.html
15:04 jeff Thanks, everyone!
15:04 bshum jeff++
15:04 kmlussier jeff++
15:04 dkyle jeff++
15:04 berick jeff++
15:05 dbwells jeff++
15:06 gmcharlt jeff++
15:07 bshum dbwells: Logistics question, but we haven't branched rel_2_6 yet right?  So whatever we're adding for the moment still just goes to master?
15:08 dbwells bshum: I was thinking of branching at RC, but at this point, we might as well wait for .0, I think.
15:08 dbwells so, yest
15:08 dbwells I mean yes
15:09 bshum Cool deal.  I'll try adding new things later this evening if I can carve out some time to test more and signoff
15:09 dbwells bshum: kmlussier: here's a very quick attempt at ferreting out the Vandelay issue - http://pastebin.com/CtujPy6z
15:09 bshum I can drop that into our test system and see what happens.
15:10 dbwells I know eeevil is cooking up something better, but this should be really easy to test, and might tell us if we're on the right track.
15:10 bshum Will do
15:10 kmlussier dbwells++
15:10 kmlussier I'll leave it in bshum's capable hands while I head home. :)
15:13 eeevil yeah, that will def make things better, but I suspect it'll still be slower than the old way.  One thing that's not covered at all, currently, is composite attrs in vandelay
15:14 eeevil (and uncontrolled attrs)
15:17 dbwells eeevil: I am curious, do you think it would help anything (regarding the speed problems we've found) to define record_attr in terms of the map/vector rather than in terms of record_attr_flat?
15:17 dbwells I think we could limit that extra level of indirection.
15:17 dbwells s/limit/eliminate/
15:18 eeevil dbwells: the speed change comes primarily from the hstore() call, so IMO, probably not. and we'd have to do what record_attr_flat does, but in-line in the query
15:18 eeevil that said, it's worth a try
15:19 eeevil dbwells: objections to me trying to address the lock overflow issue caused by the temp table usage?
15:19 dbwells It seems like we're hitting planning problems, since we know the underlying structures are plenty fast.
15:19 eeevil basic idea would be to use unlogged tables and delete from them instead of dropping them
15:20 eeevil dbwells: well, I'm going to try to get it to use the index over vlist
15:22 dbwells eeevil: sorry, not catching your context re: lock overflow issue.  What are you referring to?
15:23 * dbwells is working on too many things at once
15:23 jeff And if I didn't mention it enough earlier, if you're running pretty much anything other than Debian Squeeze, you need to upgrade openssl, restart apache, and consider taking additional steps to deal with CVE-2014-0160 http://cve.mitre.org/cgi-bin/c​vename.cgi?name=CVE-2014-0160
15:23 pinesol_green The (1) TLS and (2) DTLS implementations in OpenSSL 1.0.1 before 1.0.1g do not properly handle Heartbeat Extension packets, which allows remote attackers to obtain sensitive information from process memory via crafted packets that trigger a buffer over-read, as demonstrated by reading private keys, related to d1_both.c and t1_lib.c, aka the Heartbleed bug. (http://cve.mitre.org/cgi-bin/c​vename.cgi?name=CVE-2014-0160)
15:23 eeevil large vandelay queues can fail outright because we create and destroy 2 temp tables per record we try to match
15:23 eeevil hrm.. might be stack space, not lock space. sec
15:24 eeevil https://bugs.launchpad.net/evergreen/+bug/1271661
15:24 pinesol_green Launchpad bug 1271661 in Evergreen "record import matching can fail with "shared memory" PostgreSQL errors" (affected: 2, heat: 12) [Undecided,Triaged]
15:24 Dyrcona jeff: Or just leave the Internet, 'cause its never going to be secure enough for you. :)
15:24 Dyrcona Well, until the power goes out for everyone, for good.
15:25 dbwells eeevil: If we can keep that fix separate from the 2.6.0 window I would be happier despite the churn.  Unless, of course, it happens to be pretty simple, somehow.
15:26 eeevil dbwells: looks simple. I'll keep it in a separate commit
15:26 Sato`kun joined #evergreen
15:26 dbwells eeevil: cool, thank you
15:38 Melanion joined #evergreen
15:39 Melanion Howdy folks.
15:40 Melanion I'm having a bit of an issue and I wondered if anyone had encountered it before. I've got several items which item status show checked out to a patron with a fines stop reason of CLAIMSRETURNED, but they don't show up when viewing that patron.
15:41 eeevil Melanion: if the fine/fee balance of the circ transaction went to 0 then (IIRC) the circs disappear from the items-out display in the patron
15:42 mmorgan lp 793550
15:42 pinesol_green Launchpad bug 793550 in Evergreen 2.3 "xact_finish (prematurely?) set on claimed returned item if transaction balance reaches zero" (affected: 7, heat: 38) [Medium,Fix released] https://launchpad.net/bugs/793550
15:42 eeevil dbwells: http://git.evergreen-ils.org/?p=working/Ev​ergreen.git;a=shortlog;h=refs/heads/collab​/miker/1304559_and_1271661_vandelay_fixes 1) untested and 2) ignore the top commit if you'd rather
15:42 mmorgan Melanion: What release are you on?
15:43 Melanion Ah. So if desk staff applied a nonspecific credit to the account and it wiped any charges the CR had on it out, the CR would disappear from the patron's account?
15:43 Melanion Windows 2.4.3
15:44 Dyrcona Melanion: I don't think the Windows will matter in this case. :)
15:44 mmorgan This bug should have been fixed with 2.4. We saw it in earlier versions ... of Evergreen:)
15:44 Melanion I like to be specific. :P Also, derp on me for not reading the bug descrip before asking.
15:45 Melanion The CRs in question were added in 8/13, at which time our system was running..2.3? Maybe 2.2. So it could have happened before the fix.
15:47 dbwells bshum: you can ignore my earlier function paste, I accidentally threw an extra '=' in there anyway.
15:48 mmorgan Someone correct me if I'm wrong, but I believe nullifying action.circulation.xact_finish for those transactions would make them reappear on the patron records.
15:48 dbwells bshum: We're better off testing this, since it's ready now: http://git.evergreen-ils.org/?p=working/Ev​ergreen.git;a=shortlog;h=refs/heads/collab​/miker/1304559_and_1271661_vandelay_fixes
15:49 Dyrcona mmorgan: I believe it would.
15:52 bshum dbwells: That I can do.  We didn't get to work on the first one, mary ended up heading out early for something else
15:53 CleverNameHere joined #evergreen
15:54 Dyrcona Melanion: You say the copies say "checked out" and not "lost" for the status?
15:54 Melanion Dyrcona: Correct.
15:54 Dyrcona 'Cause I think there might be another, related issue with lost copies.
15:55 Sato`kun joined #evergreen
16:10 Melanion Blah, I'm just an underpaid undergrad who barely has the permissions to scratch my chin. I'm just going to tell the desk staff reading the reports to check the items' statuses by the barcode rather than looking at patron info. Still, thanks for the info.
16:15 jboyer-isl I need to make time to push a branch addressing lp 1241644, it sounds like that's what Melanion is running into. :(
16:15 pinesol_green Launchpad bug 1241644 in Evergreen "claims_returned and longoverdue counts differ between open-ils.actor.user.checked_out(.count) and open-ils.storage.actor.user.checked_out(.count)" (affected: 2, heat: 12) [Medium,Triaged] https://launchpad.net/bugs/1241644
16:16 jboyer-isl one method looks at checkin_time and xact_finished, the other only cares about checkin_time. (I like the latter. It's "claims returned" until it's "really returned")
16:20 jboyer-isl Uh, I guess I should have refreshed my memory a little harder on that bug, because there's a branch right there.
16:24 jeff heh
16:24 mrpeters joined #evergreen
16:28 eeevil dbwells / bshum: I'll make 2 upgrade scripts for that branch, one for each commit, if you want
16:29 jeff oh wacky. dokuwiki sets the following header on password reset emails: List-Id: Evergreen DokuWiki <wiki.evergreen-ils.org>
16:31 bshum eeevil: I would appreciate it.  I tried digging it out and I'm getting some syntax error trying to run the update
16:31 eeevil bshum: ah, yep. I'll fix those too
16:32 eeevil bshum: looks like just one, actually. the line looks like this: jrow := jrow || ' mra.vlist @> intset(ccvm.id)' ||
16:32 eeevil bshum: should end in ; instead of ||, obv
16:33 bshum Whoops, almost ran the query in production's DB.... (triple checking ftw)
16:33 eeevil heh!
16:34 dbwells bshum: at least there are worse queries to accidently run in production ;)
16:45 eeevil bshum: to simplify things, I'm going to push a separate branch that is syntax-fixed from the first commit on, and includes upgrade scripts. sec
16:46 eeevil bshum: working/collab/miker/1304559_and_12​71661_vandelay_fixes_with_upgrades   http://git.evergreen-ils.org/?p=working/Evergre​en.git;a=shortlog;h=refs/heads/collab/miker/130​4559_and_1271661_vandelay_fixes_with_upgrades
16:47 eeevil DANG IT
16:47 eeevil ok, the YYYY upgrade needs fixing, but you mostly care about the XXXX script
16:47 bshum Heh
16:48 dbwells ah, nothing like the pressure of last second bug discoveries
16:48 eeevil I totally force-updated it ;)
16:48 eeevil dbwells: :)
16:49 eeevil ok ... I'm out for now. let me know if it works out
16:53 CleverNameHere joined #evergreen
16:53 kmlussier joined #evergreen
16:54 CleverNameHere So when running a report through evergreen it sends me a link to https://localhost/blah/blahblah/blahblahblah. Anyone know how
16:54 CleverNameHere iI can configure that to our evergreen servers name
16:57 pinesol_green Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html>
16:58 jeff CleverNameHere: in your opensrf.xml configuration file, look at the value under reporter/setup/base_uri
16:58 kmlussier I don't know the answer, but I wish I had come up with a screen name that's as clever as CleverNameHere's. :)
17:03 Wyuli joined #evergreen
17:04 bshum dbs: For later, could you add kmlussier to the Evergreen Drivers group so that she can help target bugs to specific series.
17:05 bshum Related, this is my +1 to giving kmlussier more powers with LP to help organize things.
17:05 hbrennan +1 kmlussier is a super organizer
17:07 kmlussier I'm suddenly afraid of what I've gotten myself into. ;)
17:08 mmorgan left #evergreen
17:18 * gmcharlt grabs 0854
17:19 gmcharlt bah
17:19 gmcharlt correction, 0878
17:33 pinesol_green [evergreen|Jason Stephenson] LP 1303940: pg_tap regression test. - <http://git.evergreen-ils.org/?p=​Evergreen.git;a=commit;h=16eec85>
17:33 pinesol_green [evergreen|Galen Charlton] LP#1303940: improve readability of test case - <http://git.evergreen-ils.org/?p=​Evergreen.git;a=commit;h=1764ceb>
17:33 pinesol_green [evergreen|Mike Rylander] LP#1303940: Protect against bogus data that can breaking indexing - <http://git.evergreen-ils.org/?p=​Evergreen.git;a=commit;h=c964cd4>
17:33 pinesol_green [evergreen|Galen Charlton] LP#1303940: don't attempt to store NULL values in keyword, browse, or facet indexes - <http://git.evergreen-ils.org/?p=​Evergreen.git;a=commit;h=9984b11>
17:33 pinesol_green [evergreen|Galen Charlton] LP#1303940: pin schema upgrade to 0878 - <http://git.evergreen-ils.org/?p=​Evergreen.git;a=commit;h=149ffb3>
17:33 jeff @who can breaking indexing?
17:33 pinesol_green pmurray_away can breaking indexing.
17:34 CleverNameHere Thanks Jeff. I found it.
17:48 atlas__ joined #evergreen
18:07 mrpeters this ring any bells for anyone?  http://pastie.org/9004788
18:08 mrpeters really concerns me that this "oils_xpath" is missing....customized sql to build the database and i think that may have munged something up
18:13 gmcharlt mrpeters: check search_path
18:13 dbwells I second that
18:13 mrpeters where is that defined?
18:14 dbwells One way would be:  SET search_path = evergreen, public, pg_catalog;
18:15 mrpeters how can i see what search_path is now?
18:15 gmcharlt and as a Pg GUC variable, it can be set at the database level using
18:15 gmcharlt ALTER DATABASE evergreen SET search_path TO evergreen, public, pg_catalog;
18:15 mrpeters just out of curiosity
18:15 bshum SHOW search_path;
18:15 bshum From psql
18:15 gmcharlt this is one of the things that pg_dumpall will emit, but /not/ pg_dump
18:15 mrpeters tcmc_evergreen=# SHOW search_path;
18:15 mrpeters search_path
18:15 mrpeters ----------------
18:15 mrpeters "$user",public
18:15 mrpeters (1 row)
18:15 mrpeters wtfffffff
18:16 mrpeters that woudl explain why it worked fine when i did the dump, but not otherwise...they must have used dumpall
18:17 mrpeters so, i assume s/evergreen/mydbname/ there?
18:17 gmcharlt ayup
18:18 mrpeters excellent.  thanks guys
18:18 mrpeters gmcharlt++ dbwells++ bshum++
18:18 dbwells huh, I though 'evergreen' was a hardcoded schema for our functions
18:18 bshum dbwells: It is
18:19 bshum I assume mrpeters meant for the database portion where you set it with ALTER DATABASE
18:19 bshum The path definitely needs to be evergreen, etc.
18:19 mrpeters actually i meant in the list of paths
18:19 dbwells ah, ok, makes sense now
18:19 gmcharlt but not every reference to such functions are qualified with "evergreen.", hence the dependence on search_path
18:19 mrpeters i knew to alter my db name :)
18:19 mrpeters right on
18:20 gmcharlt alter database unpredicable_haxxors_go_away set search_path = 'evergreen, public, pg_catalog;
18:20 gmcharlt ;)
18:20 dbwells gmcharlt: right, just a little miscommunication there on what mrpeters was s//'ing
18:20 gmcharlt dbwells: right; mostly for the benefit of the log
18:20 bshum logs++
18:21 mrpeters haha
18:21 mrpeters thanks guys, im beat...night!
18:24 dbwells We should probably create one of those one word response things so we can say @search_path or something and have it spit out the essence of this conversation.  Seems to come up a lot.
18:27 bshum Hmm
18:28 bshum ~search_path is When 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;
18:28 pinesol_green I'll remember that, bshum
18:29 dbwells bshum++ # yeah, like that :)
18:29 bshum ~search_path is When 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';
18:29 pinesol_green But search_path already means something else!
18:29 bshum Hmm
18:29 bshum ~search_path is When 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';
18:29 bshum It doesn't like me
18:30 bshum ~no search_path is When 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';
18:30 pinesol_green I'll remember that bshum
18:30 bshum Missing trailing '
18:30 bshum ~search_path
18:30 pinesol_green search_path is When 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';
18:30 bshum That makes me feel better now.
18:33 jeff evergreen 2.next will eliminate search path issues. it will also bake you a cake.
18:34 dbwells But shouldn't there be an option for cookies instead?
18:35 hbrennan I'll vote for either as long as it's chocolate
18:35 jeff if I want cookies, I'll get them from DTLS heartbeat overflows.
18:36 jeff (too soon?)
18:36 bshum jeff: Do we need a factoid for that so that you don't have to type your PSA all over again? :D
18:37 * bshum jests
18:37 bshum jeff++
18:37 dbwells mmmmm, heartbeat overflows...
19:03 shadowspar joined #evergreen
20:30 gsams joined #evergreen
21:08 Guest82076 @quote add < jeff> evergreen 2.next will eliminate search path issues. it will also bake you a cake.
21:08 pinesol_green Guest82076: Error: You must be registered to use this command. If you are already registered, you must either identify (using the identify command) or add a hostmask matching your current hostmask (using the "hostmask add" command).
21:08 hbrennan Sneaky guests.
21:08 csharp @quote add < jeff> evergreen 2.next will eliminate search path issues. it will also bake you a cake.
21:08 pinesol_green csharp: The operation succeeded.  Quote #82 added.
21:11 csharp joined #evergreen
21:11 csharp ~search_path
21:11 pinesol_green search_path is When 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';
21:12 csharp ~no search_path is <reply> When 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';
21:12 pinesol_green In #evergreen, csharp said: ~no search_path is <reply> When 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';
21:12 csharp ~no search_path is <reply> When 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';
21:12 pinesol_green I'll remember that csharp
21:13 csharp ~search_path
21:13 pinesol_green When 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';
21:16 bshum csharp++
21:16 robbat2 csharp, so the next ver will have all plsql stored procedures using fully qualified names?
21:20 dbs @later tell kmlussier you are now a member of the Release Drivers
21:20 pinesol_green dbs: The operation succeeded.

| Channels | #evergreen index | Today | | Search | Google Search | Plain-Text | summary | Join Webchat