| 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 |
