MarsDD
Occasional Observer

Migration von FS_LIST zu FS_INDEX - Szenarien

Hallo zusammen,

hat jemand schon Erfahrung bei der Migration von FS_LIST zu FS_INDEX in Datenquellen/Datensätzen sammeln können, wobei hier 2 Szenarien vorzufinden wären.

- FS_LIST type database persistiert Daten aufgrund einer Relation zu einer anderen Datenquelle

- FS_LIST type database persistiert Daten auf Basis des Datentypes FirstSpirit-Editor

Viele Grüße und ein schönes Wochenende

Marcel

0 Kudos
6 Replies
marro
Crownpeak employee

Hallo Marcel,

Erfahrungen mit der Migration habe ich leider noch nicht sammeln können. Von einem Kollegen habe ich aber folgende Hinweise bekommen:

Für die FS_LIST auf Basis einer Relation zu einer anderen Datenquelle sollte das kein Problem sein, da die FS_LIST in diesem Fall ja keine Eingabekomponenten-spezifische Daten vorhält. Der einzige Punkt, der beachtet werden muss, ist die Sortierung der Einträge, da dies in einer FS_LIST anders gehandhabt wird als bei FS_INDEX. Dazu würde ich Dich einmal auf das Kapitel 58.8. der Releasenotes_2018_11_combined verweisen (oder falls Du ältere Releasenotes zur Hand hast einmal nach "FS_INDEX: Datensätze manuell sortieren" suchen). Dort findet sich auch ein Beispiel für ein entsprechendes Migrationsskript.

Bei der Variante auf Basis des Datentyps FirstSpirit-Editor wäre im Vorfeld zu klären, ob es dort bereits eine frühere Migration von der inzwischen veralteten Eingabekomponente INPUT_CONTENTLIST nach FS_LIST gegeben hat. FS_INDEX kann in der Regel die Daten einer FS_LIST lesen, aber nur wenn die Daten zwischenzeitlich in der FS_LIST gespeichert und auch freigegeben wurden. Wurde in der Vergangenheit nur die Eingabekomponente von INPUT_CONTENTLIST zu FS_LIST geändert ohne nachträgliches speichern und freigeben, kann es bei der weiteren Migration zu FS_INDEX zu Problemen kommen.

Ich hoffe, wir konnten Dir mit diesen Hinweisen ein wenig weiterhelfen.

Viele Grüße

Donato

0 Kudos
MarsDD
Occasional Observer

Hi Donate,

vielen Dank für Deine ausführliche Antwort.

Ist Dir ggf. ein Nachweisverfahren bekannt, bei dem ich in Erfahrung bringen könnte, ob eine Migration durchgeführt wurde?

Viele Grüße

Marcel

0 Kudos
marro
Crownpeak employee

Hallo Marcel,

mir ist leider kein Nachweisverfahren bekannt. Daher würde ich vor der Migration dazu raten, alle betroffenen Seiten (mit einer FS_LIST Eingabekomponente) einmal zu speichern und zu releasen. Das könnte man dann ja automatisiert im entsprechenden Migrationsskript miterledigen.

Viele Grüße

Donato

0 Kudos
neumann
Crownpeak employee

Hallo Marcel,

bist du über die Feiertage denn schon dazu gekommen, Donatos Antwort umzusetzen und auszuprobieren? Falls ja, wäre es toll, wenn du uns wissen lassen könntest ob das so geklappt hat oder nicht.

Viele Grüße

Emre

0 Kudos
MarsDD
Occasional Observer

Hi Emre,

wir sind noch nicht dazu gekommen, da vorerst noch diverse andere Sachen hierzu gemacht werden müssen. Meine Frage bezog sich einfach darauf, sich vorab schon einmal schlau zu machen was hierbei zu beachten ist und ob schon jemand eine solche Migration durchgeführt hat.

Viele Grüße

Marcel

0 Kudos
MarsDD
Occasional Observer

Wir haben nun angefangen hier und da eine FS_LIST zur neuen Eingabekomponente FS_INDEX zu migireren.

Folgende Findings:

- 1x im Formular geändert und gespeichert und es gibt keinen Weg mehr zurück (Freigabestand der Datensätze spielt hier keine Rolle)

- FS_LIST verifiziert nicht die Bestandsdaten anhand einer definierten Query

- FS_LIST ohne Query -> Daten werden gepflegt

- FS_LIST bekommt eine Query und 1 Datensatz würde nicht mehr in die Teilmenge gehören; bleibt aber in der FS_LIST

- Umstellung auf FS_INDEX -> 1 Datensatz wird als Invalid Value deklariert -> keine FS ID (sondern nur der GID) steht am Datensatz in der FS_INDEX

  hier würde ich mir wünschen:

  - Ausgabe der FS_ID oder

  - neuer Menüpunkt bei "Search" -> "Search für gid"

Viele Grüße

Marcel

0 Kudos