| Time |
Nick |
Message |
| 01:09 |
bshum |
@later tell dbs As I started pulling together the various changed functions, etc. for array_agg changeover, I notice a few more places where we're still doing array_to_string(array_agg()) instead of string_agg(). Will try to poke those tomorrow. |
| 01:09 |
pinesol_green |
bshum: The operation succeeded. |
| 01:18 |
|
jboyer_isl joined #evergreen |
| 05:53 |
|
dbs joined #evergreen |
| 06:40 |
bshum |
@later tell dbs Insomnia got to me and I pushed a new branch on bug 874296 with a first crack at the upgrade SQL bits. Oh my word, such HUGE functions needing replacement. |
| 06:40 |
pinesol_green |
bshum: The operation succeeded. |
| 06:41 |
dbs |
bshum++ |
| 06:42 |
bshum |
I organized the upgrade SQL with little comments to myself like -- from 030.schema.metabib.sql |
| 06:42 |
dbs |
I will endeavour to test those out. Groggy. |
| 06:42 |
bshum |
So that I knew where I was looking for changes |
| 06:42 |
bshum |
I think I caught all of them, but there were lots. |
| 06:43 |
bshum |
dbs++ cool, cool |
| 06:43 |
bshum |
I'm going to go put my head down again for a few more minutes. |
| 06:43 |
dbs |
Thanks for taking a stab! |
| 06:43 |
dbs |
Me too |
| 08:18 |
jl- |
good morning |
| 08:32 |
|
akilsdonk joined #evergreen |
| 08:43 |
|
mmorgan joined #evergreen |
| 08:55 |
|
ericar joined #evergreen |
| 08:57 |
|
dluch joined #evergreen |
| 09:18 |
|
Callender joined #evergreen |
| 09:29 |
|
Dyrcona joined #evergreen |
| 09:45 |
jeff |
bshum: re: your recent message to the list... have you observed AC jacket images being cached beyond the configured TTL? |
| 09:48 |
bshum |
jeff: That depends I guess... I should check what the configured TTL is :) |
| 09:48 |
bshum |
Maybe it's abnormally long for some reason. Or maybe people just want things NOW, NOW, NOW. |
| 09:55 |
bshum |
jeff: Remind me where that lives though, I'll check for it when I get to the office shortly. |
| 10:01 |
jeff |
bshum: opensrf.xml, cache/global/max_cache_time -- default is 1 day |
| 10:02 |
jeff |
AC does not override that default |
| 10:02 |
jeff |
(i.e., there's not currently any AC-specific TTL) |
| 10:08 |
jl- |
hmm I'm not able to truncate evergreen=# truncate biblio.record_entry; |
| 10:08 |
jl- |
ERROR: cannot truncate a table referenced in a foreign key constraint |
| 10:10 |
Dyrcona |
jl-: If this is related to your questions from yesterday, I suggest you wipe the database out and build it fresh. |
| 10:18 |
|
rjackson-isl joined #evergreen |
| 10:19 |
jl- |
Dyrcona: yes I'm trying to rebuild |
| 10:19 |
jl- |
what is the paramaeter for the db version? |
| 10:19 |
jl- |
-v doesn't work |
| 10:19 |
jl- |
nor --db_version |
| 10:20 |
dbs |
jl-: I take it you're not following the install info at docs.evergreen-ils.org |
| 10:20 |
Dyrcona |
jl-: Don't truncate tables. Go to the postgres databas and drop database {evergreen}; where {evergreen} is whatever you named your evergreen database. |
| 10:20 |
jl- |
dbs: I am, I do get this message tho: |
| 10:21 |
dbs |
Or just rerun eg_db_config as listed in http://docs.evergreen-ils.org/2.5/_creating_the_evergreen_database.html |
| 10:21 |
jl- |
* Could not determine the version of PostgreSQL you have installed. Our best * |
| 10:21 |
jl- |
* guess was: |
| 10:21 |
jl- |
when running ./build-db.sh |
| 10:22 |
dbs |
are you running build-db.sh? |
| 10:22 |
jl- |
trying to, yes |
| 10:22 |
dbs |
Where in docs.evergreen-ils.org does it say to run build-db.sh? |
| 10:23 |
jl- |
I was following http://wiki.evergreen-ils.org/doku.php?id=evergreen-admin:importing:bibrecords |
| 10:23 |
dbs |
CAN I PLEASE DELETE WIKI PAGES? |
| 10:24 |
jl- |
btw, this box has evergreen 2.1.2 installed |
| 10:24 |
jl- |
is that a feasible version or too old? |
| 10:25 |
jl- |
dbs: btw., the docs.evergreen mention the exact same command |
| 10:26 |
dbs |
2.1 hasn't been supported for about a year |
| 10:28 |
dbs |
jl-: oh yes? In the 2.1 docs? We should probably put a big red banner on those, too, saying "This version is no longer supported" |
| 10:29 |
* Dyrcona |
wonders if dokuwiki even supports deleting pages. |
| 10:30 |
kmlussier |
I think bshum told me you delete the page's contents and hit save. |
| 10:31 |
dbs |
Dyrcona: it does, as kmlussier said, but you can still get at the history of the page |
| 10:31 |
Dyrcona |
So, I've got a question: Manage Authorities looks like this with out production clients both on Windows and Ubuntu: https://jason.mvlcstaff.org/owncloud/public.php?service=files&t=718d7d406b4162761593cbf0a5438fd7 |
| 10:31 |
jl- |
ok.. so we do have 2.1, should I switch or is this enough to get this working as a demo? |
| 10:31 |
Dyrcona |
Heh, kind of like how Evergreen "deletes" things. :) |
| 10:31 |
dbs |
The reason for not deleting wiki pages is because there's a wiki manager and desires to preserve Evergreen history |
| 10:32 |
Dyrcona |
jl-: Get the latest of Evergreen and OpenSRF. |
| 10:32 |
dbs |
jl-: you should not bother with 2.1, many many things have changed and nobody will help you |
| 10:32 |
Dyrcona |
On my development client, updated from master yesterday, Manage Authorities looks perfectly fine. |
| 10:32 |
dbs |
Dyrcona: looks like a fun CSS issue, at best |
| 10:32 |
dbs |
any local CSS customizations maybe? |
| 10:33 |
Dyrcona |
Ah, so maybe a conflict with our local CSS changes. |
| 10:33 |
Dyrcona |
dbs: Yes, but I load them on development, too. |
| 10:33 |
Dyrcona |
I wondered if there was a patch already that I missed, so at least now I know where to look. |
| 10:37 |
Dyrcona |
I feel like replying to the DVD cover art thread with a sarcastic, "Gee! It would be nice if there was some unique identifier for these things." ;) |
| 10:38 |
jeff |
we're looking at putting IMDB id into records. |
| 10:38 |
jeff |
also looking at other identifiers. |
| 10:38 |
jeff |
if i say identifiers enough i feel like i'm in #code4lib around 2006 or so. |
| 10:40 |
jeff |
but imdb id is the movie, not the dvd/blu-ray/etc |
| 10:41 |
jl- |
dbs: what's your role/position in evergreen? |
| 10:42 |
phasefx |
dbs.pm |
| 10:42 |
dbs |
jl-: a developer, admin for our own evergreen instance, general pain in the posterior |
| 10:43 |
jl- |
^^ |
| 10:44 |
dbs |
these days mostly "grump" |
| 10:55 |
|
krvmga joined #evergreen |
| 10:55 |
bshum |
dbs: But a grump I aspire to be just like when I grow up. :D |
| 10:56 |
krvmga |
is there a way to set kiosk opacs so that the default search location is the library that owns the kiosk? |
| 10:57 |
krvmga |
i thought default search location had to be tied to an account but i'd be happy to be wrong |
| 10:58 |
krvmga |
dbs: http://www.grumpycats.com/ |
| 11:01 |
bshum |
Dyrcona: That seems like a perfectly valid reply to me. |
| 11:01 |
dbs |
One day you too can babysit postgresql killing queries by hand. |
| 11:02 |
Dyrcona |
dbs: Been there, done that., and on Sybase, too! |
| 11:02 |
krvmga |
Sybase. may auld acquaintance be forgot and never brought to mind. |
| 11:03 |
Dyrcona |
"I aspire to a life of fame and fortune! I aspire to be a Database Admin!" |
| 11:04 |
gmcharlt |
the fortune, at least in relative terms, is possible |
| 11:04 |
gmcharlt |
the fame... not so much ;) |
| 11:04 |
dbs |
https://groups.google.com/d/msg/conifer-discuss/-lER5ZupLNc/q67WE3PzL6MJ ... grumble grumble |
| 11:07 |
* krvmga |
is trying to find a way to fit Dyrcona's comment into the tune of "I wanna be an airborne ranger". |
| 11:07 |
Dyrcona |
krvmga++ |
| 11:08 |
Dyrcona |
change it to "db admin" and it sorta works. |
| 11:08 |
krvmga |
lol |
| 11:09 |
krvmga |
anyway, am i right that opac default search location has to be tied to an account? |
| 11:09 |
dbs |
krvmga: no, it all depends |
| 11:09 |
krvmga |
am i wrong? or am i wrong? |
| 11:10 |
krvmga |
if not, how do i make it happen? |
| 11:10 |
dbs |
You can do all sorts of things. We use hostnames that redirect to include the locg parameter that sets the default search location, for example |
| 11:11 |
dbs |
See http://docs.evergreen-ils.org/2.5/_creating_a_new_skin_the_bare_minimum.html for a really simple approach (physical_loc) |
| 11:11 |
dbs |
But you can also see how http://laurentian.concat.ca redirects to http://laurentian.concat.ca/eg/opac/home?locg=105 |
| 11:12 |
krvmga |
our setup in cwmars is that everyone goes to bark.cwmars.org. this is different from, say, mvlc, where you can go to billerica.mvlc.org. |
| 11:12 |
dbs |
And I'm sure you can use IP-based Apache config settings to say "Oh, this kiosk is in this building, set its physical_loc to 999" |
| 11:13 |
dbs |
http://stackoverflow.com/questions/6025116/apache-http-rewrite-redirect-based-on-ip for a random example |
| 11:13 |
krvmga |
dbs++ |
| 11:14 |
dbs |
(of course that might end up always forcing locg to be 999, so experimentation required) |
| 11:14 |
krvmga |
dbs: thanks for all of that. i can't do it here. |
| 11:14 |
kmlussier |
krvmga: You can just add the locg parameter to the URL you use on the kiosk. |
| 11:14 |
dbs |
A really, really simple way of doing it would be to set the home page to http://hostname/locg=999 |
| 11:14 |
dbs |
err, http://hostname/?locg=999 |
| 11:14 |
krvmga |
kmlussier: yes, that's true. but it will only stick for the first search |
| 11:15 |
kmlussier |
Then maybe using physical location? |
| 11:15 |
* kmlussier |
tries to remember how you do that. |
| 11:15 |
dbwells |
Yes, same as above but with ?physical_loc=999 |
| 11:15 |
dbwells |
That should set a cookie. |
| 11:16 |
* krvmga |
is testing it now. |
| 11:16 |
kmlussier |
krvmga: Also see http://docs.evergreen-ils.org/2.3/_setting_the_default_physical_location_for_your_library_environment.html |
| 11:16 |
bshum |
krvmga: Maybe it's your kiosk software. I know some of those don't like remembering history/cookies |
| 11:16 |
kmlussier |
I had forgotten that you could set the cookie just by using the parameter in the URL. |
| 11:17 |
krvmga |
Internal Server Error |
| 11:18 |
krvmga |
kmlussier: i see it's an apache config. can't do that here. |
| 11:18 |
krvmga |
think we'd have to have a major discussion. |
| 11:19 |
dbwells |
krvmga: To me more clear, something like http://hostname/eg/opac/home?physical_loc=999 (where 999 is your OU id) |
| 11:19 |
kmlussier |
krvmga: But what dbwells suggested should work to set the cookie. |
| 11:19 |
kmlussier |
For example, http://bark.cwmars.org/eg/opac/home?physical_loc=150 |
| 11:20 |
krvmga |
kmlussier: i got internal server error |
| 11:20 |
dbs |
yes, but... I think if the apache config sets physical_loc as well, the apache config wins |
| 11:20 |
dbs |
that said, an internal server error should not happen at all |
| 11:20 |
kmlussier |
krvmga: Do you get an internal server error when you use that link I just posted? |
| 11:20 |
* dbs |
does not get an internal server error with that URL |
| 11:22 |
* krvmga |
recently discovered discrepancies among our brickheads. i wonder if the ISE was caused by something bad on one brickhead. |
| 11:22 |
* dbwells |
can also verify he is seeing "Preferred library: Agawam Public Library" with kmlussier's link, as expected |
| 11:22 |
dbs |
moi aussi |
| 11:23 |
* krvmga |
saw what i expected when i clicked kmlussier's link |
| 11:23 |
|
yboston joined #evergreen |
| 11:24 |
* krvmga |
hates getting intermittent and seemingly inexplicable 500 errors |
| 11:27 |
|
collum joined #evergreen |
| 11:38 |
csharp |
krvmga: do you have access to the server logs? |
| 11:38 |
bshum |
Or just test each brick individually |
| 11:39 |
csharp |
yeah - intermittent usually means a misconfigured brick |
| 12:02 |
bshum |
RIP Marque :) |
| 12:06 |
|
rfrasur joined #evergreen |
| 12:20 |
Dyrcona |
bshum: I need to see if it actually works as a file named marc_export. The link works just fine. |
| 12:25 |
Dyrcona |
So far, it appears to still work that way. |
| 12:25 |
Dyrcona |
I was concerned with the module name not matching the file name. |
| 12:25 |
Dyrcona |
Guess that only matters if you use a module. |
| 12:30 |
|
mllewellyn joined #evergreen |
| 12:41 |
|
fredp_ joined #evergreen |
| 12:41 |
|
mrpeters joined #evergreen |
| 12:41 |
|
jihpringle joined #evergreen |
| 12:57 |
|
mcooper joined #evergreen |
| 13:01 |
|
smyers_ joined #evergreen |
| 13:04 |
|
mrpeters left #evergreen |
| 13:15 |
Dyrcona |
dbs: If a style problem is causing that authority manage mess I shared above, I'm not finding it. |
| 13:16 |
Dyrcona |
I also don't see any changes in the relevant js and tt2 fiiles. |
| 13:22 |
Dyrcona |
Of course, I'm comparing git branches to git branches. |
| 13:22 |
Dyrcona |
What's in git might not necessarily be what is actually in production. |
| 13:42 |
jeffdavis |
On that note, I wrote something a little while back to check EG deployments for places where they vary from a git branch |
| 13:42 |
jeffdavis |
http://git.sitka.bclibraries.ca/gitweb/?p=sitka/sitka-tools.git;a=blob;f=deployment/integrity-checker.pl |
| 13:47 |
phasefx |
jeffdavis++ |
| 14:02 |
Dyrcona |
Looks handy. |
| 14:42 |
pastebot |
"jboyer-isl" at 64.57.241.14 pasted "Error during reingest for (seemingly) single record" (146 lines) at http://paste.evergreen-ils.org/13 |
| 14:43 |
jboyer-isl |
Does anyone who knows the ingest process fairly well have time to check that paste out? From what I can tell we have a single record that causes problems. I'd like to fix it (I assume this means it can't be found in the opac) but I can't see any potential problems. |
| 14:51 |
eeevil |
jboyer-isl: without the contents of your config.metabib_field and config.xml_transform, we can't really debug. but, it's almost certainly a bug in an xslt in config.xml_transform on a /very/ rare field (else we would have seen this error before) |
| 14:52 |
pastebot |
"csharp" at 64.57.241.14 pasted "marclint results for jboyer-isl's record" (11 lines) at http://paste.evergreen-ils.org/14 |
| 14:52 |
csharp |
so a couple of (apparently) invalid subfields? |
| 14:53 |
Dyrcona |
jeffdavis: No output from integrity-checker means everything checked is up to date, yeah? |
| 14:54 |
jboyer-isl |
There's a possibility. I just ran it through an xml validator (which can only do so much). I'll try just tearing those out on a test system and seeing if it saves correctly. If not, eeevil, I'll pull those tables if they're small enough and paste them separately. |
| 14:55 |
eeevil |
csharp: the 856$9 is ours, obv (located uris). the 500$0 looks odd |
| 14:56 |
eeevil |
jboyer-isl: config.xml_transform is not small :) |
| 14:56 |
jboyer-isl |
Shoot. I hadn't looked at it yet. :) |
| 14:58 |
jboyer-isl |
Ah-ha. That record would throw up an error if you just load it and click Save, change the 500$0 to something valid and it saves fine. Thanks for the help! |
| 14:58 |
jboyer-isl |
csharp++ |
| 14:58 |
jboyer-isl |
eeevil++ |
| 15:00 |
csharp |
and just for good measure... |
| 15:00 |
csharp |
marc-- |
| 15:00 |
csharp |
@karma marc |
| 15:00 |
pinesol_green |
csharp: Karma for "marc" has been increased 0 times and decreased 14 times for a total karma of -14. |
| 15:00 |
eeevil |
wow... the $0 killed one of the mods stylesheets, then. crazy |
| 15:03 |
|
krvmga joined #evergreen |
| 15:04 |
krvmga |
i got a question from a library: could they default to "Show All Details" in search returns? In the tt2 file, the detailed_records_view is set as a conditional. i don't think it can be done without more development. |
| 15:04 |
csharp |
jboyer-isl: we had about 20 records fail during the reingest - your issue reminds me that I had not gone back to see what happened with them ;-) |
| 15:05 |
krvmga |
i'm not sure why they'd want to default to show all details when their search is scope to their library. the search results would only show if their library had it or not. |
| 15:05 |
krvmga |
if they wanted to see if other libraries had the item, they would have to change the scope and re-do the search. |
| 15:06 |
krvmga |
in cwmars, we had discussions about this over a year ago. the result was that we moved almost all the data from the detailed_record_view into the regular search returns (except ISBN, ISSN and such) |
| 15:06 |
jboyer-isl |
csharp: sounds like if you're lucky a quick trip through marclint could make that easy. I'm definately going to have to look into that. |
| 15:06 |
jboyer-isl |
If not, then it sounds like pain all around. |
| 15:07 |
Dyrcona |
krvmga: What you're asking for would take development. |
| 15:07 |
bshum |
krvmga: In our consortium, we also eliminated the "more details" view from our search results and use customized elements bridging what was in more details and less. |
| 15:07 |
krvmga |
Dyrcona: that's what i figured. |
| 15:07 |
bshum |
I just keep those in our custom build branches along with the rest of our changes |
| 15:08 |
bshum |
Probably not so easy to take apart these days |
| 15:08 |
dbs |
krvmga: we default to Show All Details |
| 15:08 |
dbs |
It didn't take much effort |
| 15:08 |
krvmga |
bshum: i had originally suggested for us to do away with show more details. |
| 15:08 |
krvmga |
dbs: what do you do? |
| 15:08 |
Dyrcona |
Well, I didn't say it would be hard. :) |
| 15:08 |
krvmga |
dbs: and that's the default for everyone, right? not just for one library? |
| 15:11 |
dbs |
krvmga: yes, but it was just a template customization. we applied it to everyone at a customization layer because it makes sense for everyone |
| 15:12 |
krvmga |
dbs: thanks |
| 15:13 |
dbs |
yeah, it's just show_more_details.default = 'false'; |
| 15:13 |
dbs |
in config.tt2 |
| 15:13 |
dbs |
switch that to 'true' and you should be golden |
| 15:14 |
Dyrcona |
OOf. |
| 15:14 |
krvmga |
dbs: if i switch that to true, something nasty will hit the fan. we would need to have a consortium-wide decision to do this. but it's good to know. |
| 15:14 |
* Dyrcona |
is wrong again. |
| 15:14 |
* Dyrcona |
should know better. |
| 15:14 |
dbs |
krvmga: oh right, because you don't have site-specific templates? |
| 15:14 |
krvmga |
dbs: right. if we did, this wouldn't be an issue. |
| 15:15 |
dbs |
originally creating the show_more_details.default setting took dev effort! /me remembers it well |
| 15:15 |
dbs |
or fuzzily |
| 15:16 |
dbs |
berick++ # wcag enhancements |
| 15:16 |
dbs |
nrcan++ # also |
| 15:16 |
graced |
nrcan++ indeed |
| 15:17 |
krvmga |
dbs: when you said that, i laughed because it made me think of this: Agador: Good eve-e-ning. May I take jour purse as usual... or for the first tine? |
| 15:17 |
|
stevenyvr joined #evergreen |
| 15:18 |
* dbwells |
is really happy to see "Packed posting lists in GIN" as committed for PG 9.4. Progress! |
| 15:18 |
dbs |
Yeah! Now if only we could get 9.3 working for us :) |
| 15:23 |
csharp |
eeevil: I can confirm that several of our records also choked on 500$0, jsyk |
| 15:40 |
Dyrcona |
bshum++ # for telling me about a feature I should have known was there. |
| 16:01 |
|
hopkinsju joined #evergreen |
| 16:12 |
|
smyers_ joined #evergreen |
| 16:18 |
jl- |
it says for Debian Suqqeze, to add the backports to the sources.list, is the same true when using debian Wheezy? |
| 16:18 |
jl- |
Wheezy is the latest stable |
| 16:26 |
csharp |
jl-: wheezy has postgresql 9.1, so I don't think backports will be necessariy |
| 16:26 |
csharp |
er.. necessary |
| 16:26 |
jl- |
ok |
| 16:49 |
|
yboston_ joined #evergreen |
| 16:57 |
|
afterl left #evergreen |
| 17:14 |
|
mmorgan left #evergreen |
| 17:15 |
dbs |
well dang: http://pastebin.com/S8FkKev8 - hold placement sql bug in master + array_agg changes |
| 17:15 |
dbs |
now to find out if the problem is the array_agg changes or just plain master |
| 17:15 |
bshum |
Uh oh |
| 17:16 |
dbs |
the error doesn't look array_agg-related |
| 17:16 |
bshum |
It doesn't |
| 17:17 |
* dbs |
waits for the little VM to rebuild a clean schema |
| 17:18 |
bshum |
Not much has touched those in awhile though |
| 17:18 |
dbs |
Nope. Looks like it's a pure bug in master. |
| 17:19 |
dbs |
Maybe postgresql 9.3 got more picky about columns? |
| 17:19 |
bshum |
Could be. |
| 17:19 |
bshum |
I need to try my own upgrade SQL |
| 17:19 |
bshum |
I think we're on PG 9.1 still |
| 17:23 |
|
Bmagic joined #evergreen |
| 17:23 |
Bmagic |
Hey everyone, got a billing question. We have noticed that money.billing and money.payments have rows that point to xact id's that dont exist in money.billable_xact |
| 17:25 |
dbs |
opened bug 1277731 - plowing ahead with array_agg testing |
| 17:25 |
pinesol_green |
Launchpad bug 1277731 in Evergreen "Hold tests failure" (affected: 1, heat: 6) [Critical,New] https://launchpad.net/bugs/1277731 |
| 17:26 |
dbs |
Bmagic: maybe in one of the Child tables: action.circulation, booking.reservation, money.grocery |
| 17:26 |
Bmagic |
dbs: thanks, i'll check |
| 17:26 |
dbs |
oh wait, I may be drunk |
| 17:28 |
dbs |
Yes, drunk. SELECT on the parent should show all of the rows from children |
| 17:29 |
dbs |
Sorry for the noise |
| 17:30 |
Bmagic |
dbs: that is what I was thining. So money.billable_xact will contain all of the rows from money.grocery, booking.reservation and action.circulation right? |
| 17:31 |
Bmagic |
select * from money.billing where xact not in(select id from money.billable_xact) order by billing_ts desc (6992 rows returned) |
| 17:35 |
dbs |
Bmagic: do you purge circulations? |
| 17:35 |
dbs |
If so, that's probably why |
| 17:35 |
Bmagic |
dbs: we do not purge circulations - some of these are only 2 months old |
| 17:35 |
Bmagic |
dbs: furthermore, we have payments for transactions that don't exist just 2 hours ago! |
| 17:38 |
Bmagic |
dbs: I am activly looking into the db, I just wanted to see if anyone knew of any reason that rows would be deleted from billable_xact. Does the staff client have code to remove rows from that table? |
| 17:39 |
dbs |
Bmagic: Not sure off-hand; circulation purging was the best thing that came to mind |
| 17:39 |
Bmagic |
dbs: no problem, I will keep looking |
| 17:40 |
bshum |
Bmagic: So you don't have anything in action.aged_circulation? |
| 17:40 |
bshum |
Stuff could end up there when obliterating patrons (aka, deleting them) |
| 17:42 |
bshum |
I think |
| 17:42 |
bshum |
At least that's where I think circs go to die when we obliterate patrons |
| 17:42 |
* dbs |
glares at "Sibelius, Jean 1865-1957 creator" in metabib.author_field_entry... I guess "creator" is coming from the MODS transform. Lots of those. blech. |
| 17:43 |
bshum |
dbs: oy |
| 17:43 |
dbs |
could be another postgresql xslt change in 9.3 |
| 17:45 |
Bmagic |
bshum: select xact from money.payment where xact not in(select id from money.materialized_billable_xact_summary) order by payment_ts desc [382 rows] select id from action.aged_circulation where id in(select xact from money.payment where xact not in(select id from money.materialized_billable_xact_summary) order by payment_ts desc) [170 rows] |
| 17:46 |
Bmagic |
bshum: So, there are 382 payments made for transactions that dont exist. 170 of those missing show up in aged_circulation.... Keep in mind, our database says that some of these payments were made as recently as 3 hours ago! |
| 17:50 |
|
hopkinsju joined #evergreen |
| 17:58 |
dbs |
bshum: ruh-roh : http://pastebin.com/iLa3bpUZ |
| 17:59 |
bshum |
dbs: Wow, it just doesn't like it. |
| 18:03 |
dbs |
well, in this case we can cast id::text and 0 to '0' but I'll take a closer look |
| 18:05 |
dbs |
That was in d80e70c48 |
| 18:07 |
dbs |
But I'm going to want to confirm that that's the same as the original |
| 18:11 |
dbs |
Yep, looks the same. |
| 18:20 |
* dbs |
discovers he was missing bshum's latest commit. sheesh |
| 18:28 |
bshum |
There were so many of them. |
| 18:28 |
bshum |
Yours mostly. |
| 18:28 |
bshum |
Sigh |
| 18:29 |
* bshum |
wanders home |
| 18:38 |
dbs |
calling 0855 |
| 18:49 |
pinesol_green |
Showing latest 5 of 12 commits to Evergreen... |
| 18:49 |
pinesol_green |
[evergreen|Dan Scott] Keep dropping and creating array_accum() - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=e6eb17a> |
| 18:49 |
pinesol_green |
[evergreen|Ben Shum] Found a few last functions that need changing to native SQL - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=c546e88> |
| 18:49 |
pinesol_green |
[evergreen|Ben Shum] Add upgrade script for changeover to array_agg() and string_agg() - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=3e2a33a> |
| 18:49 |
pinesol_green |
[evergreen|Dan Scott] Tweak STRING_AGG() arguments (expects TEXT or BYTEA) - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=ecf5858> |
| 18:49 |
pinesol_green |
[evergreen|Dan Scott] Sign off on upgrade script for (STRING|ARRAY)_AGG - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=6677228> |
| 18:50 |
|
hopkinsju joined #evergreen |
| 18:59 |
|
smyers_ joined #evergreen |
| 19:24 |
bshum |
dbs++ yay! |
| 19:26 |
bshum |
I'll try rebuilding clean master now to see if those bugs crop up for me on PG 9.1 and Ubuntu. |
| 19:26 |
bshum |
After dinner. |
| 20:21 |
eeevil |
dbs: the column error is a 9.3 change to plpgsql. variable name resolution was changed a little, it got more predictable and complains in some cases that it didn't before |
| 20:26 |
|
bshum joined #evergreen |
| 20:29 |
eeevil |
dbs: between that and the indexing bug (pg side bug) i wouldnt vote to call 9.3 supported for EG yet |
