2011-12-14T00:58:04 *** finnx has quit IRC 2011-12-14T01:00:13 *** finnx has joined #evergreen 2011-12-14T01:06:53 *** finnx has quit IRC 2011-12-14T01:21:43 *** finnx has joined #evergreen 2011-12-14T02:00:47 *** finnx has quit IRC 2011-12-14T02:16:51 *** finnx has joined #evergreen 2011-12-14T06:57:46 *** wolf29 has joined #evergreen 2011-12-14T08:04:00 *** plux has joined #evergreen 2011-12-14T08:10:06 *** bjwebb has quit IRC 2011-12-14T08:11:42 *** bjwebb has joined #evergreen 2011-12-14T08:20:39 *** Dyrcona has joined #evergreen 2011-12-14T08:26:40 *** gdunbar has joined #evergreen 2011-12-14T08:45:57 *** kmlussier has joined #evergreen 2011-12-14T08:49:01 *** bjwebb has quit IRC 2011-12-14T08:49:58 *** bjwebb has joined #evergreen 2011-12-14T08:52:46 * tsbere throws more comments at berick's address alert bug 2011-12-14T08:54:30 thanks tsbere 2011-12-14T08:54:46 I went to review/commit it. Didn't get that far. <_< 2011-12-14T08:56:16 *** kmlussier has quit IRC 2011-12-14T09:00:42 *** kmlussier has joined #evergreen 2011-12-14T09:07:21 *** Meliss has joined #evergreen 2011-12-14T09:09:16 tsbere: good catch. pushing update momentarily 2011-12-14T09:12:42 *** _bott_ has quit IRC 2011-12-14T09:13:42 *** _bott_ has joined #evergreen 2011-12-14T09:18:34 *** kmlussier_ has joined #evergreen 2011-12-14T09:20:35 *** kmlussier has quit IRC 2011-12-14T09:20:58 *** kmlussier_ is now known as kmlussier 2011-12-14T09:23:59 berick: You *are* allowed to overwrite your previous rebases, you know ;) 2011-12-14T09:25:09 tsbere: yeah, i'm (uncharacteristically) pack-rat-ish w/ branches for some reason 2011-12-14T09:25:27 of course, now i should I probably clean them up ;) 2011-12-14T09:25:38 we need to figure out what to do with ancient working branches anyway, I think. ;) 2011-12-14T09:25:55 git+- 2011-12-14T09:26:14 yeah. it's always amusing setting up a new workstation and doing the initial fetch 2011-12-14T09:26:30 "three screens later........." 2011-12-14T09:26:36 if not more 2011-12-14T09:27:07 wonder if it's possible to move branches to a sub-dir (say, archive/) that is not fetched by default. 2011-12-14T09:27:29 meh, or just delete stuff 2011-12-14T09:27:30 berick: branches don't cost much per se 2011-12-14T09:27:57 gmcharlt: They cost confusion to tab-completion later on! ;) 2011-12-14T09:27:58 except in the sense of the cognitive load of figuring out which topic branches are current, and which are hoary and dusty 2011-12-14T09:28:04 gmcharlt: right, i'm just thinking for the sake of mental clarity 2011-12-14T09:28:33 * Dyrcona likes deleting his local branches once they've made it into master or no longer server their purpose. 2011-12-14T09:28:33 yeah - but I'm of the view that that's what LP is for 2011-12-14T09:28:48 at least as far as published topic branches are concerned 2011-12-14T09:28:57 one's local branches are a different matter 2011-12-14T09:29:08 I also delete mine once they've been merged into master 2011-12-14T09:29:38 I delete mine once I realize "oh, dang, my git branch command no longer fits on my screen" ;) 2011-12-14T09:29:39 all of that said, it wouldn't be hard to rename old branches 2011-12-14T09:30:15 even automatically (e.g., if the most recent commit date on a branch is six months in the past, rename the branch to archive/foo 2011-12-14T09:30:30 Or rather push to archive/foo and delete the original? 2011-12-14T09:30:55 moving them around in the original repo doesn't help as much if you are looking for a branch with a specific name in the repo ;) 2011-12-14T09:33:38 I have deleted published published topic branches when I've typoed the name or I've decided to change the name before creating a LP bug. 2011-12-14T09:33:57 * Dyrcona can't type today. 2011-12-14T09:34:48 I dunno. You look to be typing fine. A tad redundantly, granted.... 2011-12-14T09:35:19 * Dyrcona works for the Deparment of Redundancy Department. :) 2011-12-14T09:35:59 I think that extra published slipped in when I stopped and edited what I was typing midstream. 2011-12-14T09:36:22 berick: Am I missing something, or is there no menu item for the address alert editing interface? 2011-12-14T09:36:35 *** jenny has joined #evergreen 2011-12-14T09:36:46 there's been some talkin' about in-db unapi recently ... I have a branch to share (I think berick's seen it) that allows finer-grained control over sub-object inclusion, paging thereof, and lays the groundworks for sub-object sorting 2011-12-14T09:37:00 it's a little bit-rotted, but anyone want to see it? 2011-12-14T09:38:34 tsbere: *headdesk* 2011-12-14T09:38:52 * berick prepares to push rebase3... j/k 2011-12-14T09:38:54 i'll add that 2011-12-14T09:42:08 *** shopkins has joined #evergreen 2011-12-14T09:43:58 hi - having problems running upgrade scripts 2.1-2.2-alpha1. Keep getting error: ' cannot change return type of existing function' on line 69 onf the script. Can't drop the functions cause they are used further in the script, any suggestions? 2011-12-14T09:47:18 *** fortin has joined #evergreen 2011-12-14T09:49:53 *** fortin has quit IRC 2011-12-14T09:53:08 *** copystar has joined #evergreen 2011-12-14T09:55:27 *** kmlussier has quit IRC 2011-12-14T09:57:11 shopkins: I think if you add a COMMIT; on line 10 and a BEGIN; on a line following that, you should be all right. 2011-12-14T09:57:57 * Dyrcona thinks we should do that for the alpha2 upgrade script. 2011-12-14T09:58:19 *** pmplett has joined #evergreen 2011-12-14T09:59:17 *** kmlussier has joined #evergreen 2011-12-14T10:02:53 Dyrcona: Did that and same error. I'm debating on if I should change the names of the 2nd set of functions slightly to accommodate. What do you think? 2011-12-14T10:03:15 No. Don't change the function names. 2011-12-14T10:05:03 evergreen.upgrade_list_applied_deprecates(TEXT); != evergreen.upgrade_list_applied_deprecated 2011-12-14T10:05:20 * csharp wonders if that's a typo in line 10 2011-12-14T10:05:23 csharp: typo in the script, then? 2011-12-14T10:06:38 no - maybe not 2011-12-14T10:07:42 two different functions: http://pastebin.com/arsB0K92 2011-12-14T10:08:39 naming_two_distinct_functions_almost_identically-- 2011-12-14T10:11:35 *** dbs has joined #evergreen 2011-12-14T10:11:46 dropping_a_previously_applied_upgrade_and_reapplying_it-- 2011-12-14T10:12:36 perhaps a "DROP FUNCTION evergreen.upgrade_list_applied_deprecated(TEXT);" should be added 2011-12-14T10:14:10 shopkins: I pushed a fix for that to a branch / bug that has not yet been applied, I believe 2011-12-14T10:14:10 shopkins: I suggest you clone the latest master from git and install that. You can then run any missing upgrade scripts on your system manually and avoid this confusion in the 2.1.1-2.2alpha1 upgrade script. 2011-12-14T10:14:43 dbs: I was looking for that earlier but didn't see it in the commit log for master, so didn't mention it. 2011-12-14T10:15:09 Dyrcona: because nobody has pushed it to master 2011-12-14T10:15:16 https://bugs.launchpad.net/evergreen/+bug/896405 2011-12-14T10:15:27 dbs: Yep. I can't so.... :) 2011-12-14T10:15:32 *** tspindler has joined #evergreen 2011-12-14T10:15:43 Dyrcona: as noted in previous meetings, if you sign off on it it can be applied 2011-12-14T10:15:47 Dyrcona/dbs: thanks will do. 2011-12-14T10:16:26 dbs: I wouldn't exactly feel right signing off on something that I didn't at least try to test. 2011-12-14T10:16:41 Dyrcona: well, obviously :) 2011-12-14T10:17:15 Dyrcona: that's how some of your collaboration with csharp has been committed, for example; you and csharp signed off on each other's commits (attesting that you've reviewed each other's work), so I just pushed it 2011-12-14T10:17:25 (I think it was you and csharp, anyway) 2011-12-14T10:17:53 dbs: yes, but csharp was testing my code, and I checked that he fixed a typo in a comment, so I'm ok with that. 2011-12-14T10:18:14 Dyrcona: Jeez, man. That's what I'm saying 2011-12-14T10:18:17 dbs: changes to code that gets executed, i feel that I should at least execute the code. 2011-12-14T10:18:20 ok. 2011-12-14T10:18:22 dbs: re your thoughts/concerns on indb unapi and subobject paging granularity: working/collab/miker/unapi2_subobject_improvement 2011-12-14T10:18:44 eeevil: cool, does that replace / incorporate user/dbs/in-db-unapi-circ-due-date ? 2011-12-14T10:19:24 dbs: I thought that was in master already? if not, it's just in parallel 2011-12-14T10:19:31 And do we have any performance testing to allay the concerns expressed by berick re: XML wrapped in JSON wrapped in XML wrapped in an enigma? :) 2011-12-14T10:19:47 eeevil: no, my branches tend to just sit there quietly rotting away :) 2011-12-14T10:19:58 https://bugs.launchpad.net/evergreen/+bug/901976 2011-12-14T10:20:17 dbs: the throughput of Enigma machines is terrible -- surely eeevil isn't using those as wrappers ;) 2011-12-14T10:20:27 pl/enigma 2011-12-14T10:21:17 dbs: my concerns weren't really about performance 2011-12-14T10:21:40 more about general ugh-ness layers of packaging 2011-12-14T10:21:54 dbs: the paging control in that branch helps address speed conserns 2011-12-14T10:22:00 s/layers/at the layers/ 2011-12-14T10:22:30 berick: there is no spoon! (I ignore the wire layer ;) ) 2011-12-14T10:23:22 dbs: i did some performance experiments early on and found unapi to be performant, particularly as more and more data is added, thus leveling the field some 2011-12-14T10:23:35 eeevil: yeah, fair enough 2011-12-14T10:25:14 eeevil: holy crap man, that branch looks like a rewrite, not an iteration 2011-12-14T10:25:27 *** kmlussier has quit IRC 2011-12-14T10:26:34 perhaps an in-db xml2json converter for marcxml, and then json output of the non-marc stuff, would be more performant ... even going as far as using FM objects (though hashes would be more portable) ... but it makes my spidy senses tingle 2011-12-14T10:26:38 berick: okay, good - thanks for the note on performance; I found it okay on our test server with a copy of our production data, which is one of the reasons I was pushing towards unapi in record details, but our system only has a handful of copies per bib 2011-12-14T10:26:55 marcjson! 2011-12-14T10:27:07 dbs: ha! nah, just changing the limit and offset params to hstores, really 2011-12-14T10:27:21 * dbs relearns how to tell "git diff" to ignore whitespace 2011-12-14T10:27:24 right, the biggest performance now is effective paging, etc., which is getting fixed, it looks like 2011-12-14T10:28:10 * berick just starts leaving words and phrases out when typing 2011-12-14T10:28:19 who needs complete thoughts 2011-12-14T10:28:21 git diff -b -w 2011-12-14T10:28:35 okay, that's less scary :) 2011-12-14T10:28:40 and I encourage anyone interested to take a close look at OILS::U::TagURI ... parser/generator that could be wrapped in a json_query builder fairly easily 2011-12-14T10:32:07 grabbing ... 0657 2011-12-14T10:33:31 okay - so the limit and offset params can now specify which sub-objects to limit/offset? 2011-12-14T10:37:04 dbs: correct, sir 2011-12-14T10:38:42 eeevil: so - would you be willing to merge user/dbs/in-db-unapi-circ-due-date and then rebase your branch against that (which I would then test and merge)? 2011-12-14T10:38:57 dbs: ab-so-lutely 2011-12-14T10:39:26 dbs: it's a collab branch, of course, so you could ... but I'm on it now! 2011-12-14T10:39:40 sweet. Then after that, I'll rebase https://bugs.launchpad.net/evergreen/+bug/900820 2011-12-14T10:40:51 dbs: last 2 commits in that branch, correct? 2011-12-14T10:42:16 dbs: also, should we include more than due_date? 2011-12-14T10:42:52 eeevil: you could avoid the last commit in that branch (touching TPAC) until we get the physical_loc sorting support in place 2011-12-14T10:43:01 and circ to be the top object, with copy, etc below it if requested? 2011-12-14T10:43:24 eeevil: maybe, the idea was simply to make available whatever record details in TPAC was currently showing 2011-12-14T10:44:09 * dbs is trying to iterate based on current needs, but there will undoubtedly be future needs for more 2011-12-14T10:44:21 gotcha ... adding later is fine, I'll leave it mostly unmolested. however, with your blessing, I'll add the full gammut of params to avoid having to change the api (again) later. eh? 2011-12-14T10:45:21 Sure. Again, it wasn't clear to me that there was any need for the full-on set of function params, so I was trying to keep things simple 2011-12-14T10:45:35 totally understood 2011-12-14T10:46:47 * dbs is going to test and hopefully push https://bugs.launchpad.net/evergreen/+bug/903383 (offsets for record details) 2011-12-14T10:48:03 *** shopkins has quit IRC 2011-12-14T10:49:21 or maybe not, as I have to add a github repo and trace down the commit to find out if it has a sign-off 2011-12-14T10:50:25 *** kmlussier has joined #evergreen 2011-12-14T10:50:26 bah 2011-12-14T10:52:35 dbs: I want to use includes instead of forcing circ to always be included. ok? 2011-12-14T10:53:48 Sure 2011-12-14T10:54:22 and one more thing ... can I call the element current_circ? 2011-12-14T10:54:27 *** kmlussier has quit IRC 2011-12-14T10:55:19 If you like 2011-12-14T10:56:00 meh ... well, no. 2011-12-14T10:56:17 you'll see ... more typing here than to jsut show you ;) 2011-12-14T10:56:25 and hopefully less typos 2011-12-14T10:57:17 * dbs had largely been thinking of unapi as a way of getting public info about bres/acns/acnss/acnps/acps/circs, thus wasn't aiming for attributes like current usr or past circs 2011-12-14T10:57:39 that's downt the road, after inventing some authen/authz thing 2011-12-14T10:57:49 if it happens 2011-12-14T10:58:31 Right. I was aiming for what we need now, because of that "if", and refactoring along the way if real needs arise 2011-12-14T10:58:44 but your direction sounds solid, for sure 2011-12-14T11:01:07 * Dyrcona updated https://bugs.launchpad.net/evergreen/+bug/903383 with a request for Bill. 2011-12-14T11:07:30 Dyrcona: yeah, I beat you to that by 6 minutes 2011-12-14T11:07:53 * dbs disbelieves the "standing DCO" 2011-12-14T11:08:38 There's absolutely no reason for that given git sign-offs. 2011-12-14T11:09:57 In our "submitting code" instructions we state "For all significant code contributions, please use git's sign-off feature to assert that the code you are submitting is in accordance with the Developer Certificate of Origin (DCO) 1.1" 2011-12-14T11:10:05 There's no reason to include a copy of the DCO 2011-12-14T11:10:07 There are legal reasons for it. Remember a little company named SCO? 2011-12-14T11:10:53 Dyrcona: Yes. And our advice from the SFLC via SFC was to use the sign-off 2011-12-14T11:11:38 Which is why our "submitting code" instructions request that people use git sign-off to assert that the code they are submitting is in accordance with the DCO. 2011-12-14T11:16:30 * Dyrcona signs out to break his workstation with apt-get dist-upgrade. 2011-12-14T11:16:35 *** Dyrcona has quit IRC 2011-12-14T11:18:31 dbs: collab/miker/unapi2_subobject_improvement updated 2011-12-14T11:18:37 biab 2011-12-14T11:29:41 dbs: In looking at your 902276 branch I note that a located URI with the CONS and SYS1 locations appears to show up twice in the TPac when logged in at BR1. Heh. 2011-12-14T11:32:06 tsbere: Double your pleasure! I think that data set could stand to be improved - maybe s/CONS/SYS2/ in that case 2011-12-14T11:32:26 and separate the links out into distinct links 2011-12-14T11:34:22 dbs: I dunno. May be a good test, if we call "showing the same located URI twice because it is located twice in our tree" a bug. 2011-12-14T11:34:52 tsbere: I could buy that, too 2011-12-14T11:35:49 dbs: I did throw a comment on the bug, though, questioning the > 1 lines. 2011-12-14T11:43:25 tsbere: does it show two lines in JSPAC in the same circumstances? 2011-12-14T11:43:27 *** rjackson-isl_ has joined #evergreen 2011-12-14T11:44:34 dbs: Nope. That record I only get the non-located one and a single located one (I assume....I should edit the marc record to make them distinct) 2011-12-14T11:44:53 heh 2011-12-14T11:45:22 it might be the case that you're seeing two located URIs, I thought that the logic was such that it would show located URIs if there were any, and if not, then show non-located URIs 2011-12-14T11:45:50 Hello all - quick question for community: Just installed 2.1 and one site only is receiving error "Form is invalid. Please edit and try again." when attempting to register new patrons 2011-12-14T11:46:04 Have tried to have the staff clilent re-installed with no luck resolving? 2011-12-14T11:46:16 dbs: Nope, changed them to be distinct. TPac I get Two Bs and an A (in that order), but JSPac I get one A and one B. 2011-12-14T11:46:29 rjackson-isl_: could it be a required survey local to that site? 2011-12-14T11:47:16 sorry - how to I verify? 2011-12-14T11:47:20 rjackson-isl_: I notice that our consortium-wide voter registration survey is required, but doesn't appear to be required (and stops you from saving unless you answer) 2011-12-14T11:47:42 csharp: I tried *fixing* that once. The patch file was ignored. :( 2011-12-14T11:47:52 ok - will check that out - thanks csharp 2011-12-14T11:48:07 rjackson-isl_: Admin -> Local Administration -> Surveys 2011-12-14T11:48:22 roger that! 2011-12-14T11:49:00 *** granitize has joined #evergreen 2011-12-14T11:50:01 *** granitize has quit IRC 2011-12-14T11:50:10 *** granitize has joined #evergreen 2011-12-14T11:51:02 *** granitize has left #evergreen 2011-12-14T11:51:59 dbs: For the record, I was looking at what became record #99 in my dev machine 2011-12-14T12:00:10 tsbere: cool, thanks! 2011-12-14T12:01:10 good point on > 1; I intended to type > -1 2011-12-14T12:15:23 no go on the Surveys - they also receive same error when attempting to clone a patron 2011-12-14T12:16:28 *** StephenGWills has joined #evergreen 2011-12-14T12:23:31 *** StephenGWills has quit IRC 2011-12-14T12:28:56 *** granitize has joined #evergreen 2011-12-14T12:30:21 dbs: thx for the pointers to those marc records, now I can do check-outs 2011-12-14T12:30:36 yay! 2011-12-14T12:30:38 My triggers are not functioning, but that is another story 2011-12-14T12:33:09 edoceo: are you Elliot Voris? 2011-12-14T12:33:22 I am David Busby 2011-12-14T12:33:50 heh, okay - timing was interesting with a mailing list message arriving on a similar front 2011-12-14T12:34:02 * dbs will respond to the list 2011-12-14T12:35:50 Yea, I see that, watched that thread, which was helpful to me, I had messed with those import scripts 2011-12-14T12:37:26 When I do some activity which I think should trigger events, where are these data written to, should I see some new records in the tables in the action or action_trigger schema? 2011-12-14T12:46:57 bshum++ #youarenotasnowflake tag 2011-12-14T12:50:56 edoceo: depends on the trigger 2011-12-14T12:51:25 some update the record in-place (maintain_control_numbers), others generate new rows in other tables (indexing) 2011-12-14T12:51:38 I have a new one I made: hook=checkout, enabled=true, delay=5:00 (5 min?) context_field = circ.create_time 2011-12-14T12:51:51 Oh, that kind of trigger! 2011-12-14T12:52:04 drp, yea - not in the SQL, in the Evergreen 2011-12-14T12:52:14 Oh, is Action Trigger - right? 2011-12-14T12:52:45 I am thinking my terminology for OpenILS/Evergreen is not quite on par 2011-12-14T12:53:01 i'm just wondering, why are metabib.keyword_field_entry.value values not normalized? 2011-12-14T12:53:16 tsbere: :) 2011-12-14T12:55:37 *** copystar has quit IRC 2011-12-14T13:00:35 *** kmlussier has joined #evergreen 2011-12-14T13:12:07 * tsbere looks at an email that he has been not looking at, re-reads it a few times, and gets to the conclusion "The login page works when we use it, but when we bypass it things don't work" 2011-12-14T13:15:10 jamesrf: context? 2011-12-14T13:18:35 jamesrf: config.metabib_field_index_norm_map says that "NACO Normalize" and "Normalize date range" should be applied to keyword:keyword 2011-12-14T13:18:53 yes they are applied to the index_vecotr but not the value 2011-12-14T13:19:01 the context is the relevancy bumps 2011-12-14T13:19:17 i know CD is around now but we find it's not quite powerful enough 2011-12-14T13:19:35 the relevancy bumps do a naco_normalize() on each row of the search results which slows it down a lot 2011-12-14T13:20:11 jamesrf: have you updated the cost of naco_normalize() to be something like 10 rather than 100? 2011-12-14T13:20:17 might result in a different plan 2011-12-14T13:22:18 * dbs looks at https://bugs.launchpad.net/evergreen/+bug/844374 as context 2011-12-14T13:25:07 * dbs was thinking about https://bugs.launchpad.net/evergreen/+bug/874603 re function cost, might not be relevant (hah) 2011-12-14T13:41:02 no i'll try that 2011-12-14T13:43:43 jamesrf: I'll look at that in a bit (that, being, applying negative-id'd normalizers to the value ... IIRC, it should be) 2011-12-14T13:44:23 hey dbwells: "Use of qw(...) as parentheses is deprecated at /usr/local/share/perl5/Library/CallNumber/LC.pm line 62" - just a heads-up 2011-12-14T13:44:52 eeevil: dang: psql:990.schema.unapi.sql:984: ERROR: argument of CASE/WHEN must be type boolean, not type text 2011-12-14T13:44:58 * dbs will poke 2011-12-14T13:45:07 dbs: thank you, I'll get it corrected. 2011-12-14T13:45:48 dbwells: yeah, just popped out while creating a fresh evergreen schema 2011-12-14T13:46:36 eeevil: i gather that should be $9 :) 2011-12-14T13:50:36 pushed 2011-12-14T13:58:10 eeevil: next: http://paste.lisp.org/display/126492 2011-12-14T13:59:09 I guess TPAC needs to be taught to pass the hstore parms 2011-12-14T14:02:55 * tsbere dislikes getting errors in the staff client seemingly unrelated to what he is looking to test 2011-12-14T14:04:18 dbs: For the records added by 902276, is the bug that they don't get a bib source, or that there are parts of the client (in particular, holdings maintenance) that assume that bibs have a source? 2011-12-14T14:04:49 tsbere: could be related to the changes that I committed for Dyrcona, I suppose 2011-12-14T14:05:00 * dbs wonders what bug tsbere is seeing, exactly 2011-12-14T14:05:29 I am under the assumption that this is "disallow volumes on sources" related code. All 100 test bibs have no source, so the source object is coming back as null... 2011-12-14T14:06:09 Just trying to determine if I should be tacking this info onto the existing bug, or filing a new one ;) 2011-12-14T14:07:03 New one 2011-12-14T14:07:11 Bibs don't need to have sources 2011-12-14T14:08:17 * dbs notes that he saw no errors surface while testing with xulrunner 3.2.17 2011-12-14T14:08:50 dbs: I loaded the 100 test bibs, then loaded one up in the staff client and went to holdings maintenance. At that point I got a cbsObj is null error. 2011-12-14T14:10:22 tsbere: ah, okay. I see that 2011-12-14T14:10:35 oddly, the dialog immediately disappears 2011-12-14T14:10:54 New bug, or reopen Dyrcona's bug I guess 2011-12-14T14:11:17 * tsbere will finish his testing first 2011-12-14T14:13:17 easy enough to wrap those uses methinks 2011-12-14T14:14:47 *** kmlussier has quit IRC 2011-12-14T14:16:13 dbs: Different note, pushed https://bugs.launchpad.net/evergreen/+bug/900820 - You mention needing a rebase elsewhere in a comment there? 2011-12-14T14:18:25 *** rangi has quit IRC 2011-12-14T14:18:25 *** rangi has joined #evergreen 2011-12-14T14:18:56 *** wolf29 has quit IRC 2011-12-14T14:20:40 *** akilsdonk has joined #evergreen 2011-12-14T14:21:10 tsbere: thanks for the heads-up - it's related to what eeevil and I are working on now IIRC (in-db-unapi-circ stuff), so good timing - and thanks 2011-12-14T14:21:59 * dbs is off to a meeting, alas 2011-12-14T14:22:01 dbs: Found the bug when I went to *add* prefix/suffix information to call numbers to test them showing up 2011-12-14T14:22:08 hah 2011-12-14T14:22:52 * dbs tried a quick "if (typeof cbsObj != 'undefined')" test in bib_brief and copy_browser but probably has conflicting version of the staff client installed; will test later 2011-12-14T14:23:08 * tsbere is working on a branch, about to test it 2011-12-14T14:26:00 *** kmlussier has joined #evergreen 2011-12-14T14:27:18 *** dbs has quit IRC 2011-12-14T14:29:21 FYI, folks, the Reports Taskforce meeting will begin in a couple of minutes! 2011-12-14T14:31:39 Ok, let's get the meeting started. The agenda is posted: http://open-ils.org/dokuwiki/doku.php?id=evergreen-reports:meetings:2011-12-14-agenda 2011-12-14T14:32:15 Let's start with introductions - and if someone would like to volunteer to compile minutes, it would be much appreciated 2011-12-14T14:32:39 * jenny is Jenny Turner, PALS 2011-12-14T14:33:28 * bshum is Ben Shum, Bibliomation 2011-12-14T14:33:33 (sorta) 2011-12-14T14:35:53 * bshum listens for the crickets 2011-12-14T14:35:55 bshum: If it is only (sorta) you and me, shall we cancel and wait until Dec? 2011-12-14T14:36:04 I mean Jan 2011-12-14T14:36:05 January, sure :) 2011-12-14T14:36:06 oye 2011-12-14T14:36:27 I won't be here in early January, but I'll keep my eyes open. 2011-12-14T14:36:38 im here, but have nothing useful :) 2011-12-14T14:36:59 Sounds good - I thinkthe Jan date is the 11th 2011-12-14T14:37:53 \me is Tim Spindler, C/W MARS 2011-12-14T14:38:07 Ok: reports taskforce meeting is officially cancelled for Dec! Jan. 11 it is. 2011-12-14T14:38:24 well guess i didn't miss anything ;) 2011-12-14T14:38:47 Just the crickets 2011-12-14T14:38:50 best meeting ever! 2011-12-14T14:38:51 :) 2011-12-14T14:39:03 * rangi hopes his 2 today are that fast 2011-12-14T14:42:19 rangi++ 2011-12-14T14:42:21 jenny++ #shortest Evergreen meeting yet 2011-12-14T14:42:27 jenny++ 2011-12-14T14:42:40 8 minutes, former record held by July 8 Community Meeting (14ish minutes) 2011-12-14T14:42:53 * jenny curtsies 2011-12-14T14:49:32 heh 2011-12-14T14:49:35 short_meetings++ 2011-12-14T14:53:33 * berick tries to think of a way to detect a hold whose pickup_lib changed while on the hold shelf (without adding another field) 2011-12-14T14:53:34 on the fairfax team (where i used to work, furthering rupert murdochs hold on the world media .. jesus i was evil (nz song, look it up)) we used to do stand up meetings 2011-12-14T14:53:49 and if you talked longer then 2 mins, you had to stand on one leg 2011-12-14T14:53:53 worked well :) 2011-12-14T14:53:59 best i can tell, they look just like any other in-tranit hold 2011-12-14T14:54:18 rangi++ 2011-12-14T14:56:11 berick: I find myself wondering why you need to detect that right now. <_< 2011-12-14T14:56:34 berick: Can envision a world where that information would be useful. 2011-12-14T14:56:41 *I can 2011-12-14T14:56:50 http://www.youtube.com/watch?v=eKX8ntjWeas 2011-12-14T14:57:02 and now i will stop distracting you all, and do some work myself 2011-12-14T14:58:18 *** Dyrcona has joined #evergreen 2011-12-14T15:00:06 git++ 2011-12-14T15:00:25 As I cherry-pick changes across the great perl lib boundary and git figures it out 2011-12-14T15:01:24 tsbere: so staff can pull the items from the shelf and (physically) put them into transit to the new pickup_lib 2011-12-14T15:01:38 * berick can't tell if tsbere is being sarcastic 2011-12-14T15:03:05 berick: I probably should have figured that out, as I was talking about having cherry-picked changes to Open-ILS/src/perlmods/lib/OpenILS/Application/Circ/Holds.pm in master to Open-ILS/src/perlmods/OpenILS/Application/Circ/Holds.pm in rel_2_0 ... In regards to 903896, clearing the shelf and shelf expire times when changing pickup libraries. 2011-12-14T15:06:07 *** kmlussier has quit IRC 2011-12-14T15:06:38 tsbere: ironically, that bug fix makes what I want to do now more difficult ;) 2011-12-14T15:07:05 heh 2011-12-14T15:08:42 *** kmlussier has joined #evergreen 2011-12-14T15:18:07 berick: Well, there are several options I can think of. One is to add another OU link to the hold, a second is to add another OU link to transits (or hold transits), a third is to make a lot of things potentially easier down the road and add a "last on any kind of shelf at X" field to copies........ 2011-12-14T15:18:39 berick: And the craziest I can think of is "turn on auditing for holds and run a horribly complicated query involving hold and copy auditors to figure it out" 2011-12-14T15:25:29 yeah, those are along the lines of what I was thinking 2011-12-14T15:26:02 there is an interesting field on the transit called prev_dest, which is only used when a hold changes pickup_lib's mid-transit 2011-12-14T15:26:41 Really? 2011-12-14T15:26:45 trying to think if it would be an abuse to re-use that 2011-12-14T15:27:34 * tsbere finds it scary, then, that there are over 200 instances of that not being null in the production DB here 2011-12-14T15:28:17 hmm, yeah, using that for this purpose would be an abuse, i think 2011-12-14T15:28:54 so, another ou on the hold (prev_shelf_lib ?) is next on my list 2011-12-14T15:29:22 current_shelf_lib - as in where it is currently on the shelf? 2011-12-14T15:29:27 Clear it when the checkin happens? 2011-12-14T15:33:39 hmm, calling it "current", but having it go away while the copy is on the shelf seems unintuitive to me. i like "prev" because it doesn't tell you where the copy is, just where it was 2011-12-14T15:35:07 I was thinking "whenever we set shelf time, set current shelf lib, then clear it at checkin at the wrong library" 2011-12-14T15:35:22 Pre-existing transit or no 2011-12-14T15:35:43 * tsbere goes home, can chime in again in a few 2011-12-14T15:35:48 k 2011-12-14T15:37:52 i think we may be trying to solve a different problem. will re-state for reference. 2011-12-14T15:41:31 item is on shelf at A. hold pickup lib is changed to B (and put into hold-transit under the covers). i need a way to detect such items are still sitting on the shelf at A, so I can physically put them into transit. 2011-12-14T15:47:28 following prev_shelf_lib to its conclusion, when the pickup_lib is changed, prev_shelf_lib would get set to A. then, regardless of where the copy is now (still on the shelf at A, in transit, on the shelf at B), we'd know it was previously on A's shelf 2011-12-14T15:47:44 that could be useful info in its own right, but would also allow us to find these copies 2011-12-14T15:47:57 * berick needs to take this to LP... sorry for the rambling 2011-12-14T15:48:02 Does anyone have any suggestions or metric for provisioning necessary hardware specs to support SIP services being run off the box? 2011-12-14T15:48:25 We've got some old boxes that we're trying to re-task, but not sure how best to determine their suitability, other than trying them in the field. 2011-12-14T15:48:57 bshum: number of sip clients is the most important piece of info. 2011-12-14T15:49:11 each client will maintain a persistent tcp connection 2011-12-14T15:49:18 well, most will 2011-12-14T15:50:41 *** akilsdonk has quit IRC 2011-12-14T15:51:22 berick: I think we've been keeping a relatively low number of persistent connections. 2011-12-14T15:51:29 If the load balancer printout is to be believed. 2011-12-14T15:51:38 Like around 20 or so 2011-12-14T15:53:30 *** plux has quit IRC 2011-12-14T15:54:21 * Dyrcona definitely broke stuff earlier. 2011-12-14T15:54:40 * Dyrcona can't rely on the git working directories on his workstation any longer. 2011-12-14T15:54:52 bshum: it would not take much hardware to support 20 sip clients, assuming they are not blasting the server 2011-12-14T15:55:27 *** csharp has quit IRC 2011-12-14T15:56:01 berick: By "blasting" I assume you mean like if the SIP client were some machine doing alot of checkins/checkouts (like something RFID related or an AMH) 2011-12-14T15:56:22 berick: But that's somewhat comforting. 2011-12-14T15:56:27 *** tspindler has quit IRC 2011-12-14T15:56:42 tsbere++ # beaucoup merging 2011-12-14T15:57:05 *** granitize has quit IRC 2011-12-14T15:57:07 bshum: right, was thinking AMH 2011-12-14T15:57:28 *** bwicksall has quit IRC 2011-12-14T15:57:30 berick: Yeah we don't have any of those here (yet). 2011-12-14T15:58:16 I think the vast majority of the SIP clients are just doing simple patron authentication. 2011-12-14T15:58:26 *** Meliss has quit IRC 2011-12-14T15:58:42 berick: For the record, my problem with "was last on the hold shelf at...." is determining "when do we *stop* telling them to grab it and put it in transit?". "Currently on the hold shelf at..." and clearing that when they *do* grab it solves that. 2011-12-14T15:59:47 *** kmlussier has quit IRC 2011-12-14T16:00:38 tsbere: you make a good point.. 2011-12-14T16:00:55 berick: The server we were looking at putting into use only has 2-core processor with 2GB of RAM. But since we don't have exact metrics for determining usage, that's what sparked my question. 2011-12-14T16:01:28 this raises another question... should changing the pickup_lib put the item into transit (which it does now) or simply indicate (somehow) the item needs to be pulled and checked in for further processing 2011-12-14T16:01:43 since, well, it's not /really/ in transit yet 2011-12-14T16:02:40 bshum: the other question is whether you intend to run EG on the sip server or simply have the SIP server pass requests off to an existing eg cluster. 2011-12-14T16:02:54 berick: Putting it into transit solves a lot of other problems (like it saying it is available, being in status 8, when it isn't anymore). Unless we want to change every "is the copy in status 8" to "is the copy in status 8 AND is currently on the shelf at the pickup library", anyway. 2011-12-14T16:03:20 berick: That's an interesting thought that I hadn't considered. Normally we've installed the full Evergreen stack on each SIP server to work on its own. 2011-12-14T16:04:15 berick: Also, the "currently on the shelf at..." could help solve a problem where a hold's pickup library is changed, then the hold is canceled before it is taken off the shelf. No longer relying on the pickup library for showing the canceled hold that is still on the original pickup library's shelf and all. 2011-12-14T16:04:34 (although the item being "in transit" at that point makes it not show up, not being in status 8.....arguments for and against that, apparently) 2011-12-14T16:05:48 berick: Assuming that's somehow controlled with the oils_sip.xml file pointing at a given opensrf_core.xml file to tell it who to talk with? 2011-12-14T16:06:33 bshum: We install a partial evergreen stack onto our SIP server. No apache chunks, no staff client chunk, etc. 2011-12-14T16:06:38 tsbere: would current_shelf_lib be cleared the moment the pickup lib changed? 2011-12-14T16:07:07 berick: No, it would only be cleared by the checkin code seeing the copy go by. 2011-12-14T16:07:08 bshum: currect 2011-12-14T16:07:10 er, correct 2011-12-14T16:07:26 *** bwicksall has joined #evergreen 2011-12-14T16:07:50 I'll have to ponder that a bit. Currently we run SIP directly pointing at the bricks, but we've found that hampers our ability to rotate bricks around without disrupting SIP services. 2011-12-14T16:07:58 tsbere: but if you are checking it in at the new pickup_lib, wouldn't you want the current_shelf_lib to be updated to the new lib at checkin time (and not cleared)? 2011-12-14T16:08:16 bshum: right, that is a problem w/ blending them like that 2011-12-14T16:08:43 berick: *set* current_shelf_lib when you set shelf_time. *clear* current_shelf_lib if checked in at anywhere that isn't the pickup library (to indicate it was taken off the shelf after the pickup library changed). 2011-12-14T16:08:57 berick: We were contemplating that having distinct servers doing their own Evergreen services + SIP would help with that a bit. So that way if we have to do something brick-wise, it wouldn't necessarily bring down SIP 2011-12-14T16:09:25 berick: Or maybe "clear when we see the copy go by without a shelf time" 2011-12-14T16:09:31 berick: Cause then if we only did a partial stack, wherever they're pointing would become a single point of failure for the SIP servers? 2011-12-14T16:09:32 tsbere: ah, see that's the problem. for the problem I'm trying to solve, the copy is never checked in at anywher that isn't the pickup li 2011-12-14T16:09:35 b 2011-12-14T16:09:57 berick: For workflows here, the copy would pass through a checkin window to get a physical slip printed 2011-12-14T16:10:20 but how do you know to pull it off the shelf and check it in? 2011-12-14T16:10:56 Well, ideally, it was on a pull list, and not already on the shelf for pickup. 2011-12-14T16:11:14 But this entire discussion is dealing with something that doesn't happen in ideal situations. 2011-12-14T16:11:21 right, the already on the shelf for pickup is the problem i'm trying to soelf 2011-12-14T16:11:46 it's a supported work flow, though, not an anomaly 2011-12-14T16:12:16 At the moment I don't think we give libraries the ability to change the pickup library once the items are on the shelf. Makes me wonder how we got over 200 prev dest entries in our database as a result. 2011-12-14T16:12:49 * berick guesses admin did it ;) 2011-12-14T16:12:58 Oh, wait, I typoed one of my permission names. We do give them the ability to change when it is in transit......... 2011-12-14T16:13:02 i get the sense not a lot of people use it 2011-12-14T16:13:04 but not once it gets there 2011-12-14T16:13:44 Due to there being no interface for pulling the copy from the hold shelf we want a bit more mediation. As in, someone has to tell the library it is at to grab it from the shelf. 2011-12-14T16:14:52 berick: A thought, putting the "currently on the hold shelf at" on the *copy*, instead of on the *hold*, would support showing copies that are on a hold shelf after the hold was canceled and then uncanceled or otherwise forcibly retargeted....... 2011-12-14T16:15:46 *** dbs has joined #evergreen 2011-12-14T16:16:08 * dbs enjoys setting a bib to a source that can't have copies after it already has copies 2011-12-14T16:16:59 *** kmlussier has joined #evergreen 2011-12-14T16:25:46 tsbere: thinking about that... (/me really would like to avoid a new copy column if possible) 2011-12-14T16:27:17 new table/relation for copies to indicate their on-some-special-shelf status with an on/off timestamp, etc? 2011-12-14T16:27:44 maybe crazy, but it could support some things that are more difficult now, like "how long do things sit on the hold shelf, on average" 2011-12-14T16:27:57 (actually, that might be easy now, having just said that) 2011-12-14T16:28:51 berick: Thanks for your suggestions about SIP servers. Gave me an idea about how we are currently weighting SIP servers with our load balancers. 2011-12-14T16:28:56 berick++ 2011-12-14T16:29:04 it could also prove useful for "this is on the $DEPARTMENT problem shelf at $LIB", and be another step toward eliminating circ-to-pseudo-patron as a means of tracking where items are internally. 2011-12-14T16:29:30 random, half-baked thought. throwing it out there and walking away from my desk for a few. :-) 2011-12-14T16:30:17 half_baked_things_stewing++ 2011-12-14T16:38:11 *** dbs has quit IRC 2011-12-14T16:46:07 *** edoceo has quit IRC 2011-12-14T16:50:16 along those same lines, a new "probably in transit" status ;) 2011-12-14T16:53:55 "transit desired" 2011-12-14T16:55:37 *** granitize has joined #evergreen 2011-12-14T16:56:11 *** Shae has quit IRC 2011-12-14T16:58:26 *** edoceo has joined #evergreen 2011-12-14T17:15:31 *** kmlussier has quit IRC 2011-12-14T17:26:31 *** csharp has joined #evergreen 2011-12-14T17:27:21 *** csharp has left #evergreen 2011-12-14T17:31:59 *** csharp has joined #evergreen 2011-12-14T17:34:56 *** adbowling-isl has quit IRC 2011-12-14T17:45:11 *** jenny has left #evergreen 2011-12-14T17:48:46 *** alynn26 has left #evergreen 2011-12-14T18:16:35 *** granitize has quit IRC 2011-12-14T18:16:49 *** granitize has joined #evergreen 2011-12-14T19:04:42 *** tildeequals has joined #evergreen 2011-12-14T19:05:03 *** tildeequals has quit IRC 2011-12-14T19:18:57 *** granitize has quit IRC 2011-12-14T19:42:25 *** pmplett has quit IRC 2011-12-14T21:05:47 *** Dyrcona has quit IRC 2011-12-14T21:17:38 *** timhome has joined #evergreen 2011-12-14T21:26:07 *** timhome has quit IRC 2011-12-14T22:44:00 *** dbs has joined #evergreen 2011-12-14T22:44:00 *** dbs has joined #evergreen 2011-12-14T23:48:17 *** dbs has quit IRC