Questions & Answers

[felix_reinhold]

Hallo zusammen,

eine kurze Frage zur Umstellung einzelner Tabellenspalten in Schemata auf mehrsprachig.

Fehlerbeschreibung  / detailed error report:

Normalerweise sind in diesem Fall die Werte ja weg, bzw. werden nicht mehr gezogen, da die Referenz auf die Datenbank auf ein anderes Feld verweist.

Beispiel: Spalte test verweist in der DB auf TEST. Umstellung auf mehrsprachig: Spalte test_DE verweist auf TEST_DE.

Mir würde es reichen, wenn in der Mastersprache wieder die alten Werte enthalten wären. Kann es zu Problemen führen, wenn ich einfach über die externe Bearbeitung des Schemas die Spalte test_DE auf TEST verweisen lasse? Oder gibt es dann irgendwo ungültige Referenzen, weil im Backend der DB-Feldname noch irgendwo aus dem FS-Feldnamen abgeleitet wird?

Alternativ: Habt ihr für so einen Fall ein Migrationsskript oder müsste ich selbst schnell eines schreiben?

Beste Grüße

Felix

Version:

Infos (ja, ich weiß, böse BETA 😞

FirstSpirit Client 5.0_BETA.308.56374

Version Server: 5.0_BETA.308.56374

Speicher: 74,63 von 494,94 MByte belegt

Java Version: 1.6.0_43 32bit Sun Microsystems Inc.

Betriebssystem: Windows 7 6.1 x86

[StefanSchulz]

Hi,

vielleicht sehe ich das auch zu naiv, aber hier sollte man meiner Meinung nach problemlos ohne Migration auskommen. Die entsprechenden Komponenten auf mehrsprachig umstellen (im Formular) und für das Mapping die gewünschten Spalten aussuchen. Das Mapping auf _DE erfolgt eigentlich nur, wenn eine solche Spalte im Schema vorhanden ist.

Gruß

Stefan

[felix_reinhold]

Hi Stefan,

Die entsprechenden Komponenten auf mehrsprachig umstellen (im Formular) und für das Mapping die gewünschten Spalten aussuchen.

Damit die Werte mehrsprachig pflegbar sind müsste ich ja dennoch die Tabelle im Schema anpassen. (Sonst hab ich eine mehrsprachige Eingabekomponente, die für alle Sprachen auf die gleiche Spalte zeigen).

Das Mapping auf _DE erfolgt eigentlich nur, wenn eine solche Spalte im Schema vorhanden ist.

Nach dem Ändern der Spalte auf mehrsprachig ist die alte Spalte ohne Sprachkürzel leider nicht mehr vorhanden und es muss ein Mapping auf bspw. _DE erfolgen. Alternativ könnte ich natürlich auch die Spalten für die anderen Sprachen manuell anlegen und für die Mastersprache das sprachunabhängige Feld behalten, also bspw. bei den Sprachen DE, EN, FR: Spalte "test", "test_EN", test_FR".

Damit wäre ich aber nicht mehr am Standard und könnte bspw. solche Konstrukte, wie

entity.getValue("test_"+#global.language.abbreviation)

nicht mehr nutzen.

Gruß

Felix

[StefanSchulz]

Ok, wenn du direkt auf die Spalten auf obige Art zugreifen willst, geht das natürlich nicht auf dem Weg, den ich beschrieb. FirstSpirit-Zugriffe werden andernorts automatisch auf die entsprechenden Sprachkanäle geschaltet oder eben auf den sprachunabhängigen Kanal.

Obige Umstellung beinhaltet ja eine Änderung in der Datenbank, wäre es da nicht einfacher, dort die alte Spalte test auf die neue test_de zu spiegeln? Sollte ja einfach per SQL machbar sein. Oder soll da noch irgendwo parallel darauf zugegriffen werden können?

Gruß

Stefan

[felix_reinhold]

Hi Stefan,

die Variante die Inahtel per SQL zu spiegeln/kopieren wäre auf jeden Fall möglich, wollte ich nur vermeiden, da es sich bei dem Projekt um ein Template-Masterprojekt (CorporateContent) handelt und das Schema somit in extrem viele Unterprojekte verteilt wird, die eigene Datenbank-Layer haben. Die Spiegelung müsste so für jedes Unterprojekt einmal gemacht werden, die Änderung des Feldes nur im Template-Master (oder werden beim Transport des Schemas die Referenzen auf Datenbank-Felder nochmal umgeschossen und diese Variante kann gar nicht funktionieren?). Deshalb würde ich momentan die Änderung des hinterlegten DB_Feldes im Schema bevorzugen. Wenn du aber meinst, dass das nicht sinnvoll ist müssten wir eben doch die umständlichere SQL-Variante nehmen.

Gruß,

Felix

[StefanSchulz]

Und wieder eine Information mehr über das Projekt

Klar, für ein Mastertemplate ist ein Migrationsskript sinnvoller (was dann wohl nichts anderes macht als die Spalte zu spiegeln oder migrieren).

Außer die Sprachspalten händisch zu erstellen und das Mapping entsprechend einzustellen, fällt mir aktuell aber auch nichts ein. Vielleicht kommt ja noch jemand an diesem Thread vorbei und hat eine Idee.

Gruß

Stefan

[felix_reinhold]

Hi Stefan,

danke für die Antworten. Jetzt habe ich schonmal einen Überblick über die einzelnen Möglichkeiten.

Es wäre klasse, wenn jemand noch auf die Grundfrage eingehen könnte, da das immer noch die einfachste Lösung für uns wäre:

Kann es zu Problemen führen, wenn ich einfach über die externe Bearbeitung des Schemas die Spalte test_DE auf TEST verweisen lasse? Oder gibt es dann irgendwo ungültige Referenzen, weil im Backend der DB-Feldname noch irgendwo aus dem FS-Feldnamen abgeleitet wird?

Besten Dank

Felix

PS: Server-Version ist nun 5.0.318.57504

[kohlbrecher]

Hallo Felix,

hast du inzwischen eine Lösung für dein Problem gefunden? Wenn ja, wäre es schön, wenn du diese kurz vorstellen könntest, damit die anderen User sich an deiner Lösung orientieren können.

Danke

Jan

[felix_reinhold]

Hi Jan,

da ich leider keine Antwort auf obige Frage (rot geschrieben) von einem der "Backend-Entwickler" bekommen habe, haben wir die Spalte per SQL in der DB gespiegelt. Das hat natürlich ganz normal funktioniert. Obige Lösung habe ich bei mir in einem kleinen PoC mal probiert und bin auf keine Fehler gestoßen, wollt emich aber nicht darauf verlassen in einem größeren Projekt. Eine Antwort wäre hier also weiterhin ganz klasse für zukünftige Projekte.

Beste Grüße

Felix

[Peter_Jodeleit]

Zu deiner "roten" Frage: Hier könnten wir nur sagen, das dies aktuell zu keinem Problem führt (so wie du auch selber festgestellt hast). Allerdings wird das kein Pfad sein, die wir in unsere Freigabe-Tests aufnehmen. Und demzufolge auch nicht garantieren können, das dies auch in Zukunft und für alle Benutzungen (z.B. im CorporateContent-Umfeld) funktioniert.