Evergreen ILS Website

IRC log for #evergreen, 2020-08-07

| Channels | #evergreen index | Today | | Search | Google Search | Plain-Text | summary | Join Webchat

All times shown according to the server's local time.

Time Nick Message
00:29 jvwoolf joined #evergreen
00:34 jvwoolf joined #evergreen
00:39 jvwoolf joined #evergreen
00:44 jvwoolf joined #evergreen
00:49 jvwoolf joined #evergreen
00:54 jvwoolf joined #evergreen
00:59 jvwoolf joined #evergreen
01:04 jvwoolf joined #evergreen
01:09 jvwoolf joined #evergreen
01:14 jvwoolf joined #evergreen
01:19 jvwoolf joined #evergreen
01:24 jvwoolf joined #evergreen
01:29 jvwoolf joined #evergreen
01:34 jvwoolf joined #evergreen
01:39 jvwoolf joined #evergreen
01:44 jvwoolf joined #evergreen
01:49 jvwoolf joined #evergreen
01:54 jvwoolf joined #evergreen
06:00 pinesol News from qatests: Testing Success <http://testing.evergreen-ils.org/~live>
07:18 rjackson_isl_hom joined #evergreen
07:39 collum joined #evergreen
08:05 mantis1 joined #evergreen
08:11 alynn26 joined #evergreen
08:12 Dyrcona joined #evergreen
08:36 mmorgan joined #evergreen
08:40 rfrasur joined #evergreen
09:05 dbwells joined #evergreen
09:05 dbwells joined #evergreen
09:09 sandbergja joined #evergreen
09:14 sandbergja joined #evergreen
09:21 sandbergja_ joined #evergreen
09:24 dbwells joined #evergreen
09:48 sandbergja A note to committers: bug 1811466 has been signed off (by me); is a relatively small, simple webstaff column fix; and will get you lots of points with catalogers if you merge it :-)
09:48 pinesol Launchpad bug 1811466 in Evergreen 3.4 "Web Client: Copy Creator and Editor Missing from Columns in Copy Editor" [Undecided,Confirmed] https://launchpad.net/bugs/1811466
09:51 jvwoolf joined #evergreen
09:51 Dyrcona @blame fingers
09:51 pinesol Dyrcona: fingers caused the white screen of death!
09:56 mmorgan sandbergja: Sounds like a win-win! And would be a good Friday accomplishment.
10:25 angelo joined #evergreen
10:49 jvwoolf1 joined #evergreen
11:51 jvwoolf1 left #evergreen
11:54 jvwoolf joined #evergreen
11:54 angelo Bmagic i have a couple questions regarding these migration instructions if you're around
11:56 Bmagic sure
11:56 jvwoolf left #evergreen
11:57 Bmagic though, I am jumping on a call so I might be delayed in responding
11:57 jihpringle joined #evergreen
11:59 csharp angelo: if you go ahead and ask your questions, someone may be able to go ahead and respond/help
11:59 jvwoolf joined #evergreen
12:00 angelo so im following this slide deck https://docs.google.com/presentation/d/177JF_kw9o​-YO2Q0O9EEyfBuD95SStXfmyJ4TF_jOuXY/edit#slide=id.g110d509fc8_0_8
12:00 angelo i created the _legacy table, and its showing both the regular columns and the ones i created with the l_ prefix, im guessing because of the inheritance
12:01 angelo when i try and insert into the l\_ tables it throws an error because the inherited not null columns have null values
12:06 Bmagic angelo - did you execute the sql command to copy the columns from the l_ columns -> non-l_ columns?
12:06 angelo update m_staging_schema.actor_usr_legacy
12:06 angelo that one?
12:08 Bmagic angelo: line 1159 shows the example query
12:09 angelo that is the query from 1159
12:09 angelo and yes i ran it
12:09 Bmagic did it work?
12:10 angelo yes
12:11 jlundgren joined #evergreen
12:12 angelo but there isnt anything in that table
12:15 Bmagic I see - there is a prerequisite that you load that table with your data
12:15 angelo into the l\_ columns?
12:25 mrisher joined #evergreen
12:25 mrisher joined #evergreen
12:34 angelo should i be able to load data into a table with inherited columns without satisfying the requirements of the inherited columns?
12:34 Dyrcona No.
12:36 angelo then how can i insert data into the l\_ prefixed columns without also entering data into the inherited columns?
12:36 Dyrcona I wouldn't bother with l_ prefixed columns.
12:37 Dyrcona I'm not the one who wrote that slide deck, and I think Bmagic has done more data migrations than I have, but I usually go through the data that I'm given and write something bespoke in Perl to load the data.
12:38 angelo id be happy to do that i just need to know how to get around the constraint issues
12:38 Dyrcona In my experience, every migration is unique, and there are corner cases in every dataset, often more than four corners.
12:38 Dyrcona Most of the constraints are deferred, so doing things in transactions usually works.
12:39 Dyrcona You just have to load the data in the proper order: org_units, users, bibs, call numbers, items, transactions.
12:40 angelo i feel like there is no difference between loading the data directly from the tsv files and doing the steps outlined in the slide deck, especially this step https://docs.google.com/presentation/d/177JF_kw9o​-YO2Q0O9EEyfBuD95SStXfmyJ4TF_jOuXY/edit#slide=id.g110d509fc8_0_13
12:40 angelo i could see that being useful for data validation if i was coming from another system, but since im going from EG -> EG it shouldnt be an issue
12:42 Dyrcona angelo: I mostly agree with you. There's a good rationale for using staging tables, and I'm sure phasefx does it that way from experience, but I do it differently.
12:43 Dyrcona It's basically a lot of trial and error.
12:43 angelo i guess im just surprised theres not a clean import path since it came from the same system
12:46 Dyrcona :)
12:47 Dyrcona It should be possible to write something that could load data from that export. I've never needed to.
12:48 Dyrcona I've never used the export, either. We have other ways to get the data when someone leaves our consortium.
12:49 Dyrcona We also usually end up adding a lot of data from scratch when new members join. We get a lot of small libraries joining who still use card catalogs and paper records.
12:49 Dyrcona Well, by "a lot," I guess I mean that most of our recent new members have been like that.
12:51 Dyrcona Then, we often have their bib records sent off to be cleaned before we try loading them, and I don't know what they do about patrons. I'm usually not directly involved in that.
12:51 Dyrcona For those that have an ILS, that is.
12:54 Dyrcona And, I suppose that's why there isn't an easy way to move from one Evergreen system to another, because every site does things differently. Also, Evergreen to Evergreen migrations don't happen that often.
12:57 Dyrcona @monologue
12:57 pinesol Dyrcona: Your current monologue is at least 9 lines long.
13:14 Bmagic angelo: Dyrcona and I are suggesting slightly different paths. The core issue are the ID numbers. The ID numbers that you have from your export are all related to eachother. I think it's a good idea to let the new EG database assign new ID numbers. This will require that you "map" / "reassign" those foreign key ID's for each table to their new ID numbers on their associated tables
13:15 mrisher_ joined #evergreen
13:49 angelo joined #evergreen
14:26 jvwoolf joined #evergreen
16:05 mantis1 left #evergreen
17:11 mmorgan left #evergreen
18:00 pinesol News from qatests: Testing Success <http://testing.evergreen-ils.org/~live>
18:53 abowling1 joined #evergreen
19:02 abowling joined #evergreen
19:42 sandbergja joined #evergreen
19:43 pinesol [evergreen|Michele Morgan] LP1811466 Add fields to holdings editor column pickers - <http://git.evergreen-ils.org/?p=​Evergreen.git;a=commit;h=5ad0497>
20:45 alynn26_away joined #evergreen
22:24 bshum joined #evergreen
22:35 jeffdavis joined #evergreen
23:40 sandbergja joined #evergreen

| Channels | #evergreen index | Today | | Search | Google Search | Plain-Text | summary | Join Webchat