| # | Time | Nick | Message |
|---|
| # | 00:11:19 | dbs has quit IRC |
| # | 01:41:21 | rsinger has quit IRC |
| # | 02:01:28 | rsinger has joined #evergreen |
| # | 03:22:26 | rsinger has quit IRC |
| # | 03:31:53 | rsinger has joined #evergreen |
| # | 06:07:26 | Joscha has joined #evergreen |
| # | 06:08:42 | Joscha has left #evergreen |
| # | 06:34:49 | josh88 has joined #evergreen |
| # | 06:52:49 | josh88 has left #evergreen |
| # | 07:06:07 | josh88 has joined #evergreen |
| # | 07:09:56 | josh88 has left #evergreen |
| # | 07:11:01 | josh88 has joined #evergreen |
| # | 08:23:40 | rsinger has quit IRC |
| # | 08:32:24 | rsinger has joined #evergreen |
| # | 08:38:58 | atheos has joined #evergreen |
| # | 08:59:27 | rjackson-isl has joined #evergreen |
| # | 08:59:40 | dbs has joined #evergreen |
| # | 08:59:40 | dbs has joined #evergreen |
| # | 09:00:49 | Dyrcona has joined #evergreen |
| # | 09:03:06 | Dyrcona pasted http://paste.lisp.org/display/117480 |
| # | 09:03:29 | Dyrcona | What do I do about that? Is there a timeout setting or something that I can adjust? |
| # | 09:06:11 | josh88 has left #evergreen |
| # | 09:06:32 | Granitize1 has joined #evergreen |
| # | 09:06:36 | josh88 has joined #evergreen |
| # | 09:17:04 | mrpeters-isl has quit IRC |
| # | 09:17:12 | mrpeters-isl has joined #evergreen |
| # | 09:17:56 | dbs has quit IRC |
| # | 09:19:33 | dbs has joined #evergreen |
| # | 09:19:34 | dbs has joined #evergreen |
| # | 09:26:11 | dbs has quit IRC |
| # | 09:30:31 | Melissa has joined #evergreen |
| # | 09:31:08 | alxp has joined #evergreen |
| # | 09:37:02 | eeevil | Dyrcona: beta4? |
| # | 09:38:34 | yboston has joined #evergreen |
| # | 09:39:39 | eeevil | Dyrcona: hrm... without the query error, not sure where to look. that will definitely be in the PG log right around 8:56-8:57 (depending on clock drift/mismatch) |
| # | 09:41:32 | jenny has joined #evergreen |
| # | 09:44:24 | kmlussier has joined #evergreen |
| # | 09:46:27 | Dyrcona | eeevil: We're looking into it in some detail this morning. We think it is a couple of things working together, one of them being sloppy data brought over from the legacy system. |
| # | 09:46:35 | tsbere likes this line of bash when run in /openils/var/log: for file in open-ils.*; do truncate --size 0 $file; done |
| # | 09:46:41 | Dyrcona | Fortunately, it is only in our demo/test system. |
| # | 09:50:44 | bshum has joined #evergreen |
| # | 09:54:50 | dbs has joined #evergreen |
| # | 09:57:57 | dbs | eeevil: I suspect https://bugs.launchpad.net/evergreen/+bug/687996 is a matter of templates doing 'create new or replace existing' rather than just 'replace existing', eh? |
| # | 10:02:37 | eeeevil has joined #evergreen |
| # | 10:05:33 | sfortin has joined #evergreen |
| # | 10:08:29 | Granitize1 has quit IRC |
| # | 10:12:04 | eeeevil has quit IRC |
| # | 10:12:55 | Granitize1 has joined #evergreen |
| # | 10:13:49 | kmlussier has quit IRC |
| # | 10:16:08 | kmlussier has joined #evergreen |
| # | 10:17:03 | Granitize1 has quit IRC |
| # | 10:19:55 | eeeevil has joined #evergreen |
| # | 10:21:26 | eeeevil has quit IRC |
| # | 10:21:30 | eeeevil has joined #evergreen |
| # | 10:22:54 | eeeevil2 has joined #evergreen |
| # | 10:22:54 | eeeevil has quit IRC |
| # | 10:23:15 | dbs | @later tell eeevil: I suspect https://bugs.launchpad.net/evergreen/+bug/687996 is a matter of templates doing 'create new or replace existing' rather than just 'replace existing', eh? (Sorry about your comcast connection!) |
| # | 10:23:15 | pinesol` | dbs: The operation succeeded. |
| # | 10:23:34 | eeeevil2 has quit IRC |
| # | 10:23:40 | eeeevil has joined #evergreen |
| # | 10:24:50 | eeeevil2 has joined #evergreen |
| # | 10:25:23 | eeeevil has quit IRC |
| # | 11:04:18 | dbs has quit IRC |
| # | 11:53:22 | rsinger has quit IRC |
| # | 11:54:43 | josh881 has joined #evergreen |
| # | 11:56:29 | josh88 has quit IRC |
| # | 11:57:36 | Dyrcona has quit IRC |
| # | 12:03:06 | agJohn | Anyone seen a problem w/ 1.6.1.4 w/ fine amounts not displaying properly in the list of bills for a patron (and the full details showing an incorrect balance)? I'm still trying to characterize it, but on this one patron that I've looked at in detail, they have 5 $8 fines but each of them shows up as Total Billed: $8.00; Total Paid: 0.00; Total Owed: $10.00. The money schema views all show... |
| # | 12:03:08 | agJohn | ...the right data... |
| # | 12:03:55 | josh881 has left #evergreen |
| # | 12:05:12 | josh88 has joined #evergreen |
| # | 12:07:53 | rsinger has joined #evergreen |
| # | 12:13:12 | Bryan has joined #evergreen |
| # | 12:13:38 | Bryan is now known as Guest8487 |
| # | 12:15:03 | bkingsf has joined #evergreen |
| # | 12:17:27 | bshum | agJohn: I've seen some of that. |
| # | 12:17:59 | bshum | agJohn: It happened during one of my tests to show voiding via backdating, but I think it looks like that with any voiding present |
| # | 12:18:18 | bshum | agJohn: I'd have to confirm on another system. |
| # | 12:19:32 | agJohn | Seems to be a pervasive problem. Every one I've checked is showing a balance on each bill that's $2.00 more than the actual bill--when the money.billing amount was created after the upgrade to 1.6.1.4. |
| # | 12:19:34 | agJohn | The fine generation in general is messed up too--fines are not accumulating as expected. Arrrgh.... |
| # | 12:20:17 | bshum | agJohn: From what version did you upgrade from? (just curious) |
| # | 12:21:42 | agJohn | bshum: 1.6.0.6 |
| # | 12:23:43 | bshum | agJohn: What is the recurring rate supposed to be for the items in question? |
| # | 12:24:04 | bshum | Wondering if maybe you're somehow generating an extra day into the future...? |
| # | 12:25:56 | agJohn | OK. This makes no sense at all: billings from *before* the upgrade display the right amounts--but there's nothing I can see on the DB to account for the different behavior. Maybe all billings are messed up on patrons who have one after the upgrade date.... |
| # | 12:27:34 | bkingsf | help /nick |
| # | 12:27:47 | agJohn | bshum: The heart of the matter is that the data on the database is correct: the billings for the overdue items show the right amounts in money billing & in all the money views that summarize stuff. So, somehow the client program is sticking on this non-existent $2.00--or so it appears. |
| # | 12:27:51 | bkingsf | nick BryanK |
| # | 12:30:44 | afterl has left #evergreen |
| # | 12:31:53 | josh88 has quit IRC |
| # | 12:32:50 | bshum | agJohn: Out of curiosity, what displays when you pull up the full details for the billing entry in the staff client? Nothing out of the ordinary there? |
| # | 12:33:54 | bshum | Should only be all the system generated fines in increments that you expect I presume |
| # | 12:35:58 | agJohn | Full details summary portion lists the wrong Balance Owed ( just as the patron's Bills list does). The individual billing amounts are correct. |
| # | 12:36:47 | josh88 has joined #evergreen |
| # | 12:39:12 | agJohn | When I say "correct" I mean they correspond to what's in the money.billing table for the xact in question--fines haven't been accumulating correctly. |
| # | 12:42:07 | bshum | Total owed or balance owed? |
| # | 12:42:12 | bshum | There's a difference |
| # | 12:42:38 | bshum | Wait, I might just be imagining the wording |
| # | 12:42:41 | bshum | Nevermind, I'm crazy |
| # | 12:44:53 | bshum | This thing started life as a 1.6.0.6, so http://www.open-ils.org/downloads/1.6.0-mmbxs-cleanup.sql probably doesn't apply to you. |
| # | 12:49:41 | agJohn | Here's an example: Total Billed: $24.95; Total Paid: $2.00; Balance Owed: $24.95 -- another: Total Billed: $8.00; Total Paid: $0.00; Balance Owed: $10.00 |
| # | 12:49:43 | agJohn | Note, this is what's displayed in the Staff Client; the values on the DB do not have the spurious $2.00 added to the Balance Owed amounts--or, at least the money tables and views do not. Is there a function that might be messed up? |
| # | 12:57:21 | agJohn | Worse yet, if I pay off one of the fines, while the total under the Bills button shows the correct amount, the list actually shows the paid-off billing is still there with a balanace of $2.00. What the ? |
| # | 13:15:02 | cbandito has quit IRC |
| # | 13:17:58 | phasefx | agJohn: just curious (and skimming), are there any voided payments in the system? |
| # | 13:56:11 | dbwells | agJohn: just to be 100% sure, a query of money.materialized_billable_xact_summary is showing the correct amounts for total_owed and balance_owed? very odd! |
| # | 13:57:10 | agJohn | phasefx: Yes, there may be voided payments, but removing the one on the first patron that was found with this problem did not help. |
| # | 13:58:05 | phasefx | voided payments aren't supported/completely implemented, fwiw. The field exists on the payment table but not everything that counts up payments considers it |
| # | 13:59:37 | agJohn | dbwells: Huh; I am quite sure I checked that view before, but it is indeed showing *incorrect* amounts--wow, a place to start! |
| # | 14:01:18 | agJohn | Ah, so, no, I did not check that one before... OK. I'm about to show it what "material" beings can do to materialized views.... :~| |
| # | 14:02:00 | agJohn | er, uh, tables.... |
| # | 14:03:04 | agJohn | How is money.materialized_billable_xact_summary populated? By a trigger or Open-ILS code or what? |
| # | 14:03:39 | dbs has joined #evergreen |
| # | 14:03:39 | dbs has joined #evergreen |
| # | 14:06:17 | bshum | Looks like trigger functions to me. |
| # | 14:07:06 | agJohn | On what table are you seeing that, bshum? |
| # | 14:08:29 | bshum | Under the money.billing table's triggers |
| # | 14:08:51 | agJohn | Thanks, bshum. |
| # | 14:08:52 | agJohn | phasefx, dbwells: Is there any reason for amounts to be different in the money.materialized_billable_xact_summary table vs. money.billable_xact_summary view? |
| # | 14:09:49 | cbandito has joined #evergreen |
| # | 14:10:09 | agJohn | Or is that money.billable_xact_with_void_summary part of the partial implementation of the voiding of payments--so I should use it to try to correct the money.materialized_billable_xact_summary table? |
| # | 14:16:25 | bshum | agJohn: Does your money.billable_xact_summary view show the correct view of the information for the transaction? Or only the one that's _with_void_summary? |
| # | 14:19:25 | agJohn | Both show the correct amounts for the patrons I've checked. |
| # | 14:19:39 | dbwells | agJohn: the two _xact_summary should contain identical information. The materialized version is solely for added speed AFAIK. |
| # | 14:20:58 | dbwells | so, if you haven't already, truncating materialized and doing a INSERT INTO money.materialized_billable_xact_summary SELECT * FROM money.billable_xact_summary; will get you back in sync. |
| # | 14:22:10 | dbwells | Of course you may still have an underlying trigger issue. |
| # | 14:25:39 | agJohn | dbwells: Thanks much. Huge help. |
| # | 14:27:18 | agJohn | phasefx: I need to read more carefully; no, there are no voided *payments* in the sytem; some voided billings... |
| # | 14:32:12 | mrpeters-isl | dbwells: thanks for insight on the list...see last email |
| # | 14:32:31 | mrpeters-isl | this is driving me crazy! it'll be so cool when i can make it work! |
| # | 14:33:51 | mrpeters-isl | maybe you could test my custom profile in your working enviornment? not sure if that'd cause any chaos? |
| # | 14:34:43 | dbs thinks that all bets are off if you're using a release that has had 10 point releases since then |
| # | 14:35:22 | mrpeters-isl does too, but is not allowed to upgrade |
| # | 14:35:35 | mrpeters-isl | "too hard" on our customers to have an upgrade now, and again in March for 2.0 |
| # | 14:36:13 | mrpeters-isl | but being able to prove with concrete evidence that upgrading can fix things that are also making things hard.... |
| # | 14:37:48 | mrpeters-isl | so, proving it works on a later version = more proof we need to upgrade |
| # | 14:37:59 | mrpeters-isl | however, the fact that it also failed in 2.0 makes me wonder... |
| # | 14:39:30 | dbwells | mrpeters-isl: I have not tested imports in 2.0 yet. I'll give your profile and sample records a try and see how it goes. |
| # | 14:40:19 | mrpeters-isl | thank you! |
| # | 14:40:25 | mrpeters-isl | even in a later 1.6 would be fine too |
| # | 14:40:46 | mrpeters-isl | i just can't sell upgrading on a "might fix it" type scenario |
| # | 14:49:03 | dbs | dbwells: see my response to Repke from about a month ago on importing in 2.0 |
| # | 14:50:59 | dbwells | dbs: thanks, checking it out now |
| # | 14:51:08 | jenny has left #evergreen |
| # | 14:51:26 | Granitize1 has joined #evergreen |
| # | 14:54:52 | phasefx__ is now known as phasefx_ |
| # | 14:59:42 | phasefx | anyone recall slimpac jacket images ever being broken in 1.4? |
| # | 15:00:56 | dbs | dbwells: I guess I meant mrpeters-isl more than you :) |
| # | 15:06:29 | dbs | mrpeters-isl: seriously, please reread the messages between repke and I on import. I feel like the wheel is being reinvented |
| # | 15:06:41 | mrpeters-isl | I'm looking for it |
| # | 15:06:49 | brendan2 has quit IRC |
| # | 15:07:09 | dbs | mrpeters-isl, http://markmail.org/message/56ygtxjl2w7awemi |
| # | 15:07:27 | mrpeters-isl | k, I'm looking at http://libmail.georgialibraries.org/pipermail/open-ils-dev/2010-November/thread.html and its not there |
| # | 15:07:47 | agJohn has quit IRC |
| # | 15:09:01 | mrpeters-isl | frankly though, from reading your posting seeing anything differently than what i've already created? |
| # | 15:09:46 | phasefx figured out the jacket issue (bad URL in 1.4's ATOM2XHTML.xsl) |
| # | 15:09:54 | mrpeters-isl | don't see how =949 \\$aISLI $bISLI $cCD DMBAND $eIn process $fGeneral CD-ROM $gt $hf $jf $kt $l9.99 $m1234567891234 $ncd-music $pPrivate alert message here $qt $rPublic $sPublic Note Here $tPrivate Note $uPrivate Note Here differes from your 852 tag |
| # | 15:10:10 | mrpeters-isl | and my custom profile |
| # | 15:12:51 | mrpeters-isl is not trying to force anyone to "reinvent the wheel" but the difference in your example profile and my "real" profile isn't jumping out |
| # | 15:18:35 | dbs | mrpeters-isl: you were remarking about how 2.0 beta4 had worse results than 1.6 for you. Totally parallel to Repke's situation |
| # | 15:18:47 | mrpeters-isl | I'm not seeing how... |
| # | 15:19:16 | mrpeters-isl | other than the spaces between the $x tag indicators |
| # | 15:23:14 | dbs | I dunno. The example MARC field you posted contains: "\\$aAPLSD<file:///\\$aAPLSD>". Is that real? |
| # | 15:23:40 | mrpeters-isl | APLSD is a real org unit in my tree |
| # | 15:23:52 | dbs | <file://// ? |
| # | 15:24:08 | mrpeters-isl | thats puzzling...because i dont see it in my cop |
| # | 15:24:24 | mrpeters-isl | =949 \\$aAPLSD $bAPLSD $cCD DMBAND $eIn process $fAV $gt $hf $jf $kt $l9.99 $m1234567891234 $ncd-music $pPrivate alert message here $qt $rPublic $sPublic Note Here $tPrivate Note $uPrivate Note Here |
| # | 15:24:30 | dbs | In the quoted text, just about your signature. |
| # | 15:24:52 | mrpeters-isl | ah, that was probably outlook |
| # | 15:25:08 | mrpeters-isl | \\ probably tried to make a link to a network location |
| # | 15:25:11 | dbs | Info is too scattered for me to want to look at it. And I've got a deadline tonight. |
| # | 15:25:54 | mrpeters-isl | ok. i was detailed as could be, but thats fine. dbwells said he'd test and confirm maybe then it can be explained better |
| # | 15:28:23 | mrpeters-isl | yeah...yaz-marcdump confirms everything is fine in that area |
| # | 15:28:24 | mrpeters-isl | 949 $a APLSD $b APLSD $c |
| # | 15:30:06 | dbwells | mrpeters-isl: I was able to successfully import your test record using your profile, and did find a few problems. |
| # | 15:30:22 | mrpeters-isl | dbwells: well that is positive news |
| # | 15:30:28 | mrpeters-isl | all portions imported? |
| # | 15:30:59 | dbwells | First, your fields all have extra spaces at the end. I think that may be your biggest problem. |
| # | 15:31:44 | mrpeters-isl | so $aAPLSD$bAPLSD not $aAPLSD $bAPLSD |
| # | 15:33:35 | dbwells | Second, I added values for deposit amount and copy number to have a 'complete' import field. I am not sure if that actually mattered, though, as I had a few other kinks unrelated to your profile (non-existing location, for instance). |
| # | 15:33:37 | mrpeters-isl | makes sense |
| # | 15:33:45 | mrpeters-isl | yeah |
| # | 15:34:07 | mrpeters-isl | would you agree there is probably a need for age_protect (bool) and loan_duration (int) values on imports? |
| # | 15:34:18 | dbwells | This testing was done on 2.0, b3 I believe. |
| # | 15:34:25 | mrpeters-isl | 10-4 |
| # | 15:34:37 | mrpeters-isl | gonna give it another go |
| # | 15:35:28 | alxp has quit IRC |
| # | 15:35:39 | mrpeters-isl | dbwells++ it worked!!!!!!!! |
| # | 15:35:41 | mrpeters-isl | on 1.6.0.0 even |
| # | 15:36:03 | mrpeters-isl | bless you! |
| # | 15:36:37 | gdunbar has quit IRC |
| # | 15:37:04 | rsinger is now known as jrochkinds_sockp |
| # | 15:37:25 | jrochkinds_sockp is now known as jrock_puppet |
| # | 15:37:40 | dbwells | mrpeters-isl: that's great! I think the main problem I had pre-1.6.0.1 was that importing only worked for the admin user, so I hope you don't hit that wall next ;) |
| # | 15:38:14 | jrock_puppet is now known as rsinger |
| # | 15:38:29 | mrpeters-isl | hehe |
| # | 15:38:46 | mrpeters-isl | importing in general, or with attached holdings? |
| # | 15:38:58 | mrpeters-isl | we have Cat1's doing vandelay imports without issue so far ***fingers crossed*** |
| # | 15:40:03 | mrpeters-isl | hmm...fun, importing the bib doesnt bring the item along |
| # | 15:40:13 | mrpeters-isl | but at least vandelay.import_item is fully populated |
| # | 15:40:24 | mrpeters-isl | so, progress |
| # | 15:40:27 | dbwells | specific to attached holdings, I believe. Hard to recall (almost a year ago already!), but I am thinking that is what the changeset I reference on list fixed. You could probably apply just that set as a patch pretty safely to get you by until 2.0. |
| # | 15:41:22 | mrpeters-isl | will give a look to these changes seems like it could solve the holdings import |
| # | 15:41:48 | mrpeters-isl | in fact, id say better than could |
| # | 15:43:03 | agJohn has joined #evergreen |
| # | 15:52:22 | agJohn | The 1.6.1.4 fine generator does not seem to be taking into account the fact that the max fine setting is supposed to be a percentage--with the percentage flag set, the value should be 1.00 to represent 100%, right? |
| # | 15:52:23 | brendan2 has joined #evergreen |
| # | 15:55:03 | bshum | To whom it may concern, if you have custom entries in your config.metabib_field entries, the 1.6.1-2.0 upgrade dies horribly starting around line 15507 because they're inserting hardcoded IDs that may conflict with your custom entries... :( |
| # | 15:57:50 | agJohn | BTW, the fix to the money.materialized_billable_xact_summary was successful. I actually did an update to the table rather than a delete/re-insert--since it's a live system. Haven't turned up any info on how things got messed up. |
| # | 16:01:20 | dbwells | mrpeters-isl: again, my memory is a bit fuzzy, but I think our holdings in (at least early versions of) 1.6 may not import holdings except when 'Auto import non-colliding records' is checked. Just another factor to consider as you test. This is definitely fixed in 2.0 at least. |
| # | 16:03:49 | bshum | dbs: In your blog post for adjusting relevancy ranking in Evergreen, the example has us putting a new entry in config.metabib_field with an id of 17. I did that on our system and now the 1.6.1-2.0 upgrade script creates additional new entries starting at that same id 17 and causes everything in that transaction block to fail during upgrade. |
| # | 16:04:01 | bshum | Oops |
| # | 16:05:12 | bshum | Is this a situation where I should have remembered the rule of reserving the first 100 or so IDs for major changes? |
| # | 16:09:31 | eeevil | bshum: I'm thinking I will, in the upgrade script, use class+name to match what we want to insert, move anything we don't recongize (after checking the fkey cascades), and adjust the ids as needed ... exactly when I'll be able to do that, I don't know. probably not for b5, unfortunately |
| # | 16:10:48 | bshum | eeevil: Oh, that sounds cool. For my test data, I'm working on how best to drop those elements from the copy of our live db that I'm working with. |
| # | 16:11:12 | bshum | eeevil: Thanks :) |
| # | 16:12:35 | sfortin has quit IRC |
| # | 16:13:52 | eeevil | agJohn: I'm pretty sure that, no, the percent is measured directly (0-100), not as a ratio (0.0-1.0) |
| # | 16:15:23 | Granitize1 has quit IRC |
| # | 16:17:29 | eeevil | dbs: hey ... got a sec? |
| # | 16:17:56 | dbs | eeevil: one or two |
| # | 16:18:24 | eeevil | looking at the bug you @later'd to me before |
| # | 16:18:27 | eeevil | the authority thing |
| # | 16:18:36 | dbs | aye |
| # | 16:19:52 | eeevil | in vandelay.replace_field (plpgsql), the IF block /should/ be stopping the add-without-replace bit, no? can you doublecheck my thinking there? |
| # | 16:20:01 | eeevil | I'll paste to explain. sec |
| # | 16:20:25 | dbs will check |
| # | 16:20:49 | dbs stopped at authority.generate_overlay_template and thought "dang - overlay problems?" |
| # | 16:22:13 | bshum has quit IRC |
| # | 16:22:14 | eeevil | http://paste.lisp.org/display/117494 |
| # | 16:22:50 | brendan2 has quit IRC |
| # | 16:23:24 | eeevil | arg! ... well, strip_field may change the XML regardless of whether it did anything ... BOO |
| # | 16:23:39 | dbs | heh |
| # | 16:23:41 | eeevil | so, I think the IF xml_output <> target_xml part is the culprit |
| # | 16:23:53 | eeevil | just by stripping formatting, etc |
| # | 16:25:08 | Melissa has left #evergreen |
| # | 16:25:13 | eeevil | dbs: so ... here's a bad idea ;) ... run the target xml through strip_field with an empty field spec first |
| # | 16:27:21 | eeevil | dbs: xml_output := vandelay.strip_field( vandelay.strip_field(target_xml,''), field); ... would you be able to test that? |
| # | 16:28:09 | rjackson-isl has quit IRC |
| # | 16:28:29 | dbs | I can test it. My brain might not be able to parse it, but that's okay :) |
| # | 16:29:20 | eeevil | dbs: that would replace the first (real) line of the function (that may be obvious) ... my brain is mush too, meetings solid today |
| # | 16:29:25 | brendan2 has joined #evergreen |
| # | 16:29:44 | eeevil | well, s/too// |
| # | 16:30:04 | eeevil | dunno if you're brain is mush or not ... but mine definitely is |
| # | 16:30:07 | eeevil | brb |
| # | 16:30:08 | dbs fires up the trunk staff client |
| # | 16:30:10 | dbs | oh, it's mush |
| # | 16:32:50 | dbs | hmm. Still got the extra 400/600/800 fields. meh |
| # | 16:36:16 | brendan2 has quit IRC |
| # | 16:36:42 | afterl has joined #evergreen |
| # | 16:41:44 | eeevil | lksadfkjldfskljdfkljdf |
| # | 16:42:07 | eeevil | doh, gah... ok, I'm dumb |
| # | 16:42:50 | brendan2 has joined #evergreen |
| # | 16:43:49 | eeevil | dbs: ok, one last try? http://paste.lisp.org/display/117495 |
| # | 16:48:01 | dbs | eeevil: success, no additional fields created |
| # | 16:48:10 | dbs | but... |
| # | 16:48:16 | dbs | existing field was not updated? |
| # | 16:48:16 | eeevil | uh oh |
| # | 16:48:23 | eeevil | hrm |
| # | 16:48:30 | dbs clears cache, tries pulling record up again |
| # | 16:48:59 | dbs | Nope. existing 100 stayed as it was. For context, my edit consisted of adding a subfield |
| # | 16:49:34 | eeevil | ahh... did you expect it to be removed to match the authority? |
| # | 16:49:44 | eeevil | I would not expect that, fwiw |
| # | 16:50:24 | eeevil | I would only expect changing (or removing, say) a controlled subfield to cause it to change |
| # | 16:51:02 | eeevil | IOW, it /did/ change the field, but only the controlled fields get touched, so they just got rewritten with the same data (I think) |
| # | 16:51:58 | dbs | oh |
| # | 16:52:16 | dbs | Looks like the auth record itself didn't save - suggesting a transaction failure? |
| # | 16:52:20 | dbs tries again |
| # | 16:52:46 | dbs | yeah. Just changing the existing subfield in the auth fails |
| # | 16:53:20 | eeevil | oh dear ... error message? |
| # | 16:53:58 | eeevil | the trigger is causing an explosion, surely, but I can't sus out why staring at the code |
| # | 16:54:08 | dbs | I'm actually working on the conservancy agreement wording with the director of the conservancy at the moment |
| # | 16:54:19 | eeevil | ok ... I'll look later |
| # | 16:54:24 | eeevil | thank you for testing thus far! |
| # | 16:54:42 | dbs | thanks for your braaaaains! |
| # | 16:55:27 | eeevil heads home |
| # | 17:03:51 | kmlussier has quit IRC |
| # | 17:15:37 | Granitize1 has joined #evergreen |
| # | 17:15:50 | yboston has quit IRC |
| # | 17:22:32 | tpham has joined #evergreen |
| # | 18:17:35 | agJohn | dbs: Any possibility of hitting you up for a consult on the Java interface to OpenSRF? What we've got going is sort of working, but not quite. When we do the same calls through srfsh that our Java program is doing, everything works (updating bibs). Through Java, we end up with no fingerprint and an all-but-the-record-id-missing metabib.rec_descriptor. Having poured over logs until our eyes... |
| # | 18:17:37 | agJohn | ...are buggy, it seems like there's something subtly wrong. |
| # | 18:20:14 | agJohn | And we can't isolate what it is. The effect is that when the biblio_fingerprint.js is called, for instance, it comes back with no data. In the same spot when the xml.update call is issued by a srfsh request, the JS bits come back with the right data. Now, we are not invoking those calls directly so what is wrong is unclear. There may be some differences in the handling of the opensrf... |
| # | 18:20:16 | agJohn | ...sessions (one to the open-ils.cat and one to cstore.ingest)--we can't tell for sure. |
| # | 18:21:16 | agJohn | Perhaps just some general guidance on what has happened to OpenSRF from a theoretical/design perspective since the org.opensrf Java packages were created lo, those many years ago, would be enough. |
| # | 18:22:45 | agJohn | We'd also be pleased to have a consult from anyone else who has insight into that level of stuff. berick? eeevil? jeff? (If I left you off the list, don't feel bad ;-) |
| # | 18:32:42 | Granitize1 has left #evergreen |
| # | 18:45:15 | Bryan has joined #evergreen |
| # | 18:45:41 | Bryan is now known as Guest1979 |
| # | 19:22:53 | brykin has joined #evergreen |
| # | 19:32:02 | eeevil | dbs: I think I figured it out on the ride home ... checking now |
| # | 19:39:43 | eeevil | dbs: nope ... arg |
| # | 19:58:45 | eeevil | dbs: hrm... I can't make things blow up :( |
| # | 20:39:24 | dbs | eeevil: can't make things blow up? |
| # | 20:40:52 | dbs | eeevil: my approach: 1) load some authority records via Vandelay 2) load some bib records via Vandelay 3) control a field in a bib record (I go with the 100) 4) use the Manage Authorities interface to edit one of the controlling auth records 5) boom |
| # | 20:51:44 | eeevil | dbs: do you have pg error logs you could share? |
| # | 20:52:18 | dbs will grab said logs |
| # | 20:52:40 | afterl has left #evergreen |
| # | 20:53:11 | dbs | ahahaha |
| # | 20:53:14 | dbs | ERROR: error from Perl function "generate_overlay_template": Wide character in subroutine entry at /usr/local/share/perl5/MARC/Charset/Table.pm line 96. |
| # | 20:53:25 | dbs | That's what I get for using data with accents in it! |
| # | 20:53:39 | dbs | bugs inside of bugs |
| # | 20:55:19 | josh88 has quit IRC |
| # | 20:59:37 | dbs will now try to reproduce with plain ASCII data so we can focus on one bug at a time |
| # | 21:01:06 | eeevil | oddly, my test record had a big pile of non-latin chars |
| # | 21:02:22 | dbs | The authority record? |
| # | 21:02:57 | eeevil | hrm... no, the bib |
| # | 21:03:01 | eeevil | but I can test that |
| # | 21:03:18 | dbs | Yeah. Just tested, couldn't reproduce when the auth record was ASCII |
| # | 21:05:07 | eeevil | ha .. yep, got that too |
| # | 21:05:35 | eeevil | so that's the bug, I think ... the last version of the func should do what we want |
| # | 21:05:41 | eeevil | http://paste.lisp.org/display/117495 |
| # | 21:07:19 | dbs | yep, that's the one |
| # | 21:07:46 | dbs | eeevil++ |
| # | 21:10:08 | Granitize1 has joined #evergreen |
| # | 21:11:07 | eeevil | odd... so, the authority record claims to be utf8 (<leader>nz a22 o 4500</leader>) |
| # | 21:11:43 | eeevil | and we're saying "don't make it marc8" (use MARC::File::XML (BinaryEncoding => 'UTF-8'); |
| # | 21:12:33 | eeevil | and we're using that incantation in, for instance, add_field |
| # | 21:15:27 | eeevil | so, it is probably the template record, not the authority record itself |
| # | 21:15:44 | Granitize1 has quit IRC |
| # | 21:16:07 | dbs | hrm |
| # | 21:16:25 | eeevil | dbs: want to try another? |
| # | 21:16:37 | dbs | the MARC::Record->new() beastie needs some options? |
| # | 21:16:38 | dbs | sure |
| # | 21:17:59 | eeevil | http://paste.lisp.org/display/117495#1 |
| # | 21:18:08 | eeevil | just using ->encoding to set it |
| # | 21:18:48 | dbs | That's what I just did here |
| # | 21:18:48 | dbs | works |
| # | 21:19:09 | eeevil | wheeeee |
| # | 21:19:17 | dbs | (I used 'UTF8' but it works out to the same, no?) |
| # | 21:19:33 | eeevil | I believe so, yes. should be /UTF-?8/ |
| # | 21:19:39 | dbs | Nice debugging, sir |
| # | 21:20:03 | eeevil | so, I'll commit both changes and backport ... in a little bit :) |
| # | 21:20:11 | eeevil | back atcha |
| # | 21:25:58 | jennam has joined #evergreen |
| # | 21:26:22 | jennam | Hi there, I was just wondering, is there source available for the win32 clients? |
| # | 21:28:49 | phasefx | jennam: hey, yes, there is. see http://evergreen-ils.org/dokuwiki/doku.php?id=scratchpad:packaging_the_staff_client_for_windows for an example of where to grab the source, how to compile and package it |
| # | 21:30:46 | jennam | thank you :) I'm so glad I came across this.. we were looking at a $20,000 bill and no way to fund it! |
| # | 21:31:27 | phasefx | oy |
| # | 21:31:41 | phasefx | now the client does need a server to connect to |
| # | 21:32:03 | jennam | haha yes I know :P |
| # | 21:32:11 | phasefx | :D |
| # | 21:32:16 | jennam | i found the server source, we're converting to linux now |
| # | 21:32:25 | jennam | which will also drop the hefty microsoft license pricing |
| # | 21:35:53 | jennam | so this is probably a really dumb question but can the client be compiled on the linux server? |
| # | 21:38:17 | phasefx | it can. it's not rightly compiled, just a set of javascript, css, xml files, etc. You point a xulrunner runtime at it and you get a client |
| # | 21:38:40 | jennam | oh okay |
| # | 21:38:43 | jennam | lots to learn! |
| # | 21:39:42 | phasefx | the client can get built at the same time the server component is compiled. In the development trunk, it can even use NSIS for you to cross-compile a windows installer while in a linux environment |
| # | 21:40:34 | jennam | oOo |
| # | 23:11:40 | tpham has quit IRC |
| # | 23:42:07 | jennam has quit IRC |
April 10-13