- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Tabellenspalte Umstellung auf mehrspaltig: Datenmigration
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
- Labels:
-
Developers
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.