2011-09-06T00:20:07 phasefx i am downloading prepacked version from evergreen site available for download 2011-09-06T00:44:09 evergreen-setup-rel_2_0_9_2.exe 2011-09-06T00:57:12 i have installed the evergreen client 2.0.9 it registers and gives error Error in props2object in message catalog in bindings.xml: Internalerror: allocation size overflow I have installed it from the evergreen site download link it was the pre-packed installer evergreen-setup-rel_2_0_9_2.exe 2011-09-06T00:58:43 i have installed the evergreen client 2.0.9 it registers and gives error "Error in props2object in message catalog in bindings.xml: Internalerror: allocation size overflow" I have installed it from the evergreen site download link it was the pre-packed installer evergreen-setup-rel_2_0_9_2.exe 2011-09-06T01:00:21 *** jamesrf has quit IRC 2011-09-06T01:00:23 i have installed the evergreen client 2.0.9 it registers and gives error "Error in props2object in message catalog in bindings.xml: Internalerror: allocation size overflow" I have installed it from the evergreen site download link it was the pre-packed installer----- evergreen-setup-rel_2_0_9.exe 2011-09-06T01:02:09 *** jamesrf has joined #evergreen 2011-09-06T01:11:49 *** tater has joined #evergreen 2011-09-06T01:11:51 *** mtate has quit IRC 2011-09-06T01:31:14 *** youdonotexist has quit IRC 2011-09-06T01:39:55 Faiz: what language/locale are you selecting with the staff client? en-US? 2011-09-06T02:03:22 hi phasefx Yes english US and windows 7 2011-09-06T02:03:50 i am installing the client evergreen-setup-rel_2_0_9.exe on windows 7 2011-09-06T02:23:31 i have installed the evergreen client 2.0.9 it registers and gives error "Error in props2object in message catalog in bindings.xml: Internalerror: allocation size overflow" I have installed it from the evergreen site download link it was the pre-packed installer----- evergreen-setup-rel_2_0_9.exe on windows 7 with english as language 2011-09-06T02:26:30 Faiz: you should try your client against the 2.0.9 demo server listed here: http://evergreen-ils.org/dokuwiki/doku.php?id=community_servers see if it works for that server 2011-09-06T02:28:33 same error 2011-09-06T02:28:56 i downloaded and installed but same error 2011-09-06T02:31:46 you used the server 75.101.133.94 with the login staff and password demo123? 2011-09-06T02:32:25 no i used that installer 2011-09-06T02:32:38 ok if i use that login it works fine 2011-09-06T02:33:46 it means i have problem in my server 2011-09-06T02:35:39 compare this file, http://75.101.133.94/xul/server/locale/en-US/offline.properties with the one produced by your server 2011-09-06T02:35:58 if identical, try the other .property files in that en-US/ directory 2011-09-06T02:43:22 yeah they are ok 2011-09-06T02:43:44 what do i do with .property file 2011-09-06T02:45:34 i have compared the two files mentioned they are same 2011-09-06T02:47:14 .property files get used by the code that's breaking for you; so if your files are different, or if apache is mangling them in some way when serving them, that could account for the message catalog error 2011-09-06T02:48:32 Faiz: I fear I must get some sleep; but I'll check my scrollback later. If you find any more clues, I suggest sharing them on the mailing list 2011-09-06T02:50:08 ok 2011-09-06T02:51:18 incidentally, I've never seen that error before 2011-09-06T02:56:11 niether did i 2011-09-06T02:56:44 where should i start diging now 2011-09-06T03:46:44 *** artunit_ has joined #evergreen 2011-09-06T03:49:41 *** artunit has quit IRC 2011-09-06T03:49:51 *** artunit_ is now known as artunit 2011-09-06T04:03:37 *** Callender has quit IRC 2011-09-06T04:42:24 *** Faiz has quit IRC 2011-09-06T05:12:29 *** Callender has joined #evergreen 2011-09-06T07:32:13 *** bott-otr has quit IRC 2011-09-06T08:12:29 *** dmoses has joined #evergreen 2011-09-06T08:12:41 *** adbowling-isl has joined #evergreen 2011-09-06T08:18:39 *** sfortin has joined #evergreen 2011-09-06T08:19:35 *** dmoses has quit IRC 2011-09-06T08:29:00 *** AaronZ-PLS has joined #evergreen 2011-09-06T08:34:34 *** Faiz has joined #evergreen 2011-09-06T08:35:07 i have installed the evergreen client 2.0.9 it registers and gives error "Error in props2object in message catalog in bindings.xml: Internalerror: allocation size overflow" I have installed it from the evergreen site download link it was the pre-packed installer----- evergreen-setup-rel_2_0_9.exe on windows 7 with english as language 2011-09-06T08:35:47 i have also chkd the demo server and it resulted that my server end is faulty 2011-09-06T08:45:55 *** Meliss has joined #evergreen 2011-09-06T08:49:17 *** plux has joined #evergreen 2011-09-06T09:09:29 *** natschil has joined #evergreen 2011-09-06T09:11:29 *** natschil has joined #evergreen 2011-09-06T09:16:47 *** natschil has quit IRC 2011-09-06T09:16:50 *** Dyrcona has joined #evergreen 2011-09-06T09:18:04 *** natschil has joined #evergreen 2011-09-06T09:18:13 *** akilsdonk has joined #evergreen 2011-09-06T09:18:41 *** natschil has quit IRC 2011-09-06T09:19:31 *** natschil has joined #evergreen 2011-09-06T09:21:33 *** natschil has joined #evergreen 2011-09-06T09:23:45 *** natschil has joined #evergreen 2011-09-06T09:25:39 *** natschil has quit IRC 2011-09-06T09:26:02 *** natschil has joined #evergreen 2011-09-06T09:26:35 *** natschil has joined #evergreen 2011-09-06T09:27:07 *** jenny1 has joined #evergreen 2011-09-06T09:28:51 *** jamesrf has quit IRC 2011-09-06T09:31:00 *** jamesrf has joined #evergreen 2011-09-06T09:33:00 *** natschil has quit IRC 2011-09-06T09:36:52 *** dbs has joined #evergreen 2011-09-06T09:36:52 *** dbs has joined #evergreen 2011-09-06T09:42:40 *** kmlussier has joined #evergreen 2011-09-06T09:43:51 *** tater has quit IRC 2011-09-06T09:44:06 *** mtate has joined #evergreen 2011-09-06T09:46:52 *** IRCReaderBOT has joined #evergreen 2011-09-06T09:47:48 *** Faiz has quit IRC 2011-09-06T10:08:42 *** collum has joined #evergreen 2011-09-06T10:11:03 *** sal_ has joined #evergreen 2011-09-06T10:27:49 *** gmcharlt has quit IRC 2011-09-06T10:31:25 *** bott-otr has joined #evergreen 2011-09-06T10:34:06 *** kmlussier has quit IRC 2011-09-06T10:34:29 *** kmlussier has joined #evergreen 2011-09-06T10:45:43 *** gmcharlt has joined #evergreen 2011-09-06T10:55:08 *** yboston has joined #evergreen 2011-09-06T10:57:28 *** bott-otr has quit IRC 2011-09-06T11:06:32 *** gdunbar has joined #evergreen 2011-09-06T11:11:56 *** matt_carlson has joined #evergreen 2011-09-06T11:13:43 *** youdonotexist has joined #evergreen 2011-09-06T11:16:55 hmmm 2011-09-06T11:17:18 What happens if I have a reporter datatype of "id' on a field that is not guaranteed to be unique when looking at that single data source? 2011-09-06T11:22:43 tsbere: nothing good (says eeevil) 2011-09-06T11:25:50 * tsbere swaps it to "link" then 2011-09-06T11:26:46 phasefx: huh, can't find the evergreen trademark / logo info on the web site or wiki 2011-09-06T11:27:23 phasefx: specifically, the usage criteria 2011-09-06T11:29:07 hrmm 2011-09-06T11:30:27 I think this is the right end-point: http://www.georgialibraries.org/lib/pines/evergreenlogo/ 2011-09-06T11:31:14 *** collsk12 has joined #evergreen 2011-09-06T11:31:52 phasefx++ 2011-09-06T11:31:59 yeah, search was doing nothing for me 2011-09-06T11:32:22 I think the logo / trademark is being transferred to SFC, but for now I'll link to that 2011-09-06T11:34:02 Is there a pull request meeting today? 2011-09-06T11:34:18 Supposed to be 2011-09-06T11:36:02 dbs: oh man, I so thought that email was spam *8) 2011-09-06T11:36:09 heh 2011-09-06T11:37:47 so the trademark/etc. are being transferred directly to the SFC? I thought we formed some legal entity that itself joined the SFC? 2011-09-06T11:38:19 phasefx: no, SFC is the legal entity 2011-09-06T11:38:44 of which the Evergreen project is a member organization, represented by the Evergreen Oversight Board 2011-09-06T11:38:57 ah, okay 2011-09-06T11:39:25 tells you how mushy my brain is 2011-09-06T11:39:43 So the Evergreen Oversight Board will need to draft some form of logo/trademark guidelines if GPLS transfers the logo/trademark to the SFC 2011-09-06T11:40:22 (probably s/GPLS/SFC under the advisement of the Evergreen Oversight Board/ or whatever) 2011-09-06T11:42:21 * dbs has been very un-devvy for the past few weeks owing to beginning of school deadlines :( 2011-09-06T11:42:32 so much ldap, so little time 2011-09-06T11:46:30 *** collsk12 has joined #evergreen 2011-09-06T11:47:08 *** jrodge01 has joined #evergreen 2011-09-06T11:50:58 Odd question: I recently imported a MARC record into a brand new installation of Evergreen 2.1. After a great deal of struggle, I have the title showing up on the OPAC; however, when I use the "Holdings Maintenance" it still shows the example branches, even though I've already removed them. 2011-09-06T11:51:20 collsk12: have you re-run autogen since deleting them? 2011-09-06T11:51:29 Yes 2011-09-06T11:52:13 have you made sure they don't exist in actor.org_unit? 2011-09-06T11:52:46 SELECT * FROM actor.org_unit WHERE shortname = 'BR-1'; -- that should be a good check 2011-09-06T11:53:02 or maybe it's BR1 2011-09-06T11:53:19 yeah, BR1 2011-09-06T11:53:37 I've checked. Just the ones I've added show up. 2011-09-06T11:53:48 also, the staff client doesn't get its org info from the file autogen produces, but from an opensrf method. may need to restart perl services to eliminate caching 2011-09-06T11:54:08 phasefx: Let me try that. 2011-09-06T11:58:10 Nah, still there. The OPAC searches are also acting strangely. I have to manually select the library I want to search. Otherwise, I just get a spinning mouse cursor with no results. 2011-09-06T11:59:22 sounds kind of like org_unit depths and org_unit_types are mismatched 2011-09-06T11:59:25 may want to sanity check org depths/types and ... 2011-09-06T11:59:56 * dbs also doesn't know if the version of 2.1 collsk12 is running needs cache-generator.sh still 2011-09-06T12:00:03 http://evergreen-ils.org/dokuwiki/doku.php?id=scratchpad:random_magic_spells#finding_mis-matched_depths_with_org_units_and_org_unit_types 2011-09-06T12:04:55 No results came back from the query and it's still showing this record as belonging to SYS2 and circulating in SYS2, yet it's available at CLMC. 2011-09-06T12:05:47 What's cache-generator.sh? 2011-09-06T12:11:46 *** artunit_ has joined #evergreen 2011-09-06T12:12:27 *** matt_carlson has quit IRC 2011-09-06T12:13:19 collsk12: it was a temporary replacement for autogen.sh; you would call "cache-generator.sh -u". we're back to autogen.sh now I think. 2011-09-06T12:13:31 pull requests? or no 2011-09-06T12:13:38 *** artunit has quit IRC 2011-09-06T12:13:53 *** artunit_ is now known as artunit 2011-09-06T12:15:04 dbs: Ah...thanks. There is a cache-generator.sh in bin folder. Should I run it, or is that a bad idea? 2011-09-06T12:15:23 I would try it, just to see. 2011-09-06T12:18:19 I'm having some trouble with the installation. 2011-09-06T12:18:28 dbs: No dice :( 2011-09-06T12:18:57 dbs: I think we should do pull requests. But I dunno if enough people are paying attention to IRC. 2011-09-06T12:19:32 tsbere: I would like to, but the fire being applied to me for LDAP synchonizing here suggests I won't be able to pay attention either 2011-09-06T12:24:27 jrodge01: What kind of trouble are you having? 2011-09-06T12:27:14 collsk12: I just pushed a branch which may fix what you are seeing. It is for 2.0, but I suspect if affects 2.1 as well. Here is the one simple commit: http://git.evergreen-ils.org/?p=working/Evergreen.git;a=commit;h=de74179598ecc00bcf0629382929dfeb9481757e 2011-09-06T12:28:51 dbwells: Now that's service!! :) I'll check it out. Thank you. 2011-09-06T12:30:17 collsk12: Well, it might seem like it, but really just coincidence :) To test, apply the fix, then re-run autogen.sh. You may also need to clear the client cache, not sure. 2011-09-06T12:30:41 OK...thanks again. 2011-09-06T12:31:30 collsk12: I am out for a bit, but will check the scrollback this afternoon to see how it went. 2011-09-06T12:32:03 OK...enjoy. I'll update you in a few. 2011-09-06T12:44:39 collsk12: I have trouble starting OpenSRF. When I do, I get an error with Jabber saying I couldn't authenticate. I can type the error if needed. 2011-09-06T12:45:49 re pull requests, it looks like tomorrow at noon won't conflict with any other community meetings. this being a short week in the US making today feel like monday for some of us, shall I put out a suggestion on -dev to coordinate for that? 2011-09-06T12:46:07 +1 2011-09-06T12:49:28 jrodge01: OK. How far along did you get? Did you register your Jabber users? And, if so, did you modify the conf files to reflect the passwords you registered? 2011-09-06T12:51:09 eeevil: tomorrow works for me. 2011-09-06T12:54:39 collsk12: I believe so. I followed the installation instructions here: http://open-ils.org/dokuwiki/doku.php?id=opensrf:1.6:install 2011-09-06T12:55:04 collsk12: Up until "Starting OpenSRF" 2011-09-06T12:58:10 *** akilsdonk has quit IRC 2011-09-06T12:59:16 collsk12: If you have any advice, please share. I have to step out for a bit, but will check back. If not, I'll go through the installation instructions one more time. 2011-09-06T13:04:25 I would double check your conf files. If they look good, I would "unregister" your users and re-register them. I've had that work for me before. Keep in mind I am not a developer, nor do I play one on tv. 2011-09-06T13:08:57 jrodge01: why are you using the 1.6 install instructions? 2011-09-06T13:09:08 Which version of Evergreen are you planning to run? 2011-09-06T13:10:13 jrodge01: (Not sure how much difference there is, but opensrf is up to version 2.0.1; install directions here: http://open-ils.org/dokuwiki/doku.php?id=opensrf:2.0:install) 2011-09-06T13:27:09 Anyone have opinions on how I did this? http://git.mvlcstaff.org/?p=tsbere/ILS.git;a=shortlog;h=refs/heads/extra_idl 2011-09-06T13:27:40 Well, beyond "apparently should throw some of it further down the file so it doesn't show up as a *core* source" that I am discovering happens. 2011-09-06T13:35:35 dbwells: Applied the fix and re-ran autogen. Restarted the client and all looks good. Thanks for the fix! 2011-09-06T13:45:26 *** jrodge01 has quit IRC 2011-09-06T13:54:33 *** matt_carlson has joined #evergreen 2011-09-06T14:05:16 *** matt_carlson has quit IRC 2011-09-06T14:26:02 *** collsk12 has quit IRC 2011-09-06T14:39:10 *** adbowling-isl has quit IRC 2011-09-06T14:39:52 *** adbowling-isl has joined #evergreen 2011-09-06T14:41:25 *** natschil has joined #evergreen 2011-09-06T14:48:53 tsbere: it shows up as a core source because of reporter:core="true", fwiw 2011-09-06T14:49:10 eeevil: I literally just noticed that and was removing it from my new ones. <_< 2011-09-06T14:49:59 * tsbere is having issues with one of the two new ones, but has at least one more thing to try before trying to dig out errors 2011-09-06T14:51:02 tsbere: I'm not a fan of a magic number when "unknown" (aka NULL) is a reasonable answer ... any reason to coalesce there? 2011-09-06T14:51:33 eeevil: On which piece? 2011-09-06T14:51:33 also, may want to use the all_circulation view to account for aged circs 2011-09-06T14:51:52 the rlc 2011-09-06T14:52:14 sorry, was just looking at the last commit 2011-09-06T14:52:15 and yea, I realized I wasn't using all_circulation. Am more concerned with getting it to work, then I will make that one behave. 2011-09-06T14:53:34 as for the magic number.....what happens if I try and say the age of a null is greater than X? 2011-09-06T14:54:28 NULL > X -> false 2011-09-06T14:54:34 NULL < X -> false 2011-09-06T14:55:05 if it hasn't circ'd, it doesn't have a last circ date :) 2011-09-06T14:55:17 That particular one is intended for use with a weeding report (with the commented out form of it for us). They want "never circulated" copies to show up in such reports. 2011-09-06T14:56:16 so, the semantics are more like "created or last circ'd", yes? 2011-09-06T14:56:37 I mean, you don't want to include brand new copies in a "haven't circed in 10 years" report, right? 2011-09-06T14:57:19 The way they talk? Some of them might. 2011-09-06T14:57:26 so, a created_or_circulated timestamptz column seems reasonable, assuming I'm right ;) 2011-09-06T14:57:44 * tsbere is trying to figure out why the reporter thinks asset.copy has a last_circ column right now 2011-09-06T14:59:10 sounds like a virtual field for holding the id of the most recent circ 2011-09-06T14:59:24 missing oils_persist:virtual="true" maybe? 2011-09-06T14:59:32 yep 2011-09-06T14:59:48 nope 2011-09-06T15:00:10 While I am in the file anyway 2011-09-06T15:00:24 ahh... because it's a has_a relationship 2011-09-06T15:00:27 * tsbere moves to all_circulation view and changes magic number of year 1 to the copy creation date 2011-09-06T15:01:10 might_have is probably what you want (even though it will always be there in your view) 2011-09-06T15:01:38 ok 2011-09-06T15:02:38 *** jamesrf has quit IRC 2011-09-06T15:02:48 The other new one appeared to work right away for me. Ran a couple tests, moved on. <_< 2011-09-06T15:04:40 You see any issues with it while I test some of the changes to the last circ one? 2011-09-06T15:06:07 *** jamesrf has joined #evergreen 2011-09-06T15:06:15 the other one is interesting ... it's a point in time only report ... the WHERE clause may need to grow, but it's probably "close enough" since the data it's using will be constantly changing anyway 2011-09-06T15:06:52 It is supposed to be a point in time report 2011-09-06T15:06:58 right 2011-09-06T15:07:07 just observing the obvious ;) 2011-09-06T15:07:19 There is a similarish one next to it in the IDL that does things very differently. 2011-09-06T15:11:00 Oh, hey, cool, an error message I understand........because postgresql is a PITA sometimes. <_< 2011-09-06T15:13:25 that other one is meant to be a relatively performant approximation. how fast does your new one run on large datasets? (I may be able to test that soon, btw) 2011-09-06T15:13:59 I can run both queries and compare them on the same large dataset if you want 2011-09-06T15:15:22 if you include a definition of large, I'd love to see that, actually (hold count, bib count, copy count, hold-copy-map size) ... and, obv, it only needs to be fast when there's a where-clause supplied, like, for bib id, or pickup lib in yours. 2011-09-06T15:15:31 I wouldn't expect the baseline to be fast ;) 2011-09-06T15:16:06 Mine just spit out 37323 rows in 13924 ms. The one that was already there is still running. 2011-09-06T15:16:16 Sans where clauses 2011-09-06T15:16:33 like: SELECT * FROM ( ... that big view ... ) WHERE bib_id = xxx; 2011-09-06T15:16:43 tsbere: right, but with a param... 2011-09-06T15:16:46 The one already in the IDL returned 21663 rows in 66670 ms 2011-09-06T15:17:11 the old one is used with a param from within the UI 2011-09-06T15:17:17 Well yea. 2011-09-06T15:17:35 But how do you expect me to pick a bib number with holds unless I grab a list of bibs with holds? ;) 2011-09-06T15:17:42 heh 2011-09-06T15:19:05 *** akilsdonk has joined #evergreen 2011-09-06T15:19:28 Also, the two give me very different results on a lot of holds for copy count 2011-09-06T15:21:06 doing the "SELECT * FROM ( blah ) WHERE id = x" for a specific X (and with an alias on the blah) mine is actually much faster, though. Let me find one with a bigger hold count, though. I randomly grabbed one with a single hold, period. 2011-09-06T15:23:20 Running on the exact same dataset, mine returned 37 rows for a bib with 442 holds and 43 copies everywhere in 10,834ms. The one from the IDL sees the same number of holds and copies but due to lack of pickup library returned one row, but took 64,254ms to do so. 2011-09-06T15:28:07 * tsbere wasn't really expecting his to be faster, due to trying to return more info 2011-09-06T15:31:36 eeevil: I think the one in the IDL is hindered by all the subselects going on. 2011-09-06T15:36:08 * berick thinks the EG git server might need NTP 2011-09-06T15:36:35 * senator thinks every server needs ntp 2011-09-06T15:36:41 well, yeah ;) 2011-09-06T15:36:43 * dbs curses the barbarians that force YY-MM-DD date format even in civilized locales like en-CA 2011-09-06T15:37:29 "Why is this person's account expired? It's not Oct 2011 yet!" 2011-09-06T15:37:48 (checks to see if the commit author's machine was not the source of the future timestamp) 2011-09-06T15:38:18 commit time vs. authoring time? 2011-09-06T15:39:22 note to committers, plz install NTP :) 2011-09-06T15:39:59 berick: I think at one point I installed NTP on the git server already 2011-09-06T15:41:04 tsbere: indeed, I take back my comment about the server. 2011-09-06T15:41:13 'twas a client-side issue 2011-09-06T15:41:24 *** kmlussier has quit IRC 2011-09-06T15:41:29 * phasefx has chaos powers across time and space 2011-09-06T15:41:47 *** kmlussier has joined #evergreen 2011-09-06T15:42:08 eeevil: Would you like me to take a crack at re-writing the hold ratio query that was already there? 2011-09-06T15:42:56 * dbs religiously types "date --set '1972-01-01'" before committing anything 2011-09-06T15:43:45 tsbere: sorry, stepped away. sure, go for it. I'll look for some time to test it on another large dataset soon 2011-09-06T15:45:43 eeevil: For the record, the dataset I was running on has 902196 bibs, 3267915 copies, 55232 active holds 2011-09-06T15:46:04 (excluding deleted bibs and copies) 2011-09-06T15:55:35 tsbere: thanks. I should be able to test on something comparable ... are you building a test script, btw? (np if not) 2011-09-06T15:56:04 I have not built a test script. I keep running things via pgadmin 2011-09-06T16:05:12 *** Meliss has quit IRC 2011-09-06T16:24:06 eeevil: http://paste.lisp.org/display/124516 2011-09-06T16:27:30 *** adbowling-isl has quit IRC 2011-09-06T16:28:20 *** dbs has quit IRC 2011-09-06T16:28:49 *** kmlussier_ has joined #evergreen 2011-09-06T16:29:54 arg! can't force-push to working... bah 2011-09-06T16:30:34 *** kmlussier has quit IRC 2011-09-06T16:30:46 *** kmlussier_ is now known as kmlussier 2011-09-06T16:31:24 grabbing 0615 2011-09-06T16:31:55 eeevil: You should be able to force-push to working. Unless it is someone else's collab? 2011-09-06T16:32:22 tsbere: it is 2011-09-06T16:32:40 it's fine, though. was just going to push an amended commit msg 2011-09-06T16:32:45 and then merge 2011-09-06T16:32:48 so... no biggy 2011-09-06T16:35:38 *** collum has quit IRC 2011-09-06T16:39:24 *** plux has quit IRC 2011-09-06T16:42:59 eeevil: You have any opinions on potential accuracy versus speed where both options are a massive improvement on the original? 2011-09-06T16:45:02 tsbere: if the semantics of the new version are as correct or more so than the original, then I have no problem replacing it ... but I haven't looked very closely at that. Is that what you mean? 2011-09-06T16:45:52 eeevil: I came up with two replacements. The slower one uses the hold copy maps and I think gets more accurate copy counts on a number of hold types. The faster one should return things identically to the original. 2011-09-06T16:47:35 tsbere: using the hold-copy-map has the drawback of missing "new" copies (not yet placed on the potentials list) .... the one without can overestimate the copy count, of course (and is more work to maintain, as the definition of holdability changes) 2011-09-06T16:49:17 so one can overestimate copy counts and is potentially more work to maintain. The other can underestimate copy counts but automatically obtains new holdable information from the perl layer. 2011-09-06T16:49:22 since it's meant to be an approximation for immediate use in a UI, I'd tend toward faster if it's close enough 2011-09-06T16:49:58 Some of the records I see go by have hundreds of potential copies in the non-maps version and <10 in the maps version 2011-09-06T16:50:01 or, that's an important use case ... not the only one, of course 2011-09-06T16:51:12 and I see a few metarecord related holds that result in a reversal. The non-maps version reports a smaller number than the maps version, because the non-maps version doesn't take into account the other format records and their copies. 2011-09-06T16:51:12 hrm... that amount of a discrepancy is a concern 2011-09-06T16:51:33 right, I'd expect that for M-type 2011-09-06T16:52:13 The "hundreds without the hold copy maps, only a few with" happens when all of the holds are part holds, copy holds, and volume holds, it seems. 2011-09-06T16:52:40 ahh... /that/ sounds like an improvement, then 2011-09-06T16:53:25 how big is your hold-copy-map? 2011-09-06T16:53:53 947886 2011-09-06T16:54:10 *** bgoble has joined #evergreen 2011-09-06T16:59:46 eeevil: So do you think the slower version using the hold copy map table is the better choice (given that even it is significantly faster than what is there now)? 2011-09-06T17:04:50 tsbere: well, the times you're getting don't jibe with what's in use at a production site, so I'll need to look closer, but I'd like to test all variants for sure 2011-09-06T17:05:46 which I'll have to do later ... COMMUTE TIME! :) 2011-09-06T17:06:17 biab 2011-09-06T17:06:26 *** natschil has quit IRC 2011-09-06T17:06:37 * tsbere is using a copy of MVLC's production database that tends to get less CPU and memory than the actual production DB 2011-09-06T17:07:00 Production data (as of Sunday morning) though 2011-09-06T17:23:39 *** akilsdonk has quit IRC 2011-09-06T17:30:46 *** Dyrcona has quit IRC 2011-09-06T17:36:31 *** kmlussier has quit IRC 2011-09-06T17:37:56 *** artunit_ has joined #evergreen 2011-09-06T17:39:23 *** artunit has quit IRC 2011-09-06T17:39:33 *** artunit_ is now known as artunit 2011-09-06T17:52:19 *** bott-otr has joined #evergreen 2011-09-06T17:57:07 *** jenny1 has left #evergreen 2011-09-06T18:01:35 *** sal_ has quit IRC 2011-09-06T18:12:28 *** sfortin has quit IRC 2011-09-06T18:25:39 *** yboston has quit IRC 2011-09-06T18:32:59 *** matt_carlson has joined #evergreen 2011-09-06T18:53:15 *** _bott_ has quit IRC 2011-09-06T18:54:02 *** _bott_ has joined #evergreen 2011-09-06T19:00:07 *** matt_carlson has quit IRC 2011-09-06T19:17:40 *** youdonotexist has quit IRC 2011-09-06T19:23:13 *** bott-otr has quit IRC 2011-09-06T19:26:40 *** bott-otr has joined #evergreen 2011-09-06T20:25:54 *** jtgorman has joined #evergreen 2011-09-06T20:31:38 *** bott-otr has quit IRC 2011-09-06T20:32:53 *** bott-otr has joined #evergreen 2011-09-06T20:37:16 *** bott-otr has quit IRC 2011-09-06T20:48:04 *** jtgorman has quit IRC 2011-09-06T21:00:05 *** bgoble has quit IRC 2011-09-06T21:26:25 *** _bott_ has quit IRC 2011-09-06T21:56:12 *** gdunbar has quit IRC 2011-09-06T21:56:12 *** leed has quit IRC 2011-09-06T21:58:12 *** gdunbar has joined #evergreen 2011-09-06T21:58:12 *** leed has joined #evergreen 2011-09-06T22:59:29 *** youdonotexist has joined #evergreen