| Time |
Nick |
Message |
| 01:15 |
|
zerick joined #evergreen |
| 04:09 |
|
gsams joined #evergreen |
| 04:16 |
|
berickm joined #evergreen |
| 04:45 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 07:11 |
|
collum joined #evergreen |
| 07:15 |
|
kbeswick joined #evergreen |
| 07:48 |
|
rjackson-isl joined #evergreen |
| 08:01 |
|
tspindler joined #evergreen |
| 08:04 |
|
jboyer-home joined #evergreen |
| 08:18 |
|
kmlussier joined #evergreen |
| 08:22 |
|
akilsdonk joined #evergreen |
| 08:44 |
|
mmorgan joined #evergreen |
| 09:22 |
|
kbeswick joined #evergreen |
| 09:30 |
kmlussier |
eeevil: Following up on my question from yesterday, I have a record with 2 Located URI's: one for MBI and one for MCD. I set my preferred search library to MCD (not the system). I search the consortium and see both links as expected on https://jasondev.mvlcstaff.org/eg/opac/record/1554276, but MBI is still appearing first. |
| 09:30 |
kmlussier |
In this case, it should be showing the preferred library, MCD, right? |
| 09:30 |
kmlussier |
That is, it should be showing the preferred library first. |
| 09:33 |
eeevil |
kmlussier: that's what I would expect from the code in the repo, and what noble saw in testing ... let me see if we still have the test server up with that (though ALA has removed most of my human resources for things like knowing where an old test server might be ...;) ) |
| 09:33 |
|
ldw joined #evergreen |
| 09:34 |
kmlussier |
eeevil: OK, thanks. I could probably take a look on noble's server too. |
| 09:42 |
jeff |
in some ways, asset.copy rows are like tree rings. |
| 09:42 |
jeff |
"here we see where the library migrated to a new ILS" |
| 09:43 |
jeff |
"practices seem to have changed around this time, as cost data is no longer recorded for new items" |
| 09:43 |
jeff |
"this seems to be the year that the library performed an RFID tagging project. can you see all the items marked Missing?" |
| 10:09 |
kmlussier |
The preferred library sorting on the Located URI doesn't seem to be working as expected on the community demo server or NOBLE's training server either. I'll file a bug and just omit that piece of information from the documentation. I can always add it if/when it is fixed. |
| 10:32 |
|
yboston joined #evergreen |
| 10:40 |
jeff |
top hit on google for evergreen custom org tree is the wikipedia page for "Christmas tree" |
| 10:42 |
kmlussier |
I keep thinking that Google should be smart enough to know that when I search for Evergreen, I'm not interested in trees. |
| 10:48 |
kmlussier |
jeff: I don't know if you're looking for docs, but I don't see anything in the community docs for it. However, I do see a list message saying that the docs were created. http://markmail.org/message/ryfxsl5ueeunj6uh. I wonder if those docs are still available somewhere on the ESI site. |
| 10:55 |
eeevil |
kmlussier: they are. sec |
| 10:57 |
eeevil |
kmlussier / jeff: http://nox.esilibrary.com/esi/availableDocs.php ... asciidoc links work, but the wordpress ones need editing |
| 10:57 |
jeff |
kmlussier: I'm looking for the current state of the art with regard to org unit hiding/custom org tree/etc as we look at skinning a library off on its own. |
| 10:57 |
jeff |
eeevil: thanks! |
| 10:57 |
kmlussier |
eeevil++ |
| 10:58 |
kmlussier |
eeevil: I'm going to be pushing some docs today. Mind if I get those into the community docs? |
| 10:59 |
kmlussier |
That is, I'll be pushing some docs if I ever work through this EDI issue. :P |
| 10:59 |
eeevil |
kmlussier: please do, thought all of that has been offered to DIG, AFAIK, so maybe it's mostly in there? |
| 10:59 |
kmlussier |
eeevil: I think most of it is. But the custom org tree docs may have just been overlooked. |
| 11:00 |
kmlussier |
You were all creating a lot of documentation at that time. I wouldn't be surprised if one or two slipped through the cracks. :) |
| 11:05 |
|
vlewis joined #evergreen |
| 11:09 |
jeff |
oh wacky. CREATE OR REPLACE VIEW can fail if you're changing a column name. |
| 11:10 |
jeff |
and there it is in the docs: |
| 11:10 |
jeff |
> CREATE OR REPLACE VIEW is similar, but if a view of the same name already exists, it is replaced. The new query must generate the same columns that were generated by the existing view query (that is, the same column names in the same order and with the same data types), but it may add additional columns to the end of the list. The calculations giving rise to the output columns may be completely different. |
| 11:10 |
eeevil |
jeff: can/will |
| 11:11 |
jeff |
yeah. poor choice of words on my part. the fact that it could fail due to some previous DDL was surprising in the first place. :-) |
| 11:16 |
Bmagic |
Quick question: Can anyone verify that you are missing this function (taking 2 arguments, not 1) : vandelay.get_expr_from_match_set(match_set_id integer, tags_rstore hstore) |
| 11:18 |
jboyer-home |
Bmagic: It appears we only have the 2 param version on 2.5.2. |
| 11:18 |
Bmagic |
As far as I can tell, our database has never had this function, oddly enough, it didnt seem to matter, all of the vandelay stuff worked. Looking back at the sql upgrade scripts, the last time it was introduced was 0738 around version 2.2.3 |
| 11:51 |
csharp |
Bmagic: right - I found that too - it didn't make it into any upgrade scripts (on the paths I've taken, anyway) |
| 11:51 |
Bmagic |
csharp: You don't have it in your production database either? |
| 11:51 |
csharp |
correct |
| 11:52 |
csharp |
but... we don't really use Vandelay at this point - we found it when testing acq record import |
| 11:53 |
Bmagic |
csharp: weird, the situation here is: we upgraded to postgres 9.2 using pg_dump evergreen instead of pg_dumpall, Vandelay was working just fine before the upgrade. Now, postgres is complaining about the 2 argument function not existing. Odd, but if I use pg_dumpall, it works fine...... puzzle anyone? |
| 11:53 |
csharp |
hmmm |
| 12:01 |
jboyer-home |
Bmagic: what are the flags you’re using for dump and dumpall? |
| 12:02 |
Bmagic |
pg_dump evergreen > db1_pgdump.sql |
| 12:03 |
Bmagic |
and that is what is in production now.... later, after finding that vandelay wasn't working. I used pg_dumpall -o > pgdumpall.sql |
| 12:04 |
Bmagic |
After testing the restore on a dev box from the dumpall, the vandelay is working (even without the 2 argument function) |
| 12:08 |
jboyer-home |
They were getting errors whether they tried to use match sets or not? |
| 12:10 |
hopkinsju |
jboyer-home: Yes, but the funny part is, if you dont' specify an import queue the import *does* work. It goes into a queue that gets labeled "-" |
| 12:15 |
jboyer-home |
Does this return anything on either system? select * from vandelay.queue where match_set is not null; |
| 12:21 |
hopkinsju |
Yes |
| 12:22 |
hopkinsju |
It returns on production |
| 12:23 |
jboyer-home |
anything done in those queues will probably trip over that missing function. I’d imagine those same queues would fail on your dev machine, but honestly I don’t do that much with this. |
| 12:23 |
jboyer-home |
(If they’re also on the dev machine, that is) |
| 12:27 |
jboyer-home |
I think selecting anything in the Record Import Actions section of the marc importer will hit it. |
| 12:28 |
* hopkinsju |
thinks Bmagic may have wandered off. (He's not supposed to be working today) |
| 12:31 |
jboyer-home |
If that query only returned results on production and not dev then I’d say that may be the actual difference, rather than anything working differently with pg_dump vs pg_dumpall. |
| 12:31 |
jboyer-home |
I’m going to wander off myself for some lunch. :) |
| 12:38 |
Bmagic |
Jboyer-home: thanks for the insight. I will look into it. |
| 13:06 |
|
bmills joined #evergreen |
| 13:38 |
|
ldw joined #evergreen |
| 14:52 |
|
kbeswick joined #evergreen |
| 14:58 |
jeff |
searching for patrons by phone number is rather handy when we get a password reset request passed our way. |
| 14:58 |
jeff |
i still want to make that automatic. soon. :-) |
| 14:58 |
jeff |
(automatic in the sense that if you have a web interface up you see patrons in evergreen based on the incoming caller id of your phone or your department's phone) |
| 15:03 |
jcamins |
jeff: I seem to recall the BOFH pioneering that feature. |
| 15:19 |
jeff |
assuming there's an account or two found, it makes it far less important to worry about getting the proper spelling of their name. |
| 15:34 |
|
akilsdonk_ joined #evergreen |
| 15:35 |
pinesol_green |
[evergreen|Kathy Lussier] Documentation for Located URI Visibility - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=d5eb3a3> |
| 15:44 |
|
eeevil joined #evergreen |
| 15:44 |
|
Callender joined #evergreen |
| 16:04 |
|
tspindler left #evergreen |
| 16:33 |
|
kbeswick joined #evergreen |
| 16:43 |
|
kbeswick joined #evergreen |
| 16:48 |
|
dbs_ joined #evergreen |
| 16:57 |
|
tsbere_ joined #evergreen |
| 16:58 |
|
dreuther joined #evergreen |
| 17:10 |
|
mmorgan left #evergreen |
| 17:18 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 17:23 |
|
akilsdonk joined #evergreen |
| 17:25 |
|
jcamins_ joined #evergreen |
| 17:31 |
|
shadowsp1r joined #evergreen |
| 18:29 |
|
ldw joined #evergreen |
| 19:51 |
|
kmlussier joined #evergreen |
| 20:53 |
|
mceraso joined #evergreen |
