| Time |
Nick |
Message |
| 07:15 |
|
collum joined #evergreen |
| 07:30 |
|
redavis joined #evergreen |
| 08:00 |
|
BDorsey joined #evergreen |
| 08:42 |
|
mmorgan joined #evergreen |
| 08:55 |
|
Dyrcona joined #evergreen |
| 09:03 |
|
dguarrac joined #evergreen |
| 09:20 |
Dyrcona |
@later tell Bmagic git push origin tags/rel_3_11_5:tags/rel_3_11_5 |
| 09:20 |
pinesol |
Dyrcona: The operation succeeded. |
| 09:21 |
Dyrcona |
@later tell Bmagic Sorry about the transposition. I find my own typos and errors in commit messages to be most embarrassing. I run spell check these days, but that doesn't catch issues with numbers. |
| 09:21 |
pinesol |
Dyrcona: The operation succeeded. |
| 09:23 |
Dyrcona |
Other people's errors don't bother me so much. We're only human, but I cringe at my own silly mistakes. |
| 09:27 |
csharp_ |
before I reinvent the wheel, does anyone have a tool they use to migrate copies/vols from one OU to another? Use case: library closes and another library absorbs the old library's collection |
| 09:27 |
csharp_ |
we have to accommodate the constraint on duplicate cn labels per OU |
| 09:28 |
csharp_ |
I can see that the asset.merge_record_assets function has some code to crib from |
| 09:38 |
Dyrcona |
csharp_: I'd use an EXCEPTION WHEN... block for the unique violation on the call numbers if you're using SQL: https://www.postgresql.org/docs/16/plpgsql-control-structures.html#PLPGSQL-ERROR-TRAPPING |
| 09:38 |
Dyrcona |
In the WHEN block just update the copies to the existing call number and delete the call number that would be the duplicate. |
| 09:47 |
Dyrcona |
csharp_: Here's an example of a database function I use that does almost exactly what you want: https://pastebin.com/cEsaHGGX |
| 09:48 |
Dyrcona |
You could also avoid the exception by checking for an existing call number at the new owning library and updating the copies, etc., if that exists. |
| 09:50 |
Bmagic |
Dyrcona: this was my problem git remote set-url --push origin git git.evergreen-ils.org:Evergreen.git |
| 09:51 |
Bmagic |
Dyrcona: 100% agree about seeing my own mistakes vs. others's |
| 09:53 |
Dyrcona |
OK. If I have more than 1 remote, I pretty much always specify the remote that I'm pushing. I don't rely on defaults. |
| 09:53 |
Bmagic |
my instincts as well |
| 09:55 |
Dyrcona |
I think you do have to specify the remote though when pushing a new branch, if you didn't already set it to track something. |
| 10:11 |
|
mmorgan joined #evergreen |
| 11:49 |
|
jihpringle joined #evergreen |
| 12:14 |
Dyrcona |
Odd. In production, the SFTP code seems to be setting the remote filename to "1" while on my test vm it set it to the actual remote filename. I've compared RemoteAccount.pm between production and the test system, and they are identical. |
| 12:14 |
Dyrcona |
Also both are on the same release of Ubuntu with the same Perl version, and the same Net::SFTP::Foreign module version. |
| 12:16 |
Dyrcona |
I wonder if it is possibly a difference in the server? Could the SFTP server affect the return value of $sftp->put()? |
| 12:21 |
Dyrcona |
Has anyone else started using/testing SFTP with Ingram in production? If so, have you noticed anything in the acq.edi_message table, notably remote_file having just a "1" in it? |
| 12:41 |
Dyrcona |
i think there's a bug in the put_sftp function that somehow escaped testing. I unfortunately do not have syslogs on the test machine going back far enough to see what happened there. I'm going to run another test. |
| 12:50 |
Dyrcona |
Actually, I think I see the bug on one of my test systems. I'm going to test again and see what happens. |
| 13:05 |
|
sleary joined #evergreen |
| 13:44 |
Dyrcona |
Bleh. None of the production data is loading today. Too much missing extra data: bibs, etc. |
| 13:46 |
Dyrcona |
When I tried to add items via brief record, I get a failure to update the database. As I said, I don't know what I'm doing in the acq interface. |
| 13:52 |
Dyrcona |
We also see the welcome banner and please login in the pusher and fetcher output. |
| 14:02 |
Dyrcona |
Ugh! I've either already loaded the data or the inserts fail because of fkey constraints. |
| 14:07 |
* Dyrcona |
reloads a database dump or two.... |
| 14:11 |
|
collum joined #evergreen |
| 14:12 |
Dyrcona |
I suppose I could just wait until next week, but I really want to verify this bug. |
| 14:16 |
Dyrcona |
Found it in 1 account on a database that I have not reloaded, yet! remote_file is 1 for one of the purchase orders that I successfully tested. |
| 14:20 |
Dyrcona |
So, I'm going to test on one of the vms with the patch applied to see if that fixes it. |
| 14:20 |
Dyrcona |
But, first, the database must finish reloading. |
| 14:32 |
Dyrcona |
Lp 2060153 |
| 14:32 |
pinesol |
Launchpad bug 2060153 in Evergreen 3.12 "EDI SFTP Records wrong remote file when sending purchase order " [Undecided,New] https://launchpad.net/bugs/2060153 |
| 14:37 |
Dyrcona |
Oh! It looks like my query to grab the lineitem data from before the order was processed is returning no rows.... |
| 14:45 |
Dyrcona |
OK. A couple of date_trunc('second', ...) fixed it: AND date_trunc('second',audit_time) <= date_trunc('second', b.order_date) |
| 14:45 |
Dyrcona |
audit_time has fractions of a second and order_date does not. |
| 14:52 |
|
stephengwills joined #evergreen |
| 14:58 |
jeff |
yeah, timestamps that are set by DEFAULT NOW() in the database will go backward in time when those rows are later updated by... just about everything else in Evergreen. |
| 15:00 |
Dyrcona |
It makes me wonder how I got any data to test last time, though. I should check the auditor cleanup for that table. |
| 15:15 |
|
sleary_ joined #evergreen |
| 15:18 |
Dyrcona |
Ah. I see. The purchase order was updated in produciton since I last grabbed data, so the timestamps lost some precision. |
| 15:18 |
Dyrcona |
s/produciton/production/ |
| 15:18 |
* Dyrcona |
can spell. I just can't type. :) |
| 15:56 |
Dyrcona |
I get to delete some workstations, now. :) |
| 16:03 |
Dyrcona |
And, acquisitions refuses to work on this VM because too much data for the Dojo interface or something something...mumble. |
| 16:07 |
|
jihpringle joined #evergreen |
| 16:12 |
Dyrcona |
So, reload the other database that will require an upgrade and reingest. |
| 16:55 |
|
stephengwills left #evergreen |
| 17:01 |
|
mmorgan left #evergreen |
| 21:17 |
pinesol |
News from commits: LP#2019211: remove remoteauth.cgi <https://git.evergreen-ils.org/?p=Evergreen.git;a=commitdiff;h=6a898516e8552655590ae9d297a8d725ff9e486d> |
| 22:19 |
|
sleary joined #evergreen |
