2011-03-15T08:18:07 *** Dyrcona has joined #evergreen 2011-03-15T08:24:19 *** dbs has quit IRC 2011-03-15T09:17:10 *** kmlussier has joined #evergreen 2011-03-15T09:23:31 *** gdunbar has joined #evergreen 2011-03-15T09:31:21 *** StephenGWills has joined #evergreen 2011-03-15T09:33:01 *** jenny has joined #evergreen 2011-03-15T09:39:42 *** bshum has joined #evergreen 2011-03-15T09:45:52 eeevil: I believe this is a masslnc enhancements issue. When loading the db (fresh) we got errors unless we changed the def in 200.schema.acq.sql for public.extract_acq_marc_field to use extract_marc_field instead of public.extract_marc_field. Seems that the public variant is commented out in 002.functions.config.sql. 2011-03-15T09:56:02 *** dbs has joined #evergreen 2011-03-15T10:12:31 anyone else having trouble with marceditor authority-popups not rendering in 2.0? 2011-03-15T10:12:43 *** mrpeters-isl has joined #evergreen 2011-03-15T10:15:06 from what I can tell, xulrunner is losing track of the code running in the pop-up event handler. This seems very similar to the problem with dojo-onload/xhr problem 2011-03-15T10:18:22 phasefx: if that's the problem that parsr is running into, I haven't been able to reproduce it 2011-03-15T10:18:59 it's encouraging-ish if it can be reproduced. I loaded 50,000 records onto the 2.0.3 virtual image and it all worked fine. 2011-03-15T10:21:05 dbs: I can reproduce it at a library production site, and on an in-house server, but not so far on a public server like acq.open-ils.org :-/ of course, that server has no records to speak of so, so my next goal is to load it up with authority records 2011-03-15T10:21:50 parsr is getting that too? 2011-03-15T10:21:53 Fortunately parsr provided 500,000 records in his bug report 2011-03-15T10:22:05 phasefx: yeah, don't you read bug reports? For shame! :) 2011-03-15T10:22:05 * phasefx looks at launchpad 2011-03-15T10:22:23 if they involve the staff client, I usually do :D just don't remember this one 2011-03-15T10:23:11 https://bugs.launchpad.net/evergreen/+bug/732681 2011-03-15T10:23:15 gracias 2011-03-15T10:24:13 yeah, that's what happens.. the event handler that is supposed to handle the popup starts to run, and then falls off the face of the earth, and the normal context menu shows up 2011-03-15T10:25:32 my suspicion is that it's a race condition in Mozilla, so who knows what sort of variables come into play 2011-03-15T10:25:43 * dbs wonders if cache settings are different on the Web servers where the problem occurs 2011-03-15T10:26:00 * phasefx can check 2011-03-15T10:26:54 It's a stab in the dark, but not being able to reproduce the problem, and thinking it's another race condition, I don't have many other places to look 2011-03-15T10:27:37 well, I can tell you the callback for the xhr happens, and the code starts looping through the returned records 2011-03-15T10:27:47 but it never gets past that dojo.forEach on the records 2011-03-15T10:28:21 something specific about those particular records then? 2011-03-15T10:28:51 that's an idea too.. I was thinking either quanity or quality of the records 2011-03-15T10:28:56 quantity even 2011-03-15T10:29:31 quantity-wise, it's always a set number of records, albeit with a varying number of DOM elements being generated (based on 1xx/4xx/5xx entries per record) 2011-03-15T10:30:57 If there's a weird XML encoding issue with a particular record that causes JS to barf an exception, I suppose that could be an issue. Wrap the forEach in a try/catch perhaps? 2011-03-15T10:32:11 * phasefx was stepping through it with venkman, but can do that too 2011-03-15T10:36:22 tsbere: whoa, that's very strange (re public schema) that's the default schema for unqualified relations, by (um) default ... in what schema do you actually see the extract_acq_marc_field function in your db? 2011-03-15T10:37:18 eeevil: Oh, extract_*acq*_marc_field is likely in public. The extract_marc_field function it *calls* was the problem. 2011-03-15T10:37:39 phasefx: Just checking, but I guessing acq.open-ils.org is using Squeeze? 2011-03-15T10:37:48 tsbere: k, looking 2011-03-15T10:37:50 bshum: lenny 2011-03-15T10:38:17 phasefx: Ah okay. I'm going to continue my test with Lucid then, for OpenSRF 2.0 rc2 2011-03-15T10:38:32 har, not enough space on acq to load nrcan's authority records 2011-03-15T10:38:41 *** natschil has joined #evergreen 2011-03-15T10:38:41 phasefx: Didn't want to cover a second Debian test if we already had one. 2011-03-15T10:38:44 Thanks. 2011-03-15T10:38:54 phasefx: I can send you a 50K chunk of nrcan's records 2011-03-15T10:38:55 tsbere: that's still created in the public schema, AFAICT (also, that code in particular hasn't changed in the masslnc-cataloging-enhancements branch, AFAIK) 2011-03-15T10:39:18 eeevil: We are running into a whole slew of problems. No longer sure where any of it is coming from. 2011-03-15T10:39:41 dbs: I'll take em, thanks 2011-03-15T10:39:43 eeevil / tsbere: I was seeing some public schema weirdness on 9.0 over the weekend in trunk, fwiw 2011-03-15T10:40:10 dbs: did that precipitate the evergreen schema? 2011-03-15T10:40:29 recreating the database schema was complaining about public.english_nostop, which was only qualified in one place; when I removed that qualification, it got through the recreate cleanly 2011-03-15T10:40:31 Other issues include the 000.blah fts stuff apparently not showing up *anywhere* we can see with pgadmin. And our bibs won't load due to FTS configs not existing. 2011-03-15T10:40:37 eeevil: part of the rationale, yeah 2011-03-15T10:41:23 tsbere: did you get any warnings during buid_db.sh? 2011-03-15T10:41:54 no errors or warnings in the latest run. 2011-03-15T10:42:23 dbs: I should have enough space now for the file from the ticket, so no need to go out of your way 2011-03-15T10:42:24 * tsbere has the db reload set to tee to a file for easy reviewing 2011-03-15T10:42:43 phasefx: http://evergreen-ils.org/~denials/nrcan_small.sql 2011-03-15T10:42:49 tsbere: are you creating the db from scratch (as in, createdb)? 2011-03-15T10:42:50 dbs: gracias 2011-03-15T10:42:56 (give it 1 minute to finish uploading) 2011-03-15T10:43:13 eeevil: Our first attempt was. Can drop/recreate the db to try that again. 2011-03-15T10:43:21 phasefx: okay, it's done 2011-03-15T10:43:54 * dbs was running through both clean db schema creates and recreates over the weekend 2011-03-15T10:45:24 http://svn.open-ils.org/trac/ILS/changeset/19723 is where I unqualified public.english_nostop to make it match the rest of the references to english_nostop 2011-03-15T10:46:01 ok ... looks like time for a schema-qual-funcs branch :( 2011-03-15T10:46:23 (should remove some of the agg functions anyway, since PG has them now) 2011-03-15T10:48:13 So, main difference between previous run from a clean db and this one is the first run with a clean db had the extract_marc_field problem. 2011-03-15T10:48:30 And this one apepars to be working. Can't forget that. 2011-03-15T10:48:39 s/apepars/appears/ 2011-03-15T10:48:46 *** natschil has quit IRC 2011-03-15T10:49:55 one thing I've seen, which confuses me greatly, but is probably related to syscache invalidation or something, is after a fresh schema load I have to disconnect everything using the newly set up db and reconnect 2011-03-15T10:50:17 like, \d won't find stuff until I reconnect 2011-03-15T10:50:54 So, if I load *fresh* it looks like it works. If I had any error and *reload* all the FTS vanish. 2011-03-15T10:51:21 tsbere: that sounds very strange 2011-03-15T10:52:01 *** mtate has quit IRC 2011-03-15T10:52:59 *** mtate has joined #evergreen 2011-03-15T10:57:58 is git revert the correct way to flush uncommitted changes? 2011-03-15T10:58:03 Testing shows that dropdb/createdb cycle (with all other needed pieces) followed by eg_db_config.pl = functional. Run eg_db_config.pl *again*? Non-functional. 2011-03-15T10:58:04 I want my files back! :) 2011-03-15T10:58:06 eeevil: no 2011-03-15T10:58:10 eeevil: Git checkout 2011-03-15T10:58:14 or git checkout --force to do it all 2011-03-15T10:58:16 k, thanks 2011-03-15T11:11:07 * tsbere may be onto something on this, but has to do some fresh loads/exports for comparison 2011-03-15T11:17:34 I'll post a reminder to the mailing lists, but there's a dev meeting scheduled at 12:00 EST today right? 2011-03-15T11:18:48 dbs: Sounds right. 2011-03-15T11:18:59 or EDT, or whatever. Stupid time. 2011-03-15T11:28:35 *** djfiander has joined #evergreen 2011-03-15T11:36:09 Looks like 1 line added to 000.english.pg90.fts-config.sql may fix the "second+ load fails" problem :D 2011-03-15T11:36:27 * tsbere will run 3-5 more load tests to be sure 2011-03-15T11:36:45 fwiw, I'm not seeing second+ load problems in trunk 2011-03-15T11:37:55 dbs: In 9.0.3 I am not seeing FTS Dictionary or Configurations on a second load, but I am doing so with the masslnc catalog enhancements branch merged in. 2011-03-15T11:38:33 tsbere: ah, so a problem specific to your branch? 2011-03-15T11:38:56 I can on the next load test (and was going to anyway) swap to clean trunk. 2011-03-15T11:40:35 dbs: *Clean* trunk is doing the same thing for me, it seems. 2011-03-15T11:40:47 Will try my one line fix in a minute 2011-03-15T11:41:18 tsbere: how are you checking for FTS dictionary / configs? I'd like to be able to reproduce this problem 2011-03-15T11:41:31 dbs: I am using pgadmin to show me them at the moment. 2011-03-15T11:41:42 let me dig up the psql command variants 2011-03-15T11:42:46 tsbere: a 9.0-aware pgadmin? 2011-03-15T11:43:20 just wondering if pgadmin has the same issues as psql in not being reliable going from 8.4 version of psql -> 9.0 database 2011-03-15T11:43:22 dbs: Yes, 9.0-aware. Looks like \dF and \dFd are the psql variants. 2011-03-15T11:44:06 The \dFd is dictionaries, there should be a public english_nostop, and \dF is the configurations, should have a small pile of public ones 2011-03-15T11:44:22 Should also have a static list of pg_catalog based in both lists 2011-03-15T11:44:27 okay. that I can reproduce 2011-03-15T11:44:42 Question about action_trigger.event we have not been using triggers but that table has been getting filled for quite some time, how/why? 2011-03-15T11:45:07 dbs: For me a clean db load is showing the public ones. Running a load onto that db a second time isn't. 2011-03-15T11:45:28 tsbere: yeah. I can reproduce that. 2011-03-15T11:45:30 moodaepo: any active definitions on non-passive hooks will cause that ... checkins, checkouts, hold capture, etc 2011-03-15T11:45:48 moodaepo: just deactivate all active defs 2011-03-15T11:46:03 dbs/eeevil: Adding "SET search_path = public, pg_catalog;" just after "BEGIN" in the fts-config sql file makes it work again for me on first or second load after clean db create. 2011-03-15T11:46:08 and if you aren't going to process the events, you can delete them 2011-03-15T11:46:51 tsbere: that sounds entirely safe ... I'll do that now 2011-03-15T11:47:08 eeevil: Will do. I hadn't looked there since we thought the cron job needed to be running. 2011-03-15T11:47:40 Hmm, based on the last email to the list, maybe we should add a "slightly older versions" link for older 2.0 staff clients to the downloads page. Kind of like what we had done for the 1.6.1's 2011-03-15T11:47:47 moodaepo: it does to process events, but creation of events on non-passive hooks is done in-line during the event itself 2011-03-15T11:48:01 or we could qualify the schemas explicitly? 2011-03-15T11:48:33 The stock 90 day mark overdue lost, does that look for just the overdues the 90th day from today and mark them lost or all overdues older than 90 days. 2011-03-15T11:49:27 dbs: I tried something like that. It wasn't happy. Not sure why. Maybe I did it wrong. 2011-03-15T11:49:31 moodaepo: I would have thought 90 days from the event specified in the definition. Which I think is overdue date 2011-03-15T11:49:33 dbs: I think we should, but we should do it consistently for functions, aggs, types, etc across the board, and that's going to be a BIG job. perhaps that's a good GSoC project? 2011-03-15T11:50:30 eeevil: 12 weeks of work? Maybe, if the student is also required to create tests to ensure before/after works 2011-03-15T11:52:06 eeevil: for now, we could specify pg_catalog / public explicitly - I've got that working - and that might make it easier to cut over to something non-public later 2011-03-15T11:52:09 dbs: It may be weeks just figuring out where everything should go ;) 2011-03-15T11:53:07 dbs: another consideration is that as all of that changes, other dev will have much pain. perhaps timing on this is important,and we should focus on, say, immediately after a release before big new features are in heavy dev? 2011-03-15T11:53:10 bshum: Ok. By the way I setup the trigger and the cron for process-hooks pending and started running out of processes, I now think it's because of the thousands of entries in action_trigger.event 2011-03-15T11:53:11 Not to mention the resulting upgrade script... 2011-03-15T11:53:41 moodaepo: That certainly wouldn't be fun :) 2011-03-15T11:53:53 anyway ... I'm fine with either SEARCH_PATH or explicit qualification 2011-03-15T11:54:21 dbs: if you already have the explicit qual done and tested, please commit! :) 2011-03-15T11:54:28 will do 2011-03-15T11:54:32 dbs++ 2011-03-15T11:54:52 tsbere++ # for finding the problem in the first place 2011-03-15T11:55:07 indeed 2011-03-15T11:55:59 arg ... fetching food for the meeting 2011-03-15T11:56:05 tsbere: have defaultws and installer committed. poking at stubs now (that can be tested independent of installer?) 2011-03-15T11:56:23 moodaepo: "running out of processes" meaning opensrf errors? Or just taking an inordinately long time processing the backlog of thousands of old entries? 2011-03-15T11:56:34 phasefx: stubs is literally 4 files. No code changes. Two pre-rigged xulrunner-stub.exe files and the icons that were used to rig them. 2011-03-15T11:57:26 I think the icons came from mrpeters-isl, I just added them to the xulrunner-stub.exe file because I can't find a way to do that outside of wine on linux. 2011-03-15T11:57:50 so, I just build a client installation exe, install, and see if I get new icons for a running client? 2011-03-15T11:58:39 moodaepo: Or a little of both I guess, taking forever + running out of processes 2011-03-15T11:59:02 Well, you would need to copy xulrunner-stub.?.exe to xulrunner-stub.exe, and evergreen?.ico should be copied to the build folder I think it was.... 2011-03-15T11:59:10 let me check on the icon 2011-03-15T11:59:35 bshum: Yea I think both, it might have been for the holds. I'm going to try deleting the events and try again as eeevil suggested. 2011-03-15T11:59:47 *** djfiander has quit IRC 2011-03-15T11:59:48 Meeting time in 10 seconds? 2011-03-15T12:00:13 phasefx: If there is a branding folder with evergreen.ico it copies at build time. So copy the icon you want to the build folder as evergreen.ico to test that part. 2011-03-15T12:00:17 *** djfiander has joined #evergreen 2011-03-15T12:00:29 *** KingNightWolf has joined #evergreen 2011-03-15T12:00:31 tsbere: so, I'm not seeing anything different. I have to do some intervening step before make winclient, you're saying? ah, k 2011-03-15T12:01:20 *** jasonb has joined #evergreen 2011-03-15T12:02:13 * bshum nominates moodaepo to lead since he talked about the meeting last before 12 2011-03-15T12:02:14 phasefx: Basically, things only look for xulrunner-stub.exe and evergreen.ico, in the staff_client and build folder respectively. 2011-03-15T12:02:14 :) 2011-03-15T12:02:21 *** slipscomb has joined #evergreen 2011-03-15T12:02:28 But now is meeting time. More discussion later ;) 2011-03-15T12:02:37 Meeting called to order 2011-03-15T12:03:50 bshum berick phasefx How has the OpenSRf 2.0.0 testing going? 2011-03-15T12:04:05 ^^ 3.1 on the agenda 2011-03-15T12:04:46 Just installed OpenSRF 2.0 rc2 on Lucid (64-bit) and it seems happy so far. I have to get Evergreen over it and see how it reacts next. 2011-03-15T12:04:49 I haven't seen any show stoppers on acq.open-ils.org, but haven't done rigorous testing. Using acq for other things, so incidental testing 2011-03-15T12:05:29 *** ChanServ changes topic to "Dev meeting agenda: http://ur1.ca/3ixot | Welcome to the #Evergreen library system channel! | We are publicly logged. | Large pastes at http://paste.lisp.org/new/evergreen" 2011-03-15T12:06:11 Can we saw needs more testing but no show stoppers as far as getting it to work with 2.0.3 since phasefx did install it with that version of Evergreen? 2011-03-15T12:06:17 s/saw/say/ 2011-03-15T12:06:58 another variable here, this wasn't a pristine install 2011-03-15T12:07:07 We always need more testing. The 2.0.3 VM also has OpenSRF 2.0.0RC2 + EG 2.0.3 (on Squeeze) 2011-03-15T12:07:13 Skipping a bit, but when we're eventually testing 2.1 pre-alpha1, should we use the 2.0 rc for opensrf? 2011-03-15T12:07:16 so anybody using that is testing it too 2011-03-15T12:07:24 dbs++ 2011-03-15T12:09:34 bshum: Or 2.0.0 if it is officially out by then 2011-03-15T12:09:52 dbs: Cool deal 2011-03-15T12:09:53 imo, the only opensrf 2.0 testing left to do is on a busy system. on test systems, everything seems fine 2011-03-15T12:10:07 berick++ 2011-03-15T12:10:24 sounds like a job for ... CONSTRICTOR(tm)! ;) 2011-03-15T12:10:32 Ok moving on to 3.2 on the agenda PostgreSQL 9.0 support 2011-03-15T12:11:02 See backscroll for latest on that :) 2011-03-15T12:11:05 with the FTS thing from just before, we should not have any outstanding 9.0 issues 2011-03-15T12:11:23 dbs++ : ) 2011-03-15T12:11:23 eeevil: s/busy/busy with real and variable traffic, not the grid of requests constrictor produces/ -- it's seen plenty of constrictor testing 2011-03-15T12:11:31 IOW, live testing is all that's left 2011-03-15T12:11:33 though there are surely optimizations we could take advantage of 2011-03-15T12:11:55 berick: perfect 2011-03-15T12:11:57 Wait I forgot to ask for someone to do the minutes...anyone? 2011-03-15T12:12:12 * moodaepo << bad meeting leader 2011-03-15T12:12:24 is hold_targeter.pl the process that insures that when a patron attempts to renew an item, staff is notified that a hold exists on that item? 2011-03-15T12:12:35 oh sorry 2011-03-15T12:13:05 * StephenGWills zips it during the mtg. 2011-03-15T12:13:22 I nominate bshum for minutes since he spoke first at the meeting. 2011-03-15T12:13:35 Heh, sure 2011-03-15T12:13:54 Ok moving on to "Patch reviews" 3.3 dbs? 2011-03-15T12:14:23 I applied both of those patches; made some further adjustments to the patron profile search 2011-03-15T12:14:41 Thanks to mrpeters-isl and tsbere for their contributions 2011-03-15T12:14:56 mrpeters-isl++ tsbere++ 2011-03-15T12:15:30 berick: Anything thoughts on 'Patron Registration Customization Overhaul' 2011-03-15T12:15:53 *** kmlussier has quit IRC 2011-03-15T12:16:47 Ok I'm guessing nothing more the add since berick did respond on the mailing list. 2011-03-15T12:17:14 moodaepo: That has been checked into trunk at this point as well. 2011-03-15T12:17:20 tsbere: Thanks 2011-03-15T12:18:11 Moving on to 3.4 - dbs and gmcharlt did a great job putting together the Google Summer of Code application, any updates/thoughts? 2011-03-15T12:18:31 dbs++ gmcharlt++ phasefx++ for being the mentors 2011-03-15T12:18:34 just a thanks to them 2011-03-15T12:18:40 them's my thoughts 2011-03-15T12:19:03 We'll hear back on the 18th whether we've been accepted 2011-03-15T12:19:09 dbs++ gmcharlt++ phasefx++ 2011-03-15T12:19:33 Excellent! 2011-03-15T12:19:55 Worst comes to worst, we've got a list of projects for any prospective dev to jump on :) 2011-03-15T12:21:12 better than the old bounty page 2011-03-15T12:21:32 Ok moving to 4. PostgreSQL local recommendations, dbs I think you might have some thoughts. 2011-03-15T12:22:16 I didn't add that agenda item, did I? 2011-03-15T12:22:17 eeevil: You might have something on this also (?) 2011-03-15T12:22:37 I put that on the agenda. More-or-less, I am wondering if sticking to locale C might be fighting a losing battle at some point. 2011-03-15T12:22:41 I think lc-ctype=C / lc-collate=C is essentially required for libraries of any size 2011-03-15T12:22:44 9.1 gets proper COLLATE support, so I think we plan on pointing that at a C/UTF-8 db when it's available 2011-03-15T12:22:47 dbs: I'm not sure but just recall you'd talked about that in the channel that's all 2011-03-15T12:22:50 *** kmlussier has joined #evergreen 2011-03-15T12:23:30 Yeah. It's more a question about whether PostgreSQL full-text search is the right long-term solution overall, which is a much bigger discussion 2011-03-15T12:23:51 essentially, use C locale for speed (and a neutral default) and apply the collation you want to queries 2011-03-15T12:24:00 The particular problem which surfaced was the 'lower()' function, but I think there may be some confusion on my test results (admitted reported in probably a confusing fashion). 2011-03-15T12:24:15 dbs: doesn't have much to do with FTS, more to do with specific strings (IMO) 2011-03-15T12:24:58 dbs: we still have to be able to say "sort these 10 records by title", regarless of the source of the list of 10 records (search, bucket, other) 2011-03-15T12:24:59 eeevil: well, the reason we use C is for performance, right? But we're struggling with performance for just metadata, and increasingly there's interest in real full-text search 2011-03-15T12:25:54 performance of what? 2011-03-15T12:25:56 dbs: we don't use C only for performance, no. or, /I/ don't 2011-03-15T12:26:08 I mean, you want to get the wrong answer really fast? 2011-03-15T12:26:34 Basically, lower() works properly when the locale is non-C, and it doesn't when it is set to C. We found a workaround, but I would think any query which relies on DB sorting is going to do strange things with locale C and primarily non-western characters, isn't it? 2011-03-15T12:27:39 dbwells: sort relies on collate, so there's hope for that getting "sorted" out :) 2011-03-15T12:28:12 would picking any given locale cause a problem with records from locales that weren't picked? 2011-03-15T12:28:19 Ok I'm reeling this back to the agenda question "are current recommendations of 'C' as locale inviting problems for libraries using primarily non-Latin character sets?" 2011-03-15T12:28:24 phasefx++ 2011-03-15T12:28:25 dbwells: it's defined, and therefore not "strange", but also not addressable without 1) using the locale (non-contrib) addon or 2) waiting for 9.1 (COLLATE) 2011-03-15T12:29:24 phasefx++ 2011-03-15T12:30:02 phasefx: yes, which is why I'm happy about evergreen.lowercase() (and don't consider it a hack) ... perl handles it correctly, period 2011-03-15T12:30:10 and COLLATE will handl sorting 2011-03-15T12:30:10 eeevil: so, while waiting, do we still recommend 'C' for non-Latin script libraries? 2011-03-15T12:31:03 dbwells: that recommendation (from me) will not change. COLLATE will address the issue of sorting, period. C will be faster for equality searches, always 2011-03-15T12:31:41 Just to add some more data, our library, not knowing any better at first, has been using en-us.UTF-8 since we went live. Speed is not fast, but nevertheless workable. 2011-03-15T12:32:50 And our 16 GB RAM test db server, even with 'C', struggles horribly to search our 2M records 2011-03-15T12:33:41 dbs: if only there was a consulting/services company you could have look into that for you... ;) 2011-03-15T12:34:01 * eeevil steps away from the mic 2011-03-15T12:34:26 eeevil: Yeah, helpless little me 2011-03-15T12:34:33 *snerk* 2011-03-15T12:34:49 More relevant details: our server has 16GB of RAM as well, and right around one million records. Maybe I am too patient :) 2011-03-15T12:34:57 dbs: see, it works on many levels 2011-03-15T12:35:06 Ok how about we say there aren't any obvious issues recommending 'C' as locale for libraries using primarily non-Latin character sets and post to the dev list with any issues/discussion. 2011-03-15T12:35:28 Moving on to "Patch review queue" 2011-03-15T12:35:58 eeevil: I don't even know what we're talking about anymore 2011-03-15T12:36:12 I've been getting some stuff straight from tsbere's git repo, which aren't listed in launchpad 2011-03-15T12:36:55 which, can make me a bottleneck, but there's less overhead when it works :) 2011-03-15T12:36:57 What's with the weird SVN thing running at svn.open-ils.org, anyway? Is that something like git, but dumber? 2011-03-15T12:37:24 * phasefx thinks the subversion on svn.open-ils.org could use an upgrade 2011-03-15T12:37:26 If jamesrf is around, I would love to get his opinion (maybe later) on the org unit contexts for circ/hold matrix and see if we can get that applied someday to 2.0 / trunk. His contents were designed for 1.6.0, if I remember correctly? 2011-03-15T12:38:53 (saw that one in the LP link and been curious about it, but maybe can talk about that later...) 2011-03-15T12:39:04 I'd love to see it generalized so you could select the ou-ish field you want to filter on in addition ot the filter itself 2011-03-15T12:39:56 eeevil: That does sound cool. 2011-03-15T12:40:38 So can once of the core devs take a look at looking at the patches and getting them into trunk? 2011-03-15T12:41:16 s/once/one/ 2011-03-15T12:41:39 I'll be taking a look at grace period, unless someone else wants it 2011-03-15T12:41:46 I will volunteer to get the grace period stuff tested and committed. 2011-03-15T12:41:48 sheeesh s/take a look at looking at the/take a look at the/ 2011-03-15T12:41:49 doh 2011-03-15T12:42:19 I can look at patron opt-in 2011-03-15T12:42:49 though I see eeevil poked his head in on that ticket 2011-03-15T12:42:50 dbwells: Would you like me to grab an updated patch file, or are you fine with the updated git repo? 2011-03-15T12:42:57 dbwells: we can both look at it. don't let me looking stop you from doing so as well 2011-03-15T12:43:03 dbwells++ phasefx++ eeevil++ 2011-03-15T12:43:12 or eeevil for that matter. 2011-03-15T12:43:23 * tsbere has at least one commit not represented in any of the attached patch files 2011-03-15T12:43:58 tsbere: mind adding git cmds for grabbing, for easy cut-n-paste? ( have it remote'd, but others may not) 2011-03-15T12:44:19 Ok I say we put this back on the next meetings agenda and move on to "Release statuses" 2011-03-15T12:44:48 How has the process been working folks? 2011-03-15T12:45:16 tsbere: naw, don't need the patch. But at this point I will defer to eeevil, as I would need to set up a 2.1 testbed first, and we are very likely taking the plunge to 2.0 live this weekend. 2011-03-15T12:45:18 working OK for me 2011-03-15T12:45:44 dbwells: Yay, more 2.0 buddies :) 2011-03-15T12:45:47 we need a 2.0.4 RSN (important bug found yesterday) 2011-03-15T12:46:22 and, barring anything like what happened with trying to get 2.0.3 out, I'll cut 1.6.1.8 as well 2011-03-15T12:46:34 I created the 2.0.4 milestone and "Fix released" the LP bugs, but somebody else is supposed to do that I think; also, no release announcement yet on blogs etc? 2011-03-15T12:46:54 dbs: not yet, afaict 2011-03-15T12:47:11 dbs: I'll get on the 2.0.3/4 announcements 2011-03-15T12:47:14 I also screwed up by not listing the previous clients for download. Although, csharp is referring to a page that did at one time exist, ye olde "code_museum.php" 2011-03-15T12:47:15 dbs: I think afterl mentioned to me that she had updated freshmeat, not sure about others. 2011-03-15T12:47:33 eeevil: When do we expect 2.0.4 2011-03-15T12:47:44 For 2.0.3 I mean 2011-03-15T12:48:10 http://evergreen-ils.org/code_museum.php still exists, just hasn't been maintained for a long time 2011-03-15T12:48:45 moodaepo: tomorrow ok (with everyone)? 2011-03-15T12:48:46 Personally, I prefer the idea of a clean link to an "older releases" page so that we can avoid making the downloads page look like a crapload of links 2011-03-15T12:49:09 +1 to that 2011-03-15T12:49:16 dbs: I agree. eeevil: Works for me other devs? 2011-03-15T12:49:18 dbs: I agree, but we seem to be in the loyal opposition ;) 2011-03-15T12:49:36 or may be not! 2011-03-15T12:50:09 eeevil: crapload of links on page == my first "website" circa 1996 2011-03-15T12:50:41 Ok finally 2.1 any targeted dates? 2011-03-15T12:51:07 I still like april for RC 2011-03-15T12:51:12 random aside, if we start building 2.1 clients with NSIS, I vote for using that compile flag that turns off the "EULA" crap. GPL isn't an EULA 2011-03-15T12:51:14 or whatever we call it 2011-03-15T12:51:33 phasefx++ 2011-03-15T12:51:38 phasefx: agreed 2011-03-15T12:52:10 phasefx: +1 2011-03-15T12:52:42 phasefx: That can, with a single-line patch, be made the default. Shall I whip that up? 2011-03-15T12:52:56 tsbere++ yes please 2011-03-15T12:53:21 eeevil: Ok then we set a tentative target as April first week for RC 2011-03-15T12:53:27 we also might want to give thought on whether we want to provide incremental updates for communitity client builds or not 2011-03-15T12:53:38 for some spelling of community 2011-03-15T12:53:39 moodaepo: well, "before the conf" is my personal goal ;) 2011-03-15T12:54:13 eeevil: Revised to "sometime in April" 2011-03-15T12:54:19 moodaepo: but if moving the initial bar up a bit helps with motivation (hangings and fortnights) that's fine 2011-03-15T12:54:34 probably not a whole lot of thought (I'm thinking no:) 2011-03-15T12:54:36 * dbs will try not to make further stupid breaking commits in the near future 2011-03-15T12:54:56 Ok any other thoughts on 2.1 release date/client? 2011-03-15T12:55:17 dbs: you're still less often than me, so you're ahead of the game 2011-03-15T12:55:20 RC, meaning between now and April, we should see some more alphas/betas? 2011-03-15T12:55:46 bshum: I would hope so : ) 2011-03-15T12:55:48 bshum: yep 2011-03-15T12:56:03 Cool. 2011-03-15T12:56:06 phasefx: Updated my installer branch, for the record. 2011-03-15T12:56:16 gracias 2011-03-15T12:56:21 Ok since I don't see anything else coming up about 2.1, meeting adjourned? 2011-03-15T12:56:24 and there's always trunk and the public repos ... hrm, that's a good band name: Trunk and the Public Repos 2011-03-15T12:56:37 moodaepo: seconded 2011-03-15T12:57:15 Ok folks next meeting March 29th same time, same place. 2011-03-15T12:57:37 eeevil++ # Band name 2011-03-15T12:58:38 eeevil: Did you want me to post the git copy/paste lines in any launchpad bugs I make with git branches, as well as the current grace period entry? 2011-03-15T12:58:56 StephenGWills: hold_targeter.pl checks for items that fulfill a hold and applies them to the patron. 2011-03-15T12:59:05 tsbere: I think it would be helpful, yes 2011-03-15T13:00:18 moodaepo: thanks. sorry to intrude on the meeting like a blockhead. 2011-03-15T13:00:30 eeevil/tsbere: huh. So the problem with creating the 'evergreen' schema for lowercase() is that PostgreSQL automatically prepends the db user's username to the schema search path, and I suspect 'evergreen' is very often used as the db user name 2011-03-15T13:01:10 perhaps "egfunctions" is a better variant of the schema? 2011-03-15T13:01:12 Thus, the default schema for subsequently created not-explicitly-qualified functions becomes 'evergreen' in that case; so tsbere's qualification is required too 2011-03-15T13:01:15 or "eglocal" or something 2011-03-15T13:01:22 eguniversa,l 2011-03-15T13:01:23 dbs: I was wondering if you'd run into a user/search_path problem 2011-03-15T13:02:43 it's okay, as long as the search path is set 2011-03-15T13:03:08 *** jasonb has quit IRC 2011-03-15T13:06:03 *** slipscomb has left #evergreen 2011-03-15T13:06:22 eeevil: Updated 732679 with a "help" block. Saved it as a template locally for quick addition into other bugs/emails. 2011-03-15T13:07:10 *** gdunbar has quit IRC 2011-03-15T13:08:06 thanks 2011-03-15T13:10:57 *** djfiander has quit IRC 2011-03-15T13:29:09 dbs: Is that why my evergreen schema has all kinds of other functions in it after a second load? 2011-03-15T13:29:34 tsbere: yep. And the search path seems to not affect that :( 2011-03-15T13:30:02 (in another meeting at the moment but that seems to be the case) 2011-03-15T13:30:11 dbs: Well, the one search path setting will have an effect on, at best, that invocation of psql. 2011-03-15T13:30:37 set search path at the top of each SQL file? 2011-03-15T13:31:11 And then you have a possible issue in functions that aren't schema-qualifying? 2011-03-15T13:31:27 * tsbere thinks this whole thing is a headache 2011-03-15T13:32:03 And this is why public.extract_marc_field isn't working for us, isn't it. Because the def isn't schema-qualified it is hiding in evergreen, not public. 2011-03-15T13:32:07 right 2011-03-15T13:33:11 eeevil pasted "for dbs' 2.0 slow search -- a test" at http://paste.lisp.org/display/120537 2011-03-15T13:34:05 On the other hand......I think the search path can be rigged to default functions created in a given file to a given schema. So saying acq, pg_catalog before loading the acq schema would take unqualified functions there and put them in acq. 2011-03-15T13:34:26 tsbere/dbs: or set the search_path in postgresql.conf 2011-03-15T13:35:08 eeevil: That sounds like it has the potential to horribly break who knows what that is sharing the DB server 2011-03-15T13:35:45 tsbere: IMO, sharing your EG db server with anything else sounds like a horrible idea :) 2011-03-15T13:35:54 hrm... however 2011-03-15T13:35:58 it can be set per db 2011-03-15T13:37:46 ALTER DATABASE SET search_path TO 'public,pg_catalog'; 2011-03-15T13:38:59 er, with a database in there, of course 2011-03-15T13:41:34 Honestly, I would prefer to not do stuff like that if possible. For now I am going to swap to a non-evergreen username instead. 2011-03-15T13:41:40 put that directly in build-db.sh? 2011-03-15T13:42:10 tsbere: why? 2011-03-15T13:42:32 dbs: sure, I guess generate a statement to do that and echo it to psql 2011-03-15T13:43:28 eeevil: Because it isn't obvious to those going in that the setting is there, and if anything forgets to put that setting in down the road things may break for no apparent reason? 2011-03-15T13:44:01 obv, 9.0 changed how search_path interacts with object creation, so we need to either change everything to be schema qualified (and ideally, non-public) or compensate for it 2011-03-15T13:44:38 tsbere: but a search_path of 'public,pg_catalog' works with every version. it's 9.0 that apparently changed behavior on us 2011-03-15T13:44:54 I dunno if 8.4 wouldn't have been effected. Did anyone try creating an evergreen schema on 8.4 before doing a load? 2011-03-15T13:45:02 so setting that on all versions (via upgrade script) seems perfectly fine to me 2011-03-15T13:49:35 upgrade script will need to know the name of the database 2011-03-15T13:51:54 *** b_bonner has joined #evergreen 2011-03-15T13:51:57 dbs: true ... hrm 2011-03-15T13:52:42 I suspect tsbere is correct that the same problem would happen in 8.4 where a schema exists matching the db user's name 2011-03-15T13:53:05 So hopefully we can get a GSoC student to explicitly qualify everything, eh? :) 2011-03-15T13:53:23 short term, we could change "evergreen" schema name to "egFJ@#FN#(*" or the like 2011-03-15T13:53:34 or "munge" ;) 2011-03-15T13:53:47 CREATE SCHEMA pleasepleasedonotcreateauserwiththisname; 2011-03-15T13:57:31 psql --set dbname=foobar 2011-03-15T13:57:36 just a small observation about the default eg.conf apache config, some mod_expires settings are set to A64800 -- wondering is that intentional or was 604800 intended? 2011-03-15T13:57:57 then: ALTER DATABASE :foobar SET search_path = 'public,pg_catalog'; 2011-03-15T13:58:19 easy enough to explain that in the upgrade instructions, I think. no? 2011-03-15T13:58:29 eeevil: Naaah 2011-03-15T13:58:45 tsbere pasted "Change current db" at http://paste.lisp.org/display/120538 2011-03-15T13:58:47 "run the upgrade sql as follows" 2011-03-15T13:59:20 tsbere: dingdingding! you're the big winner! 2011-03-15T13:59:51 *** KingNightWolf_ has joined #evergreen 2011-03-15T14:00:39 (which can be spelled: DO $$BEGIN EXECUTE 'ALTER DATABASE ' || current_database() || $_$ SET search_path TO 'public,pg_catalog'$_$; END;$$; ) 2011-03-15T14:00:44 nice one tsbere 2011-03-15T14:01:36 *** gdunbar has joined #evergreen 2011-03-15T14:01:36 eeevil: Alternatively, the function can take the setting and value as parameters and be usable for any number of settings. But whichever works. 2011-03-15T14:02:08 jamesrf: 18 hours is good enough for anyone! well, maybe when you're changing things frequently. When things settle down, though, "1 week" makes much more sense 2011-03-15T14:02:21 *** KingNightWolf has quit IRC 2011-03-15T14:02:21 *** KingNightWolf_ is now known as KingNightWolf 2011-03-15T14:02:57 jamesrf: would make sense to switch from A64800 to "access plus 18 hours" or "access plus 1 week" for clarity, in any case 2011-03-15T14:03:37 * tsbere did find the function variant easier to debug typos in than the DO variant, though 2011-03-15T14:05:20 tsbere: fair enough 2011-03-15T14:05:44 and a "set settings in this db" function would probably continue to be useful 2011-03-15T14:06:16 yeah maybe, although i thought it looked like maybe someone forgot a zero 2011-03-15T14:06:56 eeevil: So, does this result in a 000.db_settings.sql loader file? 2011-03-15T14:08:20 tsbere: sounds good to me. dbs, objections/thoughts? 2011-03-15T14:08:32 (and a upgrade/0XXX.foo file) 2011-03-15T14:09:02 I'd buy shares in that 2011-03-15T14:25:34 eeevil: thanks for the relevance adjustment test - still hitting timeouts on 2-word kw phrases like "computer science" with that in place, but title searches for relatively rare sets of results seem more tolerable 2011-03-15T14:26:19 Don't have hard numbers though. I should script a set of searches and time them with and without the adjustment in place, I guess. 2011-03-15T14:28:28 eeevil: Just spent the last hour or two trying to get a better handle on locales in Postgresql. You had mentioned that performance was not the reason you advocate for locale = 'C', but until that moment I hadn't heard a different reason. Is your primary reason that 'C' provides the most reliable baseline? 2011-03-15T14:30:48 Looking back again, I see you did mention 'neutral default'. 2011-03-15T14:30:51 dbwells: they're both important factors ... indexes, even with text_pattern_ops, are somewhat slower with a non-C locale 2011-03-15T14:31:12 If we do enforce lc-ctype=C, then we can drop the text_patten_ops indexes and make better use of available RAM for caching the remaining indexes 2011-03-15T14:32:25 but, yes, having a specific, reliable (if not always correct) ordering (that is, codepoint ordering) until we get COLLATE or use the locale-indexing addon is preferable, IMO, to instance-specific locale-based orderings 2011-03-15T14:32:54 sorting Armenian will probably be wrong in en-US, and vice versa 2011-03-15T14:33:19 (actually, because of ascii, that's probably not true all the time, but that makes it even more complicated) 2011-03-15T14:35:05 dbs: good to hear ... fwiw, the SVF branch introduced the use of rank_cd() and the ability to adjust ranking algorithms used via modifiers 2011-03-15T14:35:25 QueryParser search modifiers, that is 2011-03-15T14:37:12 eeevil: My curiosity in bringing this up had mostly to do with our Armenian friends. In your opinion, even if their entire catalog is Armenian, and they are willing to take the performance hit, are they still better off using locale='C'? I see a lot of people in various Postgres discussions leaning that way, but wanted to get your take. 2011-03-15T14:37:43 eeevil: to elaborate on what I said in the meeting earlier, long term I wonder whether trying to squeeze more out of PostgreSQL's FTS is worth it, compared to adopting something like Solr in the long term. As we get more and more arcane, we reduce the pool of potential contributors 2011-03-15T14:38:25 And the Solr community seems to be a lot broader and Solr seems to provide a lot more bang for the buck performance wise. 2011-03-15T14:38:49 I don't mean to imply any disrespect to what you've been able to do with Evergreen on PostgreSQL - it's amazing! 2011-03-15T14:38:54 * dbwells wonders if eeevil should have 'office hours' for answering questions from the masses 2011-03-15T14:39:02 heh 2011-03-15T14:40:00 dbwells: that's a choice they can certainly make, based on local needs. in their case, it may very well be the right one, but they are an outlier today, and we see a path (or the beginnings of one) to better cross-locale support down the road, so my recommendation for the project as a whole is to use C 2011-03-15T14:40:57 dbs: no disrespect detected. my primary concern remains visibility testing, which has (at least) two variants: public and staff 2011-03-15T14:41:23 *** b_bonner_ has joined #evergreen 2011-03-15T14:42:13 in test queries on a warm index and heap, and well tuned PG (at least, in my experience, almost without exception), that's where most (as in, everything past 1s) of the time is spent 2011-03-15T14:42:17 eeevil: Sure - and there are all sorts of advantages to having highly capable search capabilities within the database. You know I'm a big RDBMS fan 2011-03-15T14:43:04 ... merge the first parens into the second ... 2011-03-15T14:43:46 *** b_bonner has quit IRC 2011-03-15T14:43:47 *** b_bonner_ is now known as b_bonner 2011-03-15T14:44:33 eeevil++ # thanks for helping complete my understanding 2011-03-15T14:44:35 then there's the syncronization issues, and the relative lack of durability of a lucene index (unless it grew a WAL equiv recently), and plenty of other things to consider 2011-03-15T14:45:31 dbs: I was thinking of adding your "Teach Evergreen to update Solr" for the GSoC list, thoughts? 2011-03-15T14:45:37 dbs: I believe I even know how to do it transparently /through/ the db ... but I'm just not convinced that it's where I should spend my time 2011-03-15T14:45:42 eeevil: Yep - those are some of the advantages to "having highly capable search capabilities" (and redundant redundancy!) within the database, for sure 2011-03-15T14:46:27 oh, I know you know most or all of what I'm rambling about, but it's important for context, I think ... for the archives, etc ;) 2011-03-15T14:46:44 * dbs nods 2011-03-15T14:48:14 *** b_bonner has quit IRC 2011-03-15T14:49:10 if i may say, I feel the arcane-ness of Evergreen is probably one of the biggest hurdles to contribution 2011-03-15T14:51:13 jamesrf: Arcane-ness? How so? 2011-03-15T14:51:27 As in what do you mean by arcane-ness. 2011-03-15T14:51:53 there's a lot of parts to Evergreen and some aren't the most most widely known technologies 2011-03-15T14:52:24 for example, staff in a library are more likely to be familiar with the workings of Solr rather than tsearch 2011-03-15T14:52:36 few have any clue about XUL and likely haven't run an XMPP server 2011-03-15T14:52:58 jamesrf: Wait, staff in a library are likely to be familiar with anything their current ILS's user interface doesn't show them? 2011-03-15T14:53:19 jamesrf: i understand and agree (so far) with your sentiment. 2011-03-15T14:54:42 tsbere: well i more meant systems librarians than general staff 2011-03-15T14:55:23 * dbs was thinking of the hstore contrib module for PostgreSQL when he mentioned "getting more arcane" - eeevil is doing some cool stuff with that for SVF that I'm still wrapping my head around 2011-03-15T14:55:32 tsbere: in the case of solr, the experience likely comes from experimentation in new discovery layers for the previous ILS, or from library projects unrelated to either ILS. 2011-03-15T14:55:33 "systems" librarians. 2011-03-15T14:57:13 (apologies for switching between 1st and 3rd person there) 2011-03-15T14:57:14 developer documentation can/will/does help, as well as picking brains here and elsewhere, and some areas like the opac are getting lots of love in the form of berick's tt-opac branch. 2011-03-15T14:57:59 i agree the tt-opac is great 2011-03-15T14:58:31 to ride a hobby horse, test suites that ensured before/after results were as expected would be helpful to new contributors too, methinks. And to me and my addled fumbling. 2011-03-15T14:59:00 there are large chunks that i do not yet understand, and with the parts that i think i do have a decent understanding of, i suspect I'm just getting more used to it over time. 2011-03-15T14:59:24 dbs++ tests++ 2011-03-15T15:02:05 tt-opac++ 2011-03-15T15:02:26 dbs: oh! ... remember authority control sets? 2011-03-15T15:02:45 eeevil: yes, I was going to make that a part of the "authority futures" part of my talk 2011-03-15T15:03:22 (hoping to do something similar to what we did for the SRU indexes, instead of hardcoding maps all over the place) 2011-03-15T15:03:29 well, I'll be talking about it a lot at the beginning of april ... it's officially funded, hopefully targeting 2.2 2011-03-15T15:03:35 SWEET 2011-03-15T15:04:17 Now if only I could reproduce the problems parsr/phasefx have managed to trigger on some systems.. 2011-03-15T15:05:21 * dbs goes to get some lunch 2011-03-15T15:11:06 jeff: are TADL and GRPL on the same system? 2011-03-15T15:11:50 jamesrf: they are 2011-03-15T15:13:16 i'm just curious about the catalog.tadl.org vs michiganevergreen.org 2011-03-15T15:13:59 <_bott_> catalog.tadl.org = tadl.michiganevergreen.org 2011-03-15T15:16:55 so can i ask you something? how did you make it so that if change your ol=22 to ol=9 it doesn't work? 2011-03-15T15:18:33 or i guess more generically, i'd be interested in how you've set up your vhosts 2011-03-15T15:19:25 <_bott_> It's pre-orgHiding (i.e. http://svn.open-ils.org/trac/ILS/changeset/17216) So, we specifically chop up the OrgTree.js to suit our needs. If you choose an org_unit.id that doesn't exist in that file, you get no where. 2011-03-15T15:19:47 * csharp created http://www.open-ils.org/dokuwiki/doku.php?id=qa:gpls_pines_evergreen_test_cases on the wiki, linking from jamesrf 's qa test cases page 2011-03-15T15:20:21 it's a bit rough from the Excel -> OpenOffice -> wiki syntax conversion via Perl, but we'll clean it up 2011-03-15T15:20:22 <_bott_> We have separate vhosts for each system. Each points to a totally different set of opac and xul files. 2011-03-15T15:21:23 _bott_: how do you manage upgrades? do you just leave it up to each library to upgrade their OPAC? 2011-03-15T15:21:52 jamesrf: see what _bott_ said. that's something they set up for all michigan evergreen libraries before we even went live -- we're just the only library who has a second vhost for catalog.tadl.org 2011-03-15T15:22:23 jamesrf: our staff clients point to tadl.michiganevergreen.org while patrons are directed to catalog.tadl.org 2011-03-15T15:23:01 *** jenny has quit IRC 2011-03-15T15:24:10 <_bott_> "manage upgrades" ...very carefully? 2011-03-15T15:26:01 <_bott_> Thus far we (GRPL) have done virtually all the upgrade related changes, which don't amount to a whole lot. Most libraries are still using a pretty generic template. It's a matter of setting up a base, copying it around, then tweaking .css and images. Then nailing down some specific changes. 2011-03-15T15:26:35 <_bott_> jeff: you're not even a separate vhost, just a ServerAlias 2011-03-15T15:27:22 <_bott_> of course Apache keeps screaming at me for the SSL cert using multiple vhosts 2011-03-15T15:28:20 <_bott_> 2.x adds some fun, in that we need to put some tweaks in EGWeb.pm to point toward everything we want. 2011-03-15T15:28:50 * tsbere plans on using rewriterules for different libraries 2011-03-15T15:29:19 yeah we use rewrite rules for 30-something libraries 2011-03-15T15:30:07 er, all of them anyway 2011-03-15T15:30:51 was mainly interested in ways that we could isolate more and provide more local control over web files maybe through FTP or VCS or something but at the same time make sure it's maintainable 2011-03-15T15:34:41 jamesrf: we're able to check out and commit against the files which comprise our docroot -- everything that's non-shared. we then ask grpl to push the changes to testing and/or production. 2011-03-15T15:36:14 ah ok that's sorta what i had in mind 2011-03-15T15:36:32 thanks 2011-03-15T15:36:53 jeff++ 2011-03-15T15:36:55 _bott_++ 2011-03-15T15:36:58 michigan++ 2011-03-15T15:38:42 @karma michigan 2011-03-15T15:38:42 jamesrf: Karma for "michigan" has been increased 1 time and decreased 0 times for a total karma of 1. 2011-03-15T15:39:04 michigan++ 2011-03-15T15:40:52 *** jamesrf has quit IRC 2011-03-15T15:41:10 *** jamesrf has joined #evergreen 2011-03-15T15:51:47 *** KingNightWolf has quit IRC 2011-03-15T15:52:08 *** KingNightWolf has joined #evergreen 2011-03-15T15:55:45 tsbere / eeevil : so, which direction do you want to go for the "ALTER DATABASE _foo_ SET search_path = 'public,pg_catalog';" in upgrade & 000.whatnot.sql ? 2011-03-15T15:56:01 as we should probably resolve that prior to 2.0.4 2011-03-15T16:10:45 michigan++ # just because ;) 2011-03-15T16:14:51 dbs: not sure I follow ... what do you mean by direction? 2011-03-15T16:16:22 *** dbs has quit IRC 2011-03-15T16:16:42 I imagine at a minimum what methodology and who will make the changes. But I am only guessing. 2011-03-15T16:17:02 And we apparently have to wait for his return to find out what he meant. 2011-03-15T16:17:12 *** dbs has joined #evergreen 2011-03-15T16:22:06 dbs: what did you mean by "direction"? (since I think you disconnected before eeevil asked) 2011-03-15T16:22:42 you each had different approaches to solving the same problem 2011-03-15T16:22:57 * dbs goes to web irc_logs 2011-03-15T16:23:27 I was under the impression that our two approaches were "do the same thing with different syntactical wrappings" 2011-03-15T16:23:39 yes, what tsbere said 2011-03-15T16:24:58 oh, I like the idea of a "set stuff for this db" function 2011-03-15T16:25:12 so, a persistent, parameterized version of tsbere's 2011-03-15T16:26:58 There are features/gotchas we can use there. Should I whip up a function quick that handles them? 2011-03-15T16:29:04 hopefully without leaving a wide open door for clever nastiness :) 2011-03-15T16:31:03 dbs: ANYTHING using execute can possibly do that, unfortunetly. 2011-03-15T16:31:14 tsbere: yeah 2011-03-15T16:31:49 *** kmlussier has quit IRC 2011-03-15T16:32:07 if you have access to the db to execute arbitrary functions, you've already won 2011-03-15T16:33:09 Assuming your access is with a user that has been granted those privileges, yes 2011-03-15T16:33:36 Anyone else want to join our chorus? 2011-03-15T16:34:05 I broke my database, please fix 2011-03-15T16:35:39 phasefx++ 2011-03-15T16:36:04 * phasefx is sadly serious 2011-03-15T16:36:05 well, phasefx used the ALTER, then build_db.sh died 2011-03-15T16:37:06 how do I show/observe the path? 2011-03-15T16:37:51 show search_path; 2011-03-15T16:40:25 tsbere annotated #120538 "Updated Variant" at http://paste.lisp.org/display/120538#1 2011-03-15T16:40:26 dbs: so, we need to remove the quotes around the search path value 2011-03-15T16:40:42 heh 2011-03-15T16:40:51 and, we'll need to remove schema qual from some things (tsvector type, etc) 2011-03-15T16:41:30 what? setting search_path breaks explicitly qualified names? 2011-03-15T16:41:31 which is only in Open-ILS/src/sql/Pg/002.functions.aggregate.sql 2011-03-15T16:41:52 dbs: no ... there is no public.tsvector in 9.0 stock 2011-03-15T16:41:58 oh. hah 2011-03-15T16:42:08 it's spelled pg_catalog.tsvector, because it went into core 2011-03-15T16:42:22 so just that one place 2011-03-15T16:42:49 and removing the schema qual lets search_path do its thing 2011-03-15T16:43:28 Any comments on the improved variant? 2011-03-15T16:44:09 (would have thrown it in the evergreen schema, but I think the intent is for it to exist before any custom schemas do) 2011-03-15T16:44:48 tsbere: the quote_literal will break this, unfortunately 2011-03-15T16:44:55 It will? 2011-03-15T16:45:01 because we can't have the value surrounded in quotes 2011-03-15T16:45:01 yes 2011-03-15T16:45:20 works: ALTER DATABASE _foo_ SET search_path = public, pg_catalog; 2011-03-15T16:45:30 does not work: ALTER DATABASE _foo_ SET search_path = 'public, pg_catalog'; 2011-03-15T16:45:39 well, I mean, the statement succeeds 2011-03-15T16:45:57 but now the search_path has one schema in it, called "public, pg_catalog" 2011-03-15T16:46:00 not two 2011-03-15T16:46:12 wait, but we don't have everything in the "public, pg_catalog" schema? (I KID) 2011-03-15T16:46:20 hmmm 2011-03-15T16:46:31 so, we have to leave the security hole :( 2011-03-15T16:46:37 or drop the function 2011-03-15T16:46:44 I have ideas. 2011-03-15T16:46:53 that's what we get for sending a bare string in to do an array's job 2011-03-15T16:46:55 or, take an array 2011-03-15T16:47:03 heh 2011-03-15T16:47:49 indeed 2011-03-15T16:48:01 ok ... I have to commute. back on later 2011-03-15T16:48:10 for expediency, I could change the "evergreen" schema to "open_ils" (as none of the docs tell people to create a db user named "open_ils") and we could fix this properly later 2011-03-15T16:48:18 * dbs needs to jet too 2011-03-15T16:48:32 (don't start any rumours about eeevil and I, folks) 2011-03-15T16:48:33 dbs: meh 2011-03-15T16:49:13 too late 2011-03-15T16:49:41 *** bshum has quit IRC 2011-03-15T16:53:22 *** dbs has quit IRC 2011-03-15T16:59:30 *** bshum has joined #evergreen 2011-03-15T17:00:52 tsbere annotated #120538 "Lets try this again" at http://paste.lisp.org/display/120538#2 2011-03-15T17:03:18 Does anyone know anything about the spelling_dictionary options in opensrf.xml? 2011-03-15T17:03:55 *** tildeequals has joined #evergreen 2011-03-15T17:04:05 Oh, wait. Dang, I don't think string_agg exists before 9.0. 2011-03-15T17:04:35 * tsbere suggests hardcoding the setting for before 9.0, then 2011-03-15T17:07:06 committed a change to trunk for the tsvector schema stuff. voodoo to me, so fair warning ;) 2011-03-15T17:27:04 bshum: http://list.georgialibraries.org/pipermail/open-ils-commits/2010-March/009323.html & http://www.open-ils.org/dokuwiki/doku.php?id=evergreen-admin:customizations:i18n#spell_checking might help. 2011-03-15T17:28:11 *** Dyrcona has quit IRC 2011-03-15T17:29:33 *** rickd_ has quit IRC 2011-03-15T17:53:21 moodaepo: Ah, yes, I did find that. Just wondering if any sites are using custom *_dict.txt files as defined in the opensrf.xml 2011-03-15T17:53:28 Or if that's just something that never got quite finished. 2011-03-15T17:57:55 *** KingNightWolf_ has joined #evergreen 2011-03-15T17:58:49 *** KingNightWolf_ has quit IRC 2011-03-15T18:01:36 *** KingNightWolf has quit IRC 2011-03-15T18:27:22 *** Callender-Home has joined #evergreen 2011-03-15T18:58:27 *** Callender-Home has quit IRC 2011-03-15T19:08:01 *** KingNightWolf has joined #evergreen 2011-03-15T19:50:37 *** tpham has joined #evergreen 2011-03-15T20:08:38 *** tildeequals has quit IRC 2011-03-15T20:16:22 *** tpham has quit IRC 2011-03-15T20:49:34 dbwells++ # return of the close tab button! :D 2011-03-15T21:33:13 *** KingNightWolf has quit IRC 2011-03-15T22:06:26 *** tildeequals has joined #evergreen 2011-03-15T22:56:16 *** dbs has joined #evergreen 2011-03-15T23:40:13 bah, stupid question at the end of my commit to trunk for aggregate functions, as trunk/2.1 is 9.0-only 2011-03-15T23:47:07 Took a stab at a search_path setting, let's see if it works out.