| # | Time | Nick | Message |
|---|
| # | 00:14:29 | CarlSagan has quit IRC |
| # | 00:15:07 | CarlSagan has joined #evergreen |
| # | 01:09:47 | youdonotexist has quit IRC |
| # | 01:10:02 | youdonotexist has joined #evergreen |
| # | 01:18:24 | youdonotexist has quit IRC |
| # | 03:40:05 | eguest309 has joined #evergreen |
| # | 03:41:37 | eguest309 has left #evergreen |
| # | 05:48:07 | bshum has joined #evergreen |
| # | 06:47:49 | cerpy has joined #evergreen |
| # | 07:21:49 | sfortin has joined #evergreen |
| # | 07:25:45 | bshum has quit IRC |
| # | 07:29:32 | bshum has joined #evergreen |
| # | 07:33:40 | bshum has quit IRC |
| # | 07:36:18 | bshum has joined #evergreen |
| # | 07:46:55 | mrpeters-isl has joined #evergreen |
| # | 07:52:34 | mrpeters-isl has quit IRC |
| # | 07:58:36 | mrpeters-isl has joined #evergreen |
| # | 07:58:43 | collum has joined #evergreen |
| # | 08:14:58 | granitize has joined #evergreen |
| # | 08:23:37 | Dmagick-home has joined #evergreen |
| # | 08:26:26 | granitize has quit IRC |
| # | 08:26:53 | granitize has joined #evergreen |
| # | 08:31:52 | StephenGWills has joined #evergreen |
| # | 08:34:43 | StephenGWills | fines appear to be being automatically forgiven when a patron with an over due book renews? Am I missing a circ rule nuance? |
| # | 08:37:18 | bshum | StephenGWills: Hm |
| # | 08:37:24 | bshum | Maybe, maybe not. |
| # | 08:37:37 | bshum | That sounds odd to me though. |
| # | 08:39:05 | mrpeters-isl | yeah i don't know of a setting to do that either |
| # | 08:39:07 | mrpeters-isl | that is interesting |
| # | 08:39:31 | StephenGWills | sounds like I'm going log diving :) |
| # | 08:49:11 | Dyrcona has joined #evergreen |
| # | 08:51:48 | jeff | StephenGWills: how many days worth of fines are you seeing being forgiven? |
| # | 08:53:02 | mtate has quit IRC |
| # | 08:54:44 | StephenGWills | Jeff: I'm not sure yet. Have just heard about the problem |
| # | 08:55:16 | mrpeters-isl | guys, I know i've asked about this before but I can't seem to find my notes on it. What does "Returning NULL from app_request_recv |
| # | 08:55:17 | mrpeters-isl | after timeout: open-ils.auth.authenticate.init" indicate? |
| # | 08:55:21 | StephenGWills | I'm trying to think through what issues to go after |
| # | 08:56:22 | mrpeters-isl | Re: "returning null" this is only happening for one particular user |
| # | 08:59:23 | mtate has joined #evergreen |
| # | 09:08:14 | Meliss has joined #evergreen |
| # | 09:10:11 | eguest309_ has joined #evergreen |
| # | 09:10:27 | eguest309_ has left #evergreen |
| # | 09:16:41 | dbs has joined #evergreen |
| # | 09:33:47 | gdunbar has joined #evergreen |
| # | 09:34:35 | jenny has joined #evergreen |
| # | 09:36:10 | shopkins has joined #evergreen |
| # | 09:39:03 | yboston has joined #evergreen |
| # | 09:44:08 | mmorgan has joined #evergreen |
| # | 09:49:13 | kmlussier has joined #evergreen |
| # | 10:24:44 | cerpy has left #evergreen |
| # | 10:24:54 | cerpy has joined #evergreen |
| # | 10:27:01 | cerpy | What is the order of MFHD records (associated with a bib records) in the Staff Client? Most recent on top and oldest at the bottom? |
| # | 10:29:42 | dbs | cerpy: i think it's unordered, so the database just returns the most recently edited first (but it's not guaranteed) |
| # | 10:29:56 | dbs | could add an explicit "order_by" clause to fix that |
| # | 10:36:41 | cerpy | dbs: o well, we've been trying out things and were a bit puzzled in the sence that we didn't know how it was ordered. There were a couple in favour of recent - old. I wouldn't do anything about the current order - unless you really want to :) |
| # | 10:37:46 | dbs | cerpy: oh, I've got lots of other work to do (see: authorities) |
| # | 10:38:29 | cerpy | I bet you do. I'll have a look and see what you're up to. |
| # | 10:39:36 | dbs | https://bugs.launchpad.net/evergreen/+bugs?field.tag=authority is a start :) |
| # | 10:40:57 | tsbere | Anyone know if eeevil will be around in IRC today? |
| # | 10:41:19 | dbs recommends the mailing list for the best async communication experience |
| # | 10:41:47 | jeff | tsbere: looking at his secret calendar, he has "Avoid tsbere" blocked out all day. |
| # | 10:42:08 | tsbere | My list of questions is more of a tree depending on the responses to the first ones. Harder to do on a mailing list. |
| # | 10:42:19 | dbs | tsbere: your one line scenario doesn't really do much for me; if it's fleshed out with example branch names, item types, patrons, and tells a story about how things would work now vs. how you want things to work, that would be much more meaningful |
| # | 10:42:37 | dbs | but like I say, I'm not exactly mr. brain on either in-db or holds |
| # | 10:43:30 | mrpeters-isl | hey guys...a question about tying a memcache session to subsequent opensrf calls...i see the "INFO:XXXXX:osrf_system.c" block in my logs....does that :id#: stay consistent through all calls made from that authenticated session? |
| # | 10:44:04 | mrpeters-isl | trying to track down why an API call works on one memcache server, but not another but having trouble getting all of the logs tied down into working/non-working logs |
| # | 10:44:35 | mrpeters-isl | maybe its not even possible? not sure... |
| # | 10:45:45 | tsbere | dbs: Unless I am missing something: Take a system with one consortium entry, any number of systems, and any number of branches. Create a rule for the consortium, every system, and every branch, that sets the top level permissions group as the requesting group and the org unit in question as the pickup ou. All of these say holdable. |
| # | 10:45:52 | tsbere | Then take any one branch, and change the rule to be "strict_ou_match" and not holdable. |
| # | 10:46:02 | tsbere | You should find that the hold targeter can no longer fill holds, anywhere. |
| # | 10:47:05 | finnapz has left #evergreen |
| # | 10:49:40 | tsbere | (my first question for eeevil is "am I missing something here?") |
| # | 10:50:56 | jeff | either test-and-see, or go with the assumption that you're not wrong, and ask your next set of questions on the list (after a summary of what you've found) |
| # | 10:52:28 | finnapz has joined #evergreen |
| # | 10:52:45 | tsbere | I figure I am either missing something, or nobody is using indb holds rules to speak of, as this has been there for 3 years, excepting the recent addition of strict ou matching. |
| # | 10:54:04 | eeevil | tsbere: if you've tested, and strict_ou_match is what causes the behavior you see, then it's /that/ that is the problem ... not what's been there for 3 years |
| # | 10:54:36 | jenny has quit IRC |
| # | 10:54:56 | tsbere | eeevil: WITHOUT strict_ou_matching, it looks like you can have a rule set on a branch in one system that will be latched onto by a branch in another system. |
| # | 10:56:08 | eeevil | tsbere: you can create pathological cases, yes |
| # | 10:56:11 | dbs | Note some follow-up items from last meeting that have not been followed-up on in http://evergreen-ils.org/dokuwiki/doku.php?id=dev:meetings:2010-11 |
| # | 10:56:40 | tsbere | Unlike the circ matrix, I can't find anything that says "this org unit has to be in the ancestors/descendants tree (depending on if you are looking at the static side or the matchpoint side)" or with strict ou matching "this org unit has to match exactly". |
| # | 10:56:48 | dbs | (that's why I've been asking for more concrete examples - to determine how likely the corner cases are) |
| # | 10:59:00 | eeevil | tsbere: repeatable test cases are needed, I think (what dbs said) |
| # | 10:59:04 | eeevil | dbs: re |
| # | 10:59:08 | eeevil | er, sec |
| # | 10:59:26 | eeevil | dbs: re authority.propagate_changes, I don't think I follow |
| # | 11:02:13 | dbwells has quit IRC |
| # | 11:03:07 | eeevil | dbs: ah! ... dang, yeah, I think r18293 may have been too smart by half |
| # | 11:04:09 | eeevil | dbs: specifically, lines 351-353 |
| # | 11:04:37 | eeevil | dbs: unless I'm misunderstanding |
| # | 11:10:06 | mrpeters-isl has left #evergreen |
| # | 11:10:09 | mrpeters-isl has joined #evergreen |
| # | 11:10:51 | mrpeters-isl has left #evergreen |
| # | 11:10:54 | mrpeters-isl has joined #evergreen |
| # | 11:11:20 | lisppaste | tsbere pasted "Quick and dirty example data" at http://paste.lisp.org/display/116131 |
| # | 11:11:57 | dbs | eeevil: yeah, I was thinking of just doing a very simple regex along the lines of /<datafield.*?([^)])+?)$id.*?<\/datafield>/ |
| # | 11:12:20 | dbs | eeevil: will have at it tonight |
| # | 11:12:59 | eeevil | dbs: eh? you lost me there... that's what [0~$blah] is for in the rule we build |
| # | 11:13:51 | eeevil | dbs: or I could just be confused about the problem |
| # | 11:14:50 | tsbere | eeevil: Is that a decent test case? |
| # | 11:16:38 | eeevil | tsbere: it's not representative of real data ... the CONS ou would never be a pickup or request lib (for instances) |
| # | 11:17:16 | dbs | eeevil: will look at your commit later but my suspiciion is that by going through the template overlay approach the 4xx and 5xx fields in auth records get munged into the bib record |
| # | 11:17:35 | StephenGWills | reports seem to be stacking up in queue, Kent is running and settings_tester passes everything, what might I check next please? |
| # | 11:18:11 | dbs | vs. a super simplistic "find the datafield, pull out the tag, replace the guts with the auth records 1xx content + $0" |
| # | 11:18:20 | dbs runs to French class prep |
| # | 11:18:25 | eeevil | dbs: they shouldn't, since: we /only/ ask for 100-111, 130, 150-155, 180-185 |
| # | 11:18:59 | lisppaste | tsbere annotated #116131 "Different request/pickup ou, then" at http://paste.lisp.org/display/116131#1 |
| # | 11:19:07 | eeevil | dbs: IOW, we never look at anything but 1xx fields |
| # | 11:20:18 | dbs promises he will look when he returns to figure out why 400 and 500 fields seem to get created |
| # | 11:20:18 | eeevil | tsbere: why shouldn't that rule be chosen? BM1 is a child of (near to) BR1 |
| # | 11:22:26 | tsbere | Tree says 1->2->4 (where rule 2 is set on all counts) and 1->3->6->9 (the pickup/request ou). |
| # | 11:23:44 | eeevil | you're right, misread the tree. |
| # | 11:24:39 | tsbere | I will admit that item 1's owning and circ libraries are set to 4, though. |
| # | 11:25:10 | tsbere | But the pickup and request ou settings shouldn't let a rule apply that far off on the tree, IMO |
| # | 11:26:48 | eeevil | tsbere: there's an implicit "owner/circ-er controls the fate of the item" viewpoint embedded there. given that (and yes, we can discuss making that configurable such that the owner can choose /not/ to control the fate of its items) does it make sense to you? |
| # | 11:27:20 | eeevil | so, IOW, this owner has said "nobody can hold my items" |
| # | 11:27:38 | eeevil | why should someone from another system be able to say "well, /I/ can" |
| # | 11:28:01 | eeevil | in my view, what you're seeing is correct |
| # | 11:28:09 | StephenGWills look for little pieces of kryptonite in his server :( |
| # | 11:28:41 | eeevil | if, however, you move the items somewhere else and it's still doing that, then /that/ would be a problem |
| # | 11:30:30 | lisppaste | tsbere annotated #116131 "New rule!" at http://paste.lisp.org/display/116131#2 |
| # | 11:30:56 | tsbere | Whoops, copied the wrong test rule |
| # | 11:31:09 | tsbere shouldn't have 9 sitting in his buffer |
| # | 11:32:09 | gmcharlt grabs 450 |
| # | 11:32:31 | tsbere | Then again, the item is owned by 4, 8 is lower than 4 in the tree, so items applying to 8 shouldn't have an effect on 4, right? |
| # | 11:32:37 | jenny has joined #evergreen |
| # | 11:34:14 | lisppaste | tsbere annotated #116131 "Why not, org unit 5 too" at http://paste.lisp.org/display/116131#3 |
| # | 11:34:41 | eeevil | tsbere: lower/higher in the tree doesn't matter, just edge proximity |
| # | 11:36:56 | eeevil | it can certainly be (and probably should be) argued that tree direction should be considered (only look at self-or-ancestor rules, say) but that's just a simple "is this rule in scope" check at the top of the loop, I think |
| # | 11:37:33 | lisppaste | tsbere annotated #116131 "Move some stuff around" at http://paste.lisp.org/display/116131#4 |
| # | 11:39:17 | tsbere | I think that last one has created a "not a single one of the values in the matchpoint is even closely related to the ones being compared to" situation. |
| # | 11:42:20 | eeevil | tsbere: if you set all the OU fields in matchpoint 1 to 1, do you get what you expect? (symptom of underdocumenting, but "if you use an ou somewhere, fill it in on all the rules") |
| # | 11:43:33 | tsbere | eeevil: Yes. Until I turn on strict_ou_match on any other rule, anyway. |
| # | 11:43:45 | youdonotexist has joined #evergreen |
| # | 11:45:48 | tsbere | Huh, turned on strict_ou_match, and I can't get a result. Typo: pickiup_ou on line 157 of 110.hold_matrix.sql, looks like |
| # | 11:48:00 | lisppaste | tsbere annotated #116131 "More data" at http://paste.lisp.org/display/116131#5 |
| # | 11:48:19 | tsbere | (had to not have the pickup_ou in rule 5, due to said typo) |
| # | 11:48:58 | eeevil | luckily, strict is only in trunk :) |
| # | 11:50:33 | tsbere | All in all, though, I think that, especially when compared to the circ matrix, this does not act in any reasonable way. |
| # | 11:51:36 | tsbere | Unless you have set every single ou setting you are using anywhere on every rule it won't pick the right one, and I am not sure it will pick the right one even if you do set it on every rule you make. |
| # | 11:52:09 | eeevil | looks like excluding not-self-or-ancestor matchpoints for any specified OU will address your concerns, correct? |
| # | 11:52:45 | tsbere | Yes. And on strict ou I would imagine skipping the rule when a set ou value isn't exactly the same. |
| # | 11:53:17 | eeevil | IOW, it's a solvable problem with documentable restrictions as of 2.0 (always or never use a particular OU) |
| # | 11:53:29 | eeevil | ou slot, that is |
| # | 11:53:37 | tsbere | (I noticed all of this while collecting information for a re-write, for the record) |
| # | 11:54:03 | tsbere | eeevil: As I said, I am not sure it will pick the right one even if all are set. There are other concerns I have for the weighting. |
| # | 11:55:48 | eeevil | with the right tree layout you can create pathological cases today, yes. but again, these are sovlable without changing the intended semantics (or making configuration more, instead of less, complicated) |
| # | 11:57:06 | lisppaste | tsbere annotated #116131 "Wait, what?" at http://paste.lisp.org/display/116131#6 |
| # | 11:57:44 | jeff | just take a page from other systems, and require OU*CIRCMOD*PATRONGROUP*ATTR3*ATTRn... rules :) |
| # | 11:59:12 | phasefx says we get an infocom parser |
| # | 11:59:15 | phasefx | light torch |
| # | 11:59:17 | phasefx | examine hold |
| # | 11:59:38 | phasefx | dodge grue |
| # | 11:59:49 | tsbere | I feel that in order to keep this issue from being a major issue you need to have a much larger hold matrix table, which makes maintaining it much harder. Exponential growth for each ou-based setting you use. |
| # | 12:00:11 | tsbere | Thus, so long as the problem exists, configuration is more complicated. |
| # | 12:02:36 | eeevil | tsbere: it's not so bad as all that. if you use an ou in every rule where you need a specific override you're not inflating the number of rules -- just having to be more explicit that we'd perhaps like |
| # | 12:03:02 | tsbere | eeevil: Did you see my "Wait, what?" one there? |
| # | 12:03:36 | mrpeters-isl | i know this is silly, but i think "select procpid, now()-query_start AS duration, current_query from pg_stat_activity where current_query <> '<IDLE>' order by 2;" on http://open-ils.org/dokuwiki/doku.php?id=scratchpad:random_magic_spells is more correct than the current query |
| # | 12:04:04 | lisppaste | tsbere annotated #116131 "More fun" at http://paste.lisp.org/display/116131#7 |
| # | 12:04:08 | eeevil | tsbere: yes ... that one is confusing |
| # | 12:04:14 | mrpeters-isl | that small change will properly title your columns...the current verison gives "?column?" for duration and incorrectly calls the query column "duration" |
| # | 12:04:45 | jeff | mrpeters-isl: sounds useful! do you have a wiki account already, or can i create one for you? |
| # | 12:04:51 | mrpeters-isl | jeff: i don't |
| # | 12:05:08 | mrpeters-isl | but i'd behappy to update it if it's ok to do so...someone probably needs to confirm my line of thought on that first |
| # | 12:05:54 | mrpeters-isl | i only caught it because i have a nagios plugin that ties in to results from that query and i noticed the column names were wrong (at least in pg 8.4.4) |
| # | 12:05:55 | tsbere | eeevil: That comes because two branches right next to each other under the same system have the same proximity as the branch to the consortium level. Thus, whichever rule comes first in the sort, which will be table order by default, wins. By changing rule 1 twice I moved it to the end. By vacuum full in "More fun" I pushed it back to the start of the table, so it came first again. |
| # | 12:07:02 | eeevil | tsbere: self-or-ancestor would address that |
| # | 12:07:03 | jeff | mrpeters-isl: your version looks good to me, and sanity checks AOK. msg me your desired wiki username and e-mail address. |
| # | 12:08:34 | tsbere | eeevil: This last bit with a rule that changes on table order was to address the fact that to properly compensate for this you need to duplicate rules at every org unit on any level you have rules. So if you have rules at the system level every system needs them. If you have them at the branch every branch needs them. Etc. |
| # | 12:09:14 | tsbere | That creates a "you need more rules than you thought you did" issue. Luckily that rule (rules at every org unit at the same level you have a rule) only applies per permission group, or it would really spiral out of control. |
| # | 12:09:52 | eeevil | tsbere: or it's a bug and ancestor-or-self address it. I'll have a patch for you to try out in a few minutes, if you like |
| # | 12:10:27 | tsbere | eeevil: I am confident that ancestor-or-self will fully address the issue, without needing to test. But I can't figure out how this has been coded this way for 3 years without anyone noticing this. |
| # | 12:10:57 | eeevil | while these are important corner cases, they are still just that -- it's not common to see rules like you're constructing |
| # | 12:11:25 | eeevil | IOW, nobody noticed because nobody set up rules like that |
| # | 12:11:26 | tsbere | It would happen just as easily with just the pickup_ou option set, near as I can tell. |
| # | 12:12:03 | tsbere | side note: Is it expected to use actor.org_unit_proximity as a table or as a function? |
| # | 12:12:40 | eeevil | it's both. the table is a cache, and the function is authoritative |
| # | 12:12:58 | eeevil | we use the function in there so that forgetting to run autogen -u won't kill hold targetting |
| # | 12:13:23 | tsbere | Tis very confusing when you have a function by the same name as a table, though. |
| # | 12:16:24 | scott___ has joined #evergreen |
| # | 12:16:33 | lisppaste | miker_ annotated #116131 "patch" at http://paste.lisp.org/display/116131#8 |
| # | 12:17:28 | jscott has joined #evergreen |
| # | 12:19:06 | tsbere | What, you couldn't fix the pickiup typo? ;) |
| # | 12:19:14 | eeevil | thought I did |
| # | 12:19:29 | eeevil | - tmp_weight := CASE WHEN current_mp.pickup_ou = pickiup_ou THEN 1.0 ELSE 0.0 END; |
| # | 12:19:31 | tsbere | Oh, wait, it did get fixed. Why didn't my patch fix it? |
| # | 12:19:32 | eeevil | + tmp_weight := CASE WHEN current_mp.pickup_ou = pickup_ou THEN 1.0 ELSE 0.0 END; |
| # | 12:19:44 | tsbere looks at why his patch program didn't apply the whole patch, and what else it screwed up |
| # | 12:19:50 | eeevil | heh |
| # | 12:20:52 | tsbere gives up, reverts, does a second pass with the exact same command, and gets the fully patched file |
| # | 12:21:37 | tsbere | mismatched parentheses? |
| # | 12:22:08 | eeevil | ahh yeah. sec |
| # | 12:23:06 | lisppaste | miker_ annotated #116131 "doh ... parens" at http://paste.lisp.org/display/116131#9 |
| # | 12:24:37 | tsbere is getting more expected results now |
| # | 12:25:12 | tsbere | I still think that the "if not strict_ou_match" else clause should be a continue instead of a 0 adjustment, though. |
| # | 12:25:40 | tsbere | (for non-match, anyway) |
| # | 12:25:44 | eeevil | that would indeed be more clear, yes |
| # | 12:25:48 | jscott is now known as cheesemonger |
| # | 12:26:42 | tsbere | A quick run of tests shows expected results now. |
| # | 12:27:14 | tsbere | I won't bother pasting them. Partially because they already ran past my scrollback buffer. |
| # | 12:28:16 | lisppaste | miker_ annotated #116131 "CONTINUE instead of weight adjustment" at http://paste.lisp.org/display/116131#10 |
| # | 12:29:51 | eeevil | lunch |
| # | 12:30:05 | tsbere | I question one more thing, though. On strict_ou_match, why do those "always win" by default? If I make any rule without any of the ou settings in place and turn that on it starts to win regardless. |
| # | 12:33:36 | cerpy has left #evergreen |
| # | 12:37:31 | eeevil | that's s misconfiguration. it can also be addressed (perhas even as a CHECK constraint) but you wouldn't do that on purpose. now, though, I realize I need to bring back the weight adjustment after the CONTINUE, in case there are multiple rules of that sort (differing sets of ou slots in use) |
| # | 12:37:59 | eeevil | still the option for pathological cases, but better than current |
| # | 12:38:12 | eeevil | I'll do that right after I eat |
| # | 12:40:48 | tsbere | At this point I am looking at what I need to know for my re-write for more dynamic priority settings. Although I should go eat too. <-< |
| # | 13:09:52 | jamesrf has joined #evergreen |
| # | 13:12:27 | eeevil | grabbing 0451 |
| # | 13:12:59 | jamesrf has quit IRC |
| # | 13:13:56 | jamesrf has joined #evergreen |
| # | 13:22:57 | mnaj has joined #evergreen |
| # | 13:24:02 | bshum | Hmm |
| # | 13:24:12 | bshum | There has only been one reply to the IRC dev meeting scheduled for tomorrow. |
| # | 13:24:24 | bshum | That reply asked to move it to 11 am EST instead of 2 pm EST |
| # | 13:24:57 | eeevil | bshum: IIRC, dbs seconded that |
| # | 13:25:13 | mnaj has left #evergreen |
| # | 13:25:25 | bshum | eeevil: I think you're right. |
| # | 13:25:38 | bshum | Should we set the time for early then? |
| # | 13:26:13 | eeevil | 11am Eastern is fine by me, fwiw |
| # | 13:28:28 | bshum | Alright, unless there's a strong move later on, I'm going to send today's reminder with the time set for 11am EST tomorrow. |
| # | 13:31:49 | phasefx | works for me |
| # | 13:32:01 | tsbere | eeevil++ although I think the CASE on the tmp_weights after the continue could be replaced with raw 1.0 assignments. |
| # | 13:32:11 | tsbere | 11am eastern is fine by me too, for the record. |
| # | 13:32:35 | eeevil | tsbere: it could |
| # | 13:34:49 | tsbere | Any thoughts on whether something like the strict ou match flag should be incorperated into the circ matrix? |
| # | 13:36:01 | CarlSagan has quit IRC |
| # | 13:36:35 | CarlSagan has joined #evergreen |
| # | 13:37:52 | eeevil | tsbere: no thoughts. we'd need a use case that isn't covered ATM |
| # | 13:44:52 | bshum has quit IRC |
| # | 13:44:55 | kmlussier has quit IRC |
| # | 13:46:22 | jenny1 has joined #evergreen |
| # | 13:46:30 | cheesemonger has quit IRC |
| # | 13:47:38 | tildeequals has quit IRC |
| # | 13:49:23 | jenny has quit IRC |
| # | 14:01:13 | kmlussier has joined #evergreen |
| # | 14:18:12 | tildeequals has joined #evergreen |
| # | 14:56:22 | lisppaste | dbs pasted "for eeevil: generatin' auth overlays" at http://paste.lisp.org/display/116142 |
| # | 15:00:00 | dbs looks at http://svn.open-ils.org/trac/ILS/changeset/18293 but his simple mind is strongly tempted to bypass the overlay XML entirely in propagate_changes() with just a regexp_replace() |
| # | 15:05:18 | gmcharlt | dbs: a regex sophisticated enough to do things like preserve 1xx/7xx $e ? |
| # | 15:06:30 | dbs | gmcharlt: probably not; it would just keep the existing tag for any fields that contain the matching $0 and replace the contents with the contents of the 1xx from the auth record |
| # | 15:07:13 | gmcharlt | dbs: every time you say something like that, a cataloger loses its wings ;) |
| # | 15:07:22 | dbs | but I would take that over generating extra fields |
| # | 15:10:41 | dbs | It appeals to me more tahn trying to untangle the 20-odd lines of dense, regexy uncommented perl in vandelay.add_field and try to work out how to fix the case for authorities without breaking other things |
| # | 15:11:41 | dbs | (for that matter, I don't even know if the existing authority.generate_overlay_xml() preserves 1xx/7xx $e) |
| # | 15:12:25 | gmcharlt | dbs: I'm pretty sure it doesn't, actually |
| # | 15:12:36 | b_bonner has joined #evergreen |
| # | 15:12:45 | gmcharlt | I'm more just pointing out that it will need to be a subfield-level merge |
| # | 15:12:51 | dbs | then I'm not worried about fixing a known error condition |
| # | 15:13:47 | rjackson-isl has joined #evergreen |
| # | 15:14:07 | dbs | So you're essentially saying "keep $e from the existing bib field because it gets appended to the controlled subfields by the cataloger"? |
| # | 15:15:19 | dbs | so what happens when the auth record contains a 100 $e? |
| # | 15:16:17 | gmcharlt | an edge case, but possible - IMO, the bib's $e should win |
| # | 15:17:08 | tspindler has joined #evergreen |
| # | 15:17:13 | dbs | Or are you talking about something other than relator codes entirely? the $w crap, er, I mean awesomeness |
| # | 15:18:00 | dbs | gmcharlt: good god, man, what's the point of controlling a field if bib fields override controlled subfields? create another control in that case! |
| # | 15:18:17 | dbs | lewis carroll the writer vs. lewis carroll the illustrator |
| # | 15:18:31 | gmcharlt | dbs: well, it's arguably a mistake that the 1xx field in the authority record has relator codes to begin with |
| # | 15:18:39 | dbs | heh |
| # | 15:18:48 | gmcharlt | the $w is something else, of course |
| # | 15:18:56 | dbs | I guess we have to figure out what mistaken design we want to propagate |
| # | 15:20:25 | rjackson-isl has quit IRC |
| # | 15:21:23 | dbs | or what limitations we want to live with and document for 2.0, given that we're lightyears ahead of where we were pre-2.0 |
| # | 15:23:20 | dbs | gdunbar: the 2.0 release notes have circ + acquisitions sections; is there a cataloging section forthcoming, or should we start working on that separately? |
| # | 15:24:48 | gdunbar | dbs: ESI didn't do much work for cataloging on 2.0. Was there something specific you think we missed? |
| # | 15:26:50 | dbs | gdunbar: Might be my mistake, if your scope was just the ESI-specific part of the release notes for 2.0. Authorities, call number schemas, bib source manipulation are things I've worked on |
| # | 15:27:59 | gdunbar | Ah, sorry dbs, I'm not intimate with all you've done; if you've got it written down somewhere on the wiki I'd be happy to add that in for you |
| # | 15:28:14 | shopkins has quit IRC |
| # | 15:28:35 | dbs | gdunbar: no, that's okay, I can write up my pieces; I just didn't want to duplicate effort |
| # | 15:29:55 | dbs | Need to bring http://evergreen-ils.org/dokuwiki/doku.php?id=faqs:evergreen_roadmap and the release notes together (and get post-2.0 roadmap entries in place) |
| # | 15:32:02 | gdunbar | dbs: good point, it's looking a bit confused |
| # | 15:33:18 | dbs adds a link to the 2.0 release notes from the Roadmap, updates release date from Sept 2010 to Jan 2011 |
| # | 15:34:45 | dbs supposes the alternative to a regex would be if there's a "replace but do not add" overlay rule |
| # | 15:35:27 | eeevil | dbs: in your paste above, http://paste.lisp.org/display/116142 , the problem is that changeset I mentioned eariler |
| # | 15:36:35 | dbs | eeevil: sure, but presumably you added that for a reason |
| # | 15:36:36 | eeevil | dbs: I will look at that tonight and address it. if you revert that I suspect you will see what you want |
| # | 15:36:54 | eeevil | dbs: I did. the problem is I didn't go far enough |
| # | 15:36:56 | dbs | eeevil: right, but I am afeared to revert it in case it breaks something else |
| # | 15:37:02 | moodaepo | Is it safe to assume I can clean out my alpha4 db using build-db.sh as shown here > http://www.open-ils.org/dokuwiki/doku.php?id=evergreen-admin:importing:bibrecords#restoring_your_evergreen_database_to_an_empty_state |
| # | 15:37:05 | eeevil | just for testing, Imean |
| # | 15:37:22 | dbs | moodaepo: or re-run eg_db_config.pl |
| # | 15:37:23 | moodaepo is moving on to alpha5 from alpha4 |
| # | 15:37:28 | eeevil | but, now I must run |
| # | 15:37:30 | eeevil | biab |
| # | 15:37:32 | dbs | eeevil++ |
| # | 15:37:55 | moodaepo | dbs++ |
| # | 15:39:08 | dbs grabs 452 |
| # | 15:39:51 | dbwells has joined #evergreen |
| # | 15:46:38 | dbs | dbwells: will you be able to make the dev meeting tomorrow? |
| # | 15:47:49 | dbwells | dbs: I am planning on it. |
| # | 15:47:58 | dbs | yay! |
| # | 15:52:41 | sfortin has quit IRC |
| # | 15:56:31 | Meliss has quit IRC |
| # | 15:57:41 | collum has left #evergreen |
| # | 16:03:44 | tspindler has quit IRC |
| # | 16:03:54 | youdonotexist has quit IRC |
| # | 16:10:37 | jenny has joined #evergreen |
| # | 16:10:42 | jenny has left #evergreen |
| # | 16:13:20 | pmplett has joined #evergreen |
| # | 16:13:49 | jenny1 has quit IRC |
| # | 16:15:30 | mrpeters-isl has quit IRC |
| # | 16:34:50 | jamesrf has quit IRC |
| # | 16:36:47 | youdonotexist has joined #evergreen |
| # | 16:37:25 | eeevil | dbs: 1-line patch for your issue. would you be able to test? |
| # | 16:37:37 | dbs | aye |
| # | 16:38:27 | lisppaste | miker pasted "proposed fix authority propagation" at http://paste.lisp.org/display/116148 |
| # | 16:43:40 | mtcarlson has joined #evergreen |
| # | 16:43:54 | dbs | eeevil: not "next if (!exists..." ? |
| # | 16:45:01 | eeevil | nope ... if we have no target fields AND we have a requirement to match a subfield (which, by definition, can't exist) move on |
| # | 16:45:07 | dbs | ok |
| # | 16:48:13 | dbs | works |
| # | 16:48:17 | dbs | eeevil++ |
| # | 16:48:21 | eeevil | cool. committing |
| # | 16:55:37 | youdonotexist has quit IRC |
| # | 16:55:54 | youdonotexist has joined #evergreen |
| # | 17:04:19 | jamesrf has joined #evergreen |
| # | 17:05:03 | kmlussier has quit IRC |
| # | 17:06:04 | mmorgan has left #evergreen |
| # | 17:15:43 | StephenGWills has quit IRC |
| # | 17:29:03 | Dyrcona has quit IRC |
| # | 17:40:36 | dbs has quit IRC |
| # | 18:12:14 | b_bonner has quit IRC |
| # | 18:28:50 | hamtechlib has joined #evergreen |
| # | 18:33:17 | hamtechlib has quit IRC |
| # | 18:38:07 | yboston has quit IRC |
| # | 18:49:12 | mtcarlson has quit IRC |
| # | 19:26:16 | youdonotexist has quit IRC |
| # | 19:54:37 | dbs has joined #evergreen |
| # | 20:05:01 | lisppaste has quit IRC |
| # | 20:12:58 | lisppaste has joined #evergreen |
| # | 20:25:52 | jamesrf has quit IRC |
| # | 20:52:02 | CarlSagan has quit IRC |
| # | 20:52:28 | CarlSagan has joined #evergreen |
| # | 21:46:30 | StephenGWills has joined #evergreen |
| # | 21:56:25 | dbs tries to figure out why "SELECT authority.merge_records("are".id,598 ) AS "count" FROM authority.record_entry AS "are" WHERE "are".id = 684;" doesn't properly merge records, while "SELECT authority.merge_records(684,598);" does |
| # | 22:03:54 | dbs | mmm, doesn't actually work in either case. *sigh* |
| # | 22:13:35 | dbs | ah, flipped target/source record logic |
| # | 22:16:49 | jamesrf has joined #evergreen |
| # | 22:25:37 | dbs | grabbing 0454 |
| # | 22:37:14 | tildeequals has quit IRC |
| # | 22:39:16 | CarlSagan has quit IRC |
| # | 22:39:34 | CarlSagan has joined #evergreen |
| # | 23:00:18 | pmplett is now known as pmpafk |
| # | 23:14:26 | tildeequals has joined #evergreen |
| # | 23:41:12 | jamesrf has quit IRC |
April 10-13