| Time |
Nick |
Message |
| 00:12 |
|
zerick joined #evergreen |
| 01:06 |
|
Mark__T joined #evergreen |
| 07:28 |
|
timf joined #evergreen |
| 07:40 |
|
jboyer-isl joined #evergreen |
| 07:57 |
|
shadowspar joined #evergreen |
| 08:05 |
|
adbowling-isl joined #evergreen |
| 08:12 |
|
gdunbar joined #evergreen |
| 08:22 |
bshum |
csharp: I remember that bug re: custom views. Back then, I started mocking up a branch to remove the stuff that's super custom like having field entries for statcats by id. |
| 08:23 |
bshum |
Maybe if we finished generically adjusting the default build or adding in some line (and official) documentation to show folks how it works. |
| 08:23 |
|
mrpeters joined #evergreen |
| 08:24 |
bshum |
Patches welcome ;) I'll note this on the LP bug a little bit later. |
| 08:24 |
csharp |
yes - I'd like the custom views to be 1) as generically applicable as possible and 2) correct ;-) |
| 08:25 |
csharp |
PINES libraries "need" the "legacy_stat_cat" stuff, but that can be maintained locally |
| 08:25 |
csharp |
I know the intention was to phase those out eventually, but they became permanent ;-) |
| 08:25 |
bshum |
Well, we couldn't run the SQL cause we don't have a stat cat with id 2. :P |
| 08:25 |
csharp |
(as so many things like that do) |
| 08:25 |
csharp |
heh |
| 08:25 |
bshum |
That's what led me to poke at it. |
| 08:26 |
bshum |
If I have a moment later this morning, I'll dust off my branch. |
| 08:27 |
csharp |
I believe 'LEFT JOIN actor.card circ_card ON circ_u.card = circ_card.id' will accomplish what I'm trying to fix |
| 08:27 |
csharp |
since users can have multiple active cards now too |
| 08:27 |
* csharp |
is testing the view query now |
| 08:28 |
csharp |
oh, and for the logs, we're discussing bug 1072892 |
| 08:28 |
pinesol_green |
Launchpad bug 1072892 in Evergreen "reporter.classic_item_list view creates repeated rows" (affected: 1, heat: 6) [Undecided,Incomplete] https://launchpad.net/bugs/1072892 |
| 08:28 |
bshum |
csharp++ |
| 08:29 |
|
kbeswick joined #evergreen |
| 08:29 |
csharp |
the other problems with the view are that 1) it doesn't count aged circs in its circ count and 2) it pulls bib stuff in a pre-reporter.materialized_simple_record way |
| 08:30 |
bshum |
rmsr has its own quirky issues for me. |
| 08:30 |
bshum |
But I know what you mean. |
| 08:30 |
csharp |
so it's a bit-rotted, old, decrepit thing that I've decided to try rescuing rather than shooting it dead ;-) |
| 08:32 |
* csharp |
recalls the Larry the Cable Guy joke about having to shoot his horse with a broken leg - "So now it's got a broken leg and a gunshot wound. I don't know why they tell you to shoot horses with that happens.." |
| 08:36 |
|
rsinger_ joined #evergreen |
| 08:37 |
|
collum joined #evergreen |
| 08:46 |
|
mmorgan joined #evergreen |
| 08:47 |
|
Shae joined #evergreen |
| 08:53 |
|
ericar joined #evergreen |
| 09:13 |
|
rfrasur joined #evergreen |
| 09:30 |
|
mllewellyn joined #evergreen |
| 09:35 |
|
rfrasur joined #evergreen |
| 09:37 |
csharp |
hmm - where is the last() postgresql function defined? |
| 09:38 |
bshum |
My gut instinct is to say public or evergreen schemas |
| 09:39 |
* rfrasur |
got a 2nd monitor working with no clue how. |
| 09:44 |
* csharp |
sees last_agg(anyelement, anyelement) in the public schema |
| 09:45 |
bshum |
bbde818fd9fe255e83da5fa896fcd31993f9b59e |
| 09:45 |
pinesol_green |
[evergreen|miker] first() and last() aggregates - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=bbde818> |
| 09:46 |
csharp |
bshum++ # thanks |
| 09:46 |
|
RoganH joined #evergreen |
| 09:47 |
|
yboston joined #evergreen |
| 09:47 |
jeff |
which is shown in the postgresql wiki, here: http://wiki.postgresql.org/wiki/First/last_(aggregate) |
| 09:49 |
csharp |
jeff: yeah - I see that too - I wasn't seeing the last() wrapper on the first reading |
| 09:49 |
csharp |
and pgadmin3 isn't showing aggregates (that I see at this moment, anyway) |
| 09:50 |
dbs |
Open-ILS/src/sql/Pg/002.functions.aggregate.sql |
| 09:50 |
csharp |
well I believe I've found a bug around last()'s usage in money.transaction_billing_summary |
| 09:50 |
dbs |
whoops, too late |
| 09:50 |
dbs |
bshum++ |
| 09:52 |
csharp |
it appears to be showing the last billing note and billing type *alphabetically*, not chronologically as the end user expects (and as implied by use of max() on the last billing date, seems like the developer expected that too) |
| 09:52 |
* csharp |
is working up a bug report |
| 09:54 |
|
moodaepo_nb joined #evergreen |
| 10:02 |
eeevil |
csharp: actually, the use of last() there is just to get /any/ billing type, we don't care which ... or, rather, we couldn't care which, inexpensively, when the view was written originally because there were no window functions. there are now, so we can care cheaply. |
| 10:02 |
|
kivilahtio joined #evergreen |
| 10:03 |
kivilahtio |
Hi folks! |
| 10:03 |
kivilahtio |
Does anyone have experience running EG in a virtual container? |
| 10:04 |
kivilahtio |
like KVM? Using port forwarding to reach Evergreen services via a static ip in the virtualization host |
| 10:04 |
bshum |
Evergreen, yes. Postgres, not really. |
| 10:04 |
kivilahtio |
bshum: Great!! |
| 10:04 |
bshum |
PINES is using KVM I think, and so are we. |
| 10:05 |
bshum |
There's some other folks out there using xen too. |
| 10:05 |
csharp |
yes, all but our DB servers are kvm guests |
| 10:05 |
csharp |
Indiana uses xen |
| 10:05 |
kivilahtio |
I am having error 500's when trying to open the first page |
| 10:05 |
bshum |
csharp: Your DB servers are KVM too? |
| 10:05 |
csharp |
all but |
| 10:05 |
* bshum |
is a little intimidated by that. |
| 10:05 |
kivilahtio |
I have forwarded ports 80 -> 80 and 443 -> 443 |
| 10:05 |
bshum |
Oh, all but |
| 10:05 |
bshum |
Gotcha :D |
| 10:06 |
kivilahtio |
should this be enough if I am running Evergreen and PostgreSQL all in one domain? |
| 10:06 |
csharp |
yeah - I'd like to look into virtualizing the DB servers in the future |
| 10:06 |
kivilahtio |
Just checking since I am getting no errors in my logs. |
| 10:06 |
* tsbere |
never virtualizes heavily used DB servers due to filesystem lag |
| 10:07 |
csharp |
kivilahtio: hmm - I've not tried that |
| 10:07 |
kivilahtio |
tsbere: We are planning to run db from RAM + SSD, so might not be a biggie |
| 10:07 |
csharp |
kivilahtio: I would look into using LVS and bridged networking |
| 10:08 |
tsbere |
kivilahtio: When it comes to your errors, the reason may not be reported to Apache. Check for errors in your opensrf logs? |
| 10:08 |
kivilahtio |
csharp: there is a network bridge for outbound traffic, but the ports need to be forwarded for inbound traffic |
| 10:08 |
csharp |
I see |
| 10:08 |
* tsbere |
ran into errors recently with not having something that was needed for a perl module, which bubbled back to apache |
| 10:09 |
kivilahtio |
tsbere:thanks, a good point, found something from /var/log/apache2 |
| 10:09 |
kivilahtio |
I installed OpenSRF and EG on top of a Ubuntu Server 12.04 virtual server installation, (not the full server installation) |
| 10:10 |
kivilahtio |
so was thinking I should encounter some missing binaries |
| 10:11 |
|
dboyle joined #evergreen |
| 10:11 |
csharp |
eeevil: thanks - I'll look into window functions |
| 10:12 |
|
CarrieC joined #evergreen |
| 10:17 |
pastebot |
"eeevil" at 204.193.129.146 pasted "possible replacement for csharp" (9 lines) at http://paste.evergreen-ils.org/14 |
| 10:17 |
csharp |
eeevil++ |
| 10:18 |
csharp |
I'll test it |
| 10:18 |
eeevil |
csharp: there are many more than that one to convert, of course. and I'm testing on an empty db, so the syntax works but we may need to add window range conditions |
| 10:18 |
csharp |
good to know |
| 10:25 |
|
mcooper joined #evergreen |
| 10:26 |
csharp |
eeevil: that returns a list of rows rather than a single row (though the last one has the correct total owed) |
| 10:31 |
eeevil |
csharp: gotcha. so we're moving in the right direction. you feel like expanding your brain with window functions? :) |
| 10:31 |
csharp |
sure ;-) |
| 10:31 |
* csharp |
tried group by, but those aren't being treated like aggregates apparently |
| 10:32 |
tsbere |
I don't think you are going to get a single row with window functions, as I believe they operate over the set of returned rows.... |
| 10:32 |
* tsbere |
could be wrong, he doesn't play with window functions that often |
| 10:34 |
eeevil |
tsbere: you can with a group-by. obv |
| 10:36 |
eeevil |
or by using the current window-y query in a subselect, of course, with an outer group-by/order-by. that's probably the simplest way |
| 10:36 |
tsbere |
eeevil: I think group by is applied before window functions (outside of subselect fun, obviously) |
| 10:42 |
eeevil |
tsbere: yep |
| 10:52 |
eeevil |
csharp: I found a tuit! I believe you just want to add a frame clause (range condition) to the window clause: WINDOW w AS (PARTITION BY xact ORDER BY billing_ts ROWS BETWEEN UNBOUNDED PRECEDING AND UNBOUNDED FOLLOWING) |
| 10:54 |
csharp |
that works, but it's now showing the correct row 51 times (51 billings) |
| 10:55 |
|
jbfink joined #evergreen |
| 10:55 |
eeevil |
hah ... that's easy to correct: SELECT DISTINCT |
| 10:56 |
csharp |
excellent |
| 10:56 |
csharp |
eeevil++ |
| 11:33 |
csharp |
eeevil: oh wow, I see what you mean about converting the many others with last() |
| 11:36 |
|
_zerick_ joined #evergreen |
| 11:38 |
|
zerick joined #evergreen |
| 11:47 |
jboyer-isl |
csharp: Do you ever have odd clock issues with KVM? We occasionally run into a delightful xen bug where the host will for no reason jump 50 minutes into the future (brining all of the machines it hosts with it). Not great when digging through logs. |
| 11:48 |
kivilahtio |
jboyer-isl: for us using xen the whole Domain crashed and couldn't be shut down every time during data migration. We'll soon see if the problem persists with KVM ;) |
| 11:50 |
csharp |
jboyer-isl: no, we've not seen that - wild |
| 11:50 |
bradl |
jboyer-isl: we see that problem sometimes |
| 11:50 |
bradl |
supposedly fixed in a newer version of xen |
| 11:51 |
|
jdouma joined #evergreen |
| 11:51 |
jboyer-isl |
I saw that too, but the supposedly part doesn't instill lots of confidence. :) |
| 11:51 |
bradl |
kivilahtio: I've seen instances under high i/o load become totally unresponsive... |
| 11:52 |
mrpeters |
jboyer-isl: pm |
| 12:01 |
|
acoomes joined #evergreen |
| 12:09 |
|
acoomes_ joined #evergreen |
| 12:11 |
|
smyers_ joined #evergreen |
| 12:13 |
bshum |
Just thinking aloud with the Wordpress conversion |
| 12:14 |
bshum |
I was thinking we should keep around the old PHP pages as best as we can. Maybe under a new subdomain (with some minor tweaking to let that work) |
| 12:14 |
tsbere |
For how long? |
| 12:14 |
bshum |
Not forever, not everything will work perfectly. |
| 12:14 |
bshum |
Alongside, we'll probably be doing a wiki update |
| 12:15 |
bshum |
I'm thinking maybe a few weeks or something |
| 12:19 |
gmcharlt |
bshum: yeah, I think keeping the period intentionally short would be a good idea |
| 12:26 |
bshum |
gmcharlt: Sounds good. I can get by either way, just stressing the details now that the cutover is coming up. |
| 12:27 |
gmcharlt |
bshum++ # stressing so that the rest of us don't have to! ;) |
| 12:31 |
|
smyers__ joined #evergreen |
| 12:33 |
|
CarrieC joined #evergreen |
| 12:37 |
bshum |
Dyrcona++ |
| 12:49 |
|
stevenyvr2 joined #evergreen |
| 13:15 |
|
kmlussier joined #evergreen |
| 13:19 |
csharp |
eeevil: I've been working on the other money views. The only ones I'm unsure how to approach conversion with are money.billable_xact_summary_new and money.billable_xact_with_void_summary since they are pretty complicated with subqueries |
| 13:20 |
|
dboyle joined #evergreen |
| 13:24 |
eeevil |
csharp: I don't have time to look currently, but I would say toss the ones you have up as a branch for testing and signoff and we can address the remainders later |
| 13:24 |
eeevil |
csharp++ |
| 13:25 |
csharp |
will do - thanks for your help! |
| 13:26 |
|
Dyrcona joined #evergreen |
| 13:35 |
|
timf joined #evergreen |
| 13:47 |
|
CarrieC joined #evergreen |
| 14:05 |
|
rfrasur joined #evergreen |
| 14:29 |
|
BigRig joined #evergreen |
| 14:36 |
|
kbeswick joined #evergreen |
| 14:39 |
|
tfaile joined #evergreen |
| 14:40 |
|
rfrasur joined #evergreen |
| 14:59 |
rfrasur |
Every now and then, Firefox reminds my why it's so awesome (even if other browsers can do the same thing). |
| 15:08 |
pinesol_green |
[evergreen|Thomas Berezansky] Fix error on deleted hold in transit - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=dae5f2a> |
| 15:17 |
|
mllewellyn joined #evergreen |
| 15:26 |
|
stevenyvr2 joined #evergreen |
| 15:42 |
|
mcooper joined #evergreen |
| 16:23 |
Phenol |
When trying to checkout a book I get error "no_matchpoint" what does this mean? |
| 16:24 |
Dyrcona |
It means there is no entry in config.circ_matrix_matchpoint in the database that matches your book, patron, library combination. |
| 16:25 |
tsbere |
ALT: The circulate flag, duration rule, and fine rules aren't set on the matchpoint (or set thereof) |
| 16:25 |
tsbere |
(when dealing with fallthrough, anyway) |
| 16:25 |
Dyrcona |
Go to Admin->Local Administration->Circulation Policies to see what you've got and add new entries. |
| 16:26 |
Phenol |
Ewww its empty.. how did this happen :( |
| 16:27 |
Dyrcona |
I think it comes empty out of the box. |
| 16:27 |
tsbere |
I thought it came with one default rule |
| 16:28 |
Dyrcona |
Oh. Maybe it does. |
| 16:28 |
Dyrcona |
I always mess with this in the database anyway. ;) |
| 16:44 |
|
dboyle joined #evergreen |
| 17:05 |
|
mllewellyn joined #evergreen |
| 17:15 |
|
mmorgan left #evergreen |
| 17:54 |
|
CarrieC left #evergreen |
| 18:06 |
|
fparks_ joined #evergreen |
| 19:14 |
|
stevenyvr2 left #evergreen |
| 19:22 |
|
mtcarlso- joined #evergreen |
| 21:03 |
|
Pibbits joined #evergreen |
| 21:06 |
gsams |
has anyone ever had cause to clone a production system from one server to another using a tool like clonezilla? |
| 21:06 |
gsams |
both systems being identical |
