LVanselow
I'm new here

Migrationsszenarien von useLanguages="no" auf useLanguage="yes"

Hallo zusammen,

kennt jemand ein gängiges Migrationsszenario von Feldern mit useLanguages="no" auf useLanguages="yes".

Der bisherige Ansatz wäre ja:

1. pro Eingabekomponente eine zusätzliche Komponente vom gleichen Typ mit useLanguages="yes" anlegen

    <CMS_INPUT_TEXT name="st_headline" useLanguages="no"/>  + <CMS_INPUT_TEXT name="st_headline_tmp"  useLanguages="yes"/>

2. Den Wert von der alten Komponente in die neue Komponente übertragen

3. Die alte Komponente löschen

4. Die neue Komponente in den Namen der alten Komponente umbenennen

Alles im allen eine sehr aufwendige Prozedur.

Gibt es vlt. produktseitig einen anderen Ansatz (Fallbackmechanismus, Aktualisierung via Derby-DB etc.)?

Viele Grüße

Lars

5 Replies
mfinsterbusch
New Responder

... insbesondere Schwierig ist dieser Ansatz bei verschachtelten Komponenten (LIST, CATALOG) und / oder den mappings in den Datenquellen (wenn z.B. eine neue Sprache hinzugefügt wird).

Wie könnte ein fallback bei Medien aussehen?

Gibt es hier produktseitige Unterstützung?

Danke & Grüße,

Maik

0 Kudos

Hallo Maik,

Der Ansatz ist wohl eher keine gute Herangehensweise, da es mir scheint, dass Daten verloren gehen.

Eigentlich sollte das Standardverhalten von First Spirit ausreichend sein um einfach zwischen useLanguages="no" und "yes"

problemlos zu wechseln. Die weiteren Sprachreiter bekommen dort die Werte aus der Mastersprache (wenigstens in meiner lokalen Testumgebung). Anders verhält es sich, wenn eine neue Sprache hinzugefügt wird, oder Datenquellen plötzlich mehrsprachig sind.

An solcher Stelle wäre ein Script eine denkbare Lösung.

Viele Grüße

Nico

Hallo Nicolai,

vielen Dank für die Antwort. Dann scheint das ein neues Feature von FirstSpirit zu sein. Ich kenne die Problematik noch aus Zeiten von FirstSpirit 4.x. Dort waren alle Werte nach Umstellung von useLanguages="no" auf useLanguages="yes" verloren.

Wir probieren das mal aus!

Viele Grüße

Lars

0 Kudos

Hallo Nico,

das klingt sehr gut und so (oder besser) wünschen wir uns das auch 😉

Nach einem Test von einer kleiner Auswahl an Komponenten hat das auch geklappt.

Auch ich kenne noch schwierige Zeiten wo das nicht soo einfach möglich war und eine Migration viel Nerven & Schweiß gekostet hat.

Meine Fragen nun:

1) Ist das "Feature" "offiziell"?

2) Funktioniert dies für _alle_ Komponenten (oder gibt es Ausnahmen), auch verschachtelt, eingebunden in und von Datenquellen,  etc.?

Thema 'hinzufügen' von Sprachen:

Es ist nun ein paar Jahre her, jedoch gab es das Issue ja schon damals...

Gibt es hier wirklich mittlerweile kein Modul Skript oder sogar eingebaute Funktionalität? Der Anwendungsfall ist ja eher ein Standard, ohne "projektspezifische Eigenschaften"...

beste Danke & Gruß,

Maik

0 Kudos

Hallo Lars und Maik,

ich denke, diese Frage im Rahmen der Community explizit mit einem ja oder nein zu beantworten ist nicht der richtige Weg. Aktuell ist mir leider keine Stelle bekannt, an der wir so ein Vorgehen dokumentieren. Ich kann mir vorstellen, dass es hier den ein oder anderen Fallstrick gibt, der nicht abgedeckt ist. Ich denke der beste Weg ist, das Projekt Stück für Stück zu migrieren und natürlich vor jeder Feldmigration ein Backup zu machen, damit man im Zweifelsfall die Änderung(en) Rückgängig machen kann.

Gerne könnt ihr eure Erfahrungen dazu hier posten.

Viele Grüße

Martin

0 Kudos