Time |
Nick |
Message |
00:19 |
jeffdavis |
thanks! |
02:56 |
|
HoloIRCUser joined #evergreen |
03:03 |
|
HoloIRCUser3 joined #evergreen |
03:04 |
|
HoloIRCUser4 joined #evergreen |
03:11 |
|
HoloIRCUser joined #evergreen |
03:14 |
|
HoloIRCUser joined #evergreen |
07:33 |
|
rjackson_isl joined #evergreen |
08:13 |
|
collum joined #evergreen |
08:14 |
|
mrpeters joined #evergreen |
08:42 |
|
jeff_ joined #evergreen |
08:50 |
|
jeff_ joined #evergreen |
08:50 |
|
jwoodard joined #evergreen |
08:56 |
|
maryj joined #evergreen |
09:09 |
csharp |
@whocares perl |
09:09 |
pinesol_green |
paxed and jboyer-isl hate perl |
09:09 |
csharp |
perl+- |
09:10 |
csharp |
perl_oneliners++ |
09:49 |
|
yboston joined #evergreen |
09:52 |
tsbere |
csharp: Sometimes the one liners are more of a pain than a help ;) |
10:27 |
|
mmorgan joined #evergreen |
11:00 |
|
sarabee joined #evergreen |
11:06 |
|
_bott_ joined #evergreen |
11:13 |
berick |
huh, never noticed action.circulation.create_time before. |
11:13 |
berick |
(or at least i don't remember it) |
11:17 |
miker |
berick: IIRC, it differentiates from xact_start that is set by offline upload |
11:17 |
berick |
oh, that would make sense |
11:18 |
|
edoceo joined #evergreen |
11:20 |
berick |
guess it was never used. offline sends checkout API a 'checkout_time' value, which is used to modify xact_start directly. |
11:20 |
berick |
oh, but..yeah |
11:20 |
berick |
in that case, create_time would represent the real create time |
11:21 |
berick |
makes sense |
11:26 |
miker |
aye |
11:30 |
|
jlundgren joined #evergreen |
11:32 |
|
Christineb joined #evergreen |
11:36 |
|
bmills joined #evergreen |
11:50 |
bshum |
So B&T weirdness |
11:53 |
bshum |
Apparently they want to use two different SAN numbers, one for print materials, and one for AV materials ordering. |
11:53 |
bshum |
I'm wondering if that's something we can write into PO JEDI somehow |
11:54 |
bshum |
To change out the SAN if it sees a particular SAN + vendcode combination |
11:54 |
bshum |
Alternatively, I'm wondering if they should somehow be two different providers? With two different SANs |
11:54 |
berick |
IIRC, most people use 2 different providers |
11:55 |
berick |
possibly w/ the same edi_account |
11:57 |
bshum |
Hmm |
11:57 |
bshum |
A purchase order can only have one provider though right? |
11:58 |
berick |
right |
11:58 |
bshum |
Maybe that's the reason they don't like the idea of two separate providers |
11:58 |
|
jboyer-laptaupe joined #evergreen |
12:00 |
bshum |
Oh |
12:00 |
bshum |
Weird |
12:00 |
bshum |
The problem is the library SAN |
12:01 |
bshum |
So they want the org unit SAN to be one thing for print, and one thing for AV |
12:01 |
bshum |
They already do order different purchase orders with different providers for that |
12:02 |
|
krvmga joined #evergreen |
12:03 |
krvmga |
if i make a change to 012.schema.vandelay.sql, will the change automatically be picked up or do i have to run a script to insure it gets picked up? |
12:04 |
berick |
bshum: weird. i wonder what difference that makes to B&T. |
12:04 |
berick |
krvmga: you have to create an upgrade script to implement the change |
12:04 |
bshum |
berick: It's probably some silly accounting thing with their wacky software |
12:05 |
berick |
krvmga: see Open-ILS/src/sql/Pg/upgrade/ |
12:06 |
krvmga |
berick: <now looking in that directory> |
12:08 |
krvmga |
i want to removed three lines of code from vandelay.overlay_bib_record to put a bandaid on https://bugs.launchpad.net/evergreen/+bug/1447746 |
12:08 |
pinesol_green |
Launchpad bug 1447746 in Evergreen "Do not update bib source on match-only merge" [Undecided,New] |
12:09 |
krvmga |
bshum did this, too, i think |
12:09 |
krvmga |
bshum: am i remembering that right? |
12:10 |
bshum |
krvmga: Eh........... huh? |
12:11 |
bshum |
krvmga: Oh, reading the bug, yes, I did what I said I did there. |
12:14 |
krvmga |
bshum: what was in your upgrade script? |
12:16 |
bshum |
krvmga: I didn't make one |
12:16 |
|
afterl joined #evergreen |
12:16 |
bshum |
I just edited the function directly via PGadmin and then ran it |
12:17 |
krvmga |
bshum: we don't use that in production :( |
12:17 |
krvmga |
berick: what would you suggest i do? |
12:18 |
bshum |
krvmga: It's pretty easy to make an upgrade script |
12:18 |
bshum |
All you do is copy the entire function that you want from out of the main file |
12:18 |
bshum |
And then make the change to it |
12:18 |
bshum |
And then run it |
12:19 |
bshum |
So the function to be altered is in my comment |
12:19 |
bshum |
vandelay.overlay_bib_record |
12:20 |
bshum |
So you would copy the entire function out of the schema file |
12:20 |
bshum |
And put it into its own .sql script file |
12:20 |
bshum |
And then edit and remove the lines that I specified in my comment |
12:21 |
pastebot |
"bshum" at 64.57.241.14 pasted "vandelay.overlay_bib_record (and only that)" (60 lines) at http://paste.evergreen-ils.org/12 |
12:21 |
bshum |
krvmga: You could wrap it with a BEGIN; COMMIT; at the start and finish if you'd prefer |
12:21 |
bshum |
But otherwise, that's the content |
12:22 |
krvmga |
bshum: does this take a long time to run? |
12:22 |
bshum |
krvmga: That's just a CREATE OR REPLACE function |
12:22 |
bshum |
It should be fast. |
12:22 |
krvmga |
thanks. |
12:22 |
bshum |
Cause all you're doing is altering what the database does when it calls that action |
12:22 |
krvmga |
bshum++ |
12:22 |
krvmga |
berick++ |
12:22 |
bshum |
You're not changing data |
12:23 |
bshum |
And any previously affected bibs will not go back to their old sources, whatever |
12:23 |
berick |
krvmga: here's a fairly simple, self-contained example of applying a change to a SQL file and adding an upgrade script: http://git.evergreen-ils.org/?p=Evergreen.git;a=commitdiff;h=54eb62a68268768bdb44b04459376f4c11c2381f |
12:23 |
bshum |
It just stems the issue from happening further. |
12:23 |
pinesol_green |
[evergreen|Dan Wells] LP#1419172 Optimize full_circ_count view to avoid seq scans - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=54eb62a> |
12:23 |
krvmga |
thanks! :) |
12:23 |
berick |
in this case it's a view, but it's the same process for functions |
12:24 |
krvmga |
bshum: what i'll do is compare our current vandelay.overlay_bib_record with what you just pasted and make changes accordingly |
12:25 |
bshum |
krvmga: Yes, you need to use your function |
12:25 |
bshum |
Cause the one I pasted is from master |
12:25 |
bshum |
And there may be... other changes in there |
12:25 |
bshum |
Depending on what version of Evergreen you're on |
12:25 |
bshum |
That's why I said to use the one from your database :D |
12:45 |
|
nihajsk joined #evergreen |
12:52 |
|
jihpringle joined #evergreen |
12:54 |
|
bmills joined #evergreen |
12:56 |
bshum |
@dessert add Mint Truffle Hershey Kisses |
12:56 |
pinesol_green |
bshum: The operation succeeded. Dessert #42 added. |
12:56 |
bshum |
mceraso's having more fun than I am :) |
13:41 |
|
maryj joined #evergreen |
13:45 |
|
rlefaive joined #evergreen |
13:53 |
|
rfrasur joined #evergreen |
14:03 |
rfrasur |
Is there an EOB meeting today? Have I missed a memo (distinct possibility)? |
14:14 |
jihpringle |
rfrasur: tomorrow, same time |
14:15 |
jihpringle |
sorry, I'm thinking EG for Academics - don't know about EOB |
14:15 |
rfrasur |
Hmm, I think I'm a week early... |
14:16 |
rfrasur |
And then we're at Christmas. Yeah. I've lost the plot. |
14:17 |
rfrasur |
thanks, jihpringle :-) |
14:19 |
gmcharlt |
♫ on the first day of Christmas, my true gave to me: a cancelled meeting for free ♫ |
14:19 |
gmcharlt |
or something like that? ;) |
14:39 |
|
lualaba joined #evergreen |
14:40 |
lualaba |
Hello google_analytics.enabled = 'true' in config.tt2, but problem with google indexing. could you suggest what is reason? |
14:40 |
berick |
@decide partridge no-meeting |
14:40 |
pinesol_green |
berick: go with partridge no-meeting |
14:40 |
berick |
heh |
14:40 |
lualaba |
SSL is configured |
15:03 |
lualaba |
i generate sitemap but only google only 60 records |
15:04 |
tsbere |
lualaba: I was under the impression that analytics was for stats generation. Indexing is a different story entirely and doesn't happen right away. |
15:07 |
lualaba |
what should be reason? |
15:10 |
tsbere |
lualaba: You generally just need to wait for google's indexer to come around again. |
15:10 |
lualaba |
Thank you |
15:11 |
tsbere |
lualaba: You may be able to use tools google provides to ask google to come around sooner. Try searching for "request crawl" or something like that on google? |
15:12 |
lualaba |
yes we already did, but strange that google make indexing very slow |
15:13 |
tsbere |
They index a very large number of pages. Even adding you to the queue *right then* could take a while. |
15:14 |
lualaba |
i need to be sure that is not Evergreen problem |
15:53 |
|
bmills joined #evergreen |
15:55 |
csharp |
@eightball was it all just a dream? |
15:55 |
pinesol_green |
csharp: The outlook is good. |
15:56 |
dbs |
lualaba: google might think that the catalogue pages don't offer very much valuable content and ignore it |
15:56 |
dbs |
I've watched our catalogue's indexed pages slowly decline from a peak last january of 1 million pages down to (currently) about 167,000. *sigh* |
15:58 |
lualaba |
we can make something? |
16:02 |
|
jlitrell joined #evergreen |
16:06 |
dbs |
lualaba: https://plus.google.com/u/0/+DanScottCAN/posts/gtn2DhnDQmx is relevant |
16:06 |
dbs |
or more correctly https://plus.google.com/+DanScottCAN/posts/gtn2DhnDQmx |
16:06 |
lualaba |
თჰანკ ყოუ |
16:06 |
lualaba |
Thank you |
16:22 |
|
rlefaive joined #evergreen |
16:30 |
|
bmills1 joined #evergreen |
16:31 |
|
bmills2 joined #evergreen |
16:35 |
|
rlefaive joined #evergreen |
17:13 |
|
mmorgan left #evergreen |
17:56 |
|
jlitrell joined #evergreen |
21:49 |
|
bmills joined #evergreen |
22:00 |
|
sarabee joined #evergreen |