Questions & Answers

[kuaza]

Hallo zusammen,

wir erzeugen in einem Projekt unserer D Umgebung (FS5.2) einen Feature-Transport, das wir gerne auf einem Projekt unserer Q Umgebung (F5.1.) per Auftrags-FeatureTransport importieren möchten.

Dazu nutzen wir einen Filesystem-Storage, welcher auf beiden Projekten/Umgebungen einbunden ist.

Versuche ich das Feature zu importieren, erscheint dabei folgender Fehler:

Kann es sein, dass diese Abwärtskompatibilität nicht gegeben ist?

[bIT_sosswald · Accepted solution]

Hallo,

zumindest das Interface Snippet in der Access-API ist laut JavaDoc erst ab Version 5.2.9 vorhanden.

Die Interfaces DataSnippet und DataSnippetProvider auch erst ab Version 5.2.x.

Wenn diese Klasse intern im Feature-Transport Mechanismus (der meines Wissens nach mit 5.2 ja auch noch einmal verbessert/überarbeitet wurde) verwendet werden, könnte das den Fehler erklären.

Eine endgültige Antwort müssten natürlich die e-Spirit Kollegen geben. 🙂

Grüße

Sandro

[thmarx]

Hallo Michael,

es ist tatsächlich so, dass eine Abwärtskompatibilität nicht garantiert wird.

Davon abgesehen, wäre es nicht sinnvoll, die System mit der gleichen FS Version zu betreiben. Ansonsten besteht immer die Gefahr, dass ein Entwickler neue Funktionen verwendet, die auf dem anderen System noch nicht vorhanden

Gruß

Thorsten

[mbergmann]

Hallo,

Kleine Anmerkung: Streng genommen geht es hier ja gar nicht um Abwärts- sondern um Aufwärts-Kompatibilität, da ja ein Server einer älteren Version die Daten einer neueren lesen können soll. Und dieses Szenario würde übrigens auch bei einem Projekt-Import eine entsprechende Warnung liefern 😉

Ich bin hier der Meinung von Thorsten. Hier besteht natürlich außerdem die "Gefahr", dass irgendetwas auf Q wegen eines Bugs nicht funktioniert, der aber auf D (wegen der neueren Version) nicht mehr vorhanden ist und somit nicht reproduziert werden kann...

Viele Grüße

Michael

[kuaza]

Hallo zusammen,

vielen Dank für die Rückmeldung.

Ich bin vollkommen bei euch, dass das Szenario auf Grund der unterschiedlichen Versionen eher ungünstig ist (diese Systemlinie wird derzeit migriert).

Wir hatten bereits die Vermutung, dass die Aufwärtskompatibiltät 🙂 der entscheidende Faktor ist.

D.h. im Umkehrschluss, dass wir die Automatisierung hier nun erstmal auf Eis legen, bis auf der kompletten Linie wieder dieselben Version eingespielt sind.

Grüße,

Micha