Migrering

Migreringskriptet ligger i Oracle på MUSTST i skjemaet Musit_mapping og i pakken migrate_storagenode_move. Tilgangene(grantingen) ligger hos Ellen i GithubGist for ikke at de skal ligge åpent.

1.   migrate_storage;
    Laster inn magasintreet til alle museene på kultur. De ligger i samme tabell.

2. først migrate_etno_o_firstmoves;
    usd_etno_gjenstand_o har en egen flyttehendelse kalt magasinering, som tas inn først og med magasinstedet som en kommentar. Magasinstedet blir en node i magasintreet som blir liggende under noden "gml_magasin"-noden senere i koden.

3. migrate_move_Event 
    Man kan velge å kjøre en migrering for hvert museum.
    Sjekker om flyttingen skal migreres, altså man sjekker om den er en topphendelse til underflyttinger, da skal den ikke inn...
     Sjekker om den har kommentar som skal inn. Kommentaren "del av blablabla" skal ikke med, så det blir fjernet.
     Skjema USD_ETNO_GJENSTAND_O har en if-else for den samlingen er litt spesiell.
    proceduren makeOldNodeOf_etno_o_special er tatt inn slutten av proceduren migrate_move_event i stedet for å kjøres løst.

    Kommentar til : MakeOldNodeOf_etno_o_special

    legger inn steder for de med old_type_id = 41, altså de gamle_magasinstedene...de blir en node i storage_node under Rotnoden til KHM,med egen node gamle_magasinsteder. Alle disse magasinstedene legges under den noden og de er is-deleted, enn så lenge.

***  place,time,actor and object***

4. migrate_m_m_place_time_actor
    Det er lurt å ta en og en av disse m-m-tabellene inn, dvs å kommentere inn/ut linje for linje for place,actor etc. Dette fordi de ulike kallene lager ulike dbms_meldinger som vil være lurt å gå gjennom separat. Også lurt å kommentere ut insert/update-statements for å kjøre proceduren for å sjekke at alt går gjennom. Særlig lurt når vi gjør dette på musprd og/eller musutv.

****STEDER**********
     går gjennom alle flyttehendelsene som er migrert for å finne til/fra-sted,samt å legge inn place-as-object der relasjonen er "er-flyttet". finner først de som har en "er-flyttet"-relasjon og tar disse flyttehendelsene for seg for der skal nodeid inn som object. Det er noen gamle steder som fortsatt står som fra-sted. De legges inn under samme "gml-magasin" sånn at vi får med fra_stedet. PÅ mustst var det 8 stykker(se spørring under).

Spørring for å sjekke migrerte flyttehendelser som har steder knyttet til seg som ikke finnes i storage_node(finnes nok bare i usd_etno-gjenstand_o.) 

select DISTINCT S.* from usd_sted.sted s,
(select t.old_eventid,h.stedid,h.rolleid,r.rolle
 from migrate_move_event t, USD_ETNO_GJENSTAND_O.hendelse_sted_rolle h,usd_etno_felles.rolle r
where t.old_schemaName = 'USD_ETNO_GJENSTAND_O' and  t.old_eventid=h.hid and h.rolleid= r.rolleid and not exists(select 
* from storage_node s
where h.stedid=s.old_nodeid)) t
where s.stedid=t.stedid

***PERSON***********
 Samme procedure migrate_m_m_place_time_actor
Aktør registered_by = MUSIT, siden vi migrerer dataene. Det blir satt inn i migrate_move_Event-procedura.

***TID************

Registered_date = 01.01.2017 når vi lastet over dataene..
event_date = blir da startdato for eventen...eller det som lå i hendelse_tid_rolle-tabellen
Er det ulik dato i den cashede start_dato-feltet i hendelsen så tar vi inn det som ligger i hendelse_tid_Rolle for det ser riktigst ut.

***GJENSTAND*********

Det er noen gjenstander i usd_ark_gjenstand_b i MUSTS som ikker er i mappetabellen fordi jeg har disablet triggeren som bygger opp nye rader i mappetabellen
pga bryggen.

Det viser seg at det finnes gjenstander med gamle magasinsteder som ikke er flyttet til nye stedsnoder dvs at de står med sin gamle magasinsted som den eneste magasininfoen. vi endrer deres "is_deleted" til å vises igjen slik at man kan få rettet dette i magasinet senere. Noen data har mer enn en flytting og da blir max(hid) last_moveID.

******UpdateLatestMoveID for Object and STORAGENODE***********************

5. migrate_lastMoveHID
    Den fyller opp local_object-tabellen og legger inn latest_moveID og currentLocation_id der det er enkelt å finne. findLatestMoveHidAndPlace finner siste flyttehendelse til de som ikke gikk inn med en gang. Den inneholder også oppdatering av latestMoveId på StorageNode(siste kallet i proceduren).

Print fra  dbms_output...med "Fant ikke hid i mappetabellenUSD_ETNO_GJENSTAND_O oldEventid: 1731448"
Disse flyttehendelsene har til_sted men er ikke med i migreringen da de er toppFlyttehendelser eller er flyttehendelser med sted fra utlandet/organisasjoner til museet, altså stedene er ikke stedsnoder. Vi ignorerer de nå. De skal nok kanskje være med i proveniensen/innkomst.

6. set_new_eventtypeID 
 set_new_eventtype_MoveObject : Dette har ikke blitt gjort tidligere da det har vært litt uklart hvilke ID de ulike event-typene har. Men nå er det likt med ID'ene som Knut-Petter har i sin nye kode.

7. Har overført to funkjsoner fra det gamle systemet som beregner stedstien med tekst og stedstien med nodeid 

BeregnStedStiForSted og finnstedsti

AVVIK- ikke migrerte flyttinger:

Flyttehendelser som har hatt del_flyttehendelser knyttet til seg er ikke tatt med i migreringen.

For etno-samlingen i Oslo, USD_ETNO_GJENSTAND_O :

gml magasinhenvisninger er tatt inn som en første flytting og magasinstedet er lagt under noden "gml_magasin". (gml hendtypeid =41 (magasinering))

Flyttinger som har omfattet fra/til-sted som er utenlandske/nasjonale (ikke-magasin-steder), er ikke tatt med. De får tas med i innkomst/proveniens-tjenesten.

Regler for migrering av stedene

Krav til hierarki i den nye løsningen:

1. Organisasjon
2. Bygg
3. Fritt (organisasjon, bygg, rom, lagringsenhet)

Forslag til regler for de øverste nivåene ved migrering:

• KHM har noen noder som ser ut som de har to typer, både Pallereol og Reol

Mapperegler for typene:

Unntak for VM (for utlånssteder):

Typene Adresse og Institusjon mappes til type Bygg i ny løsning, og flyttes inn under hhv. «Kulturhistorie utlån person» og «Kulturhistorie utlån institusjoner» (begge type Organisasjon).