Probleme beim Import eines Projektes mit den FSDevTools
Author: christian_brock
Publication Date: 9/17/2019 15:13
Hallo zusammen,
ich habe aktuell ein Problem beim Import eines Projektes mit dem FSDevTools.
Kurz etwas zur Ausgangssituation:
Ich habe ein kleines Testprojekt mit 2 Datenbanken.
Dieses Projekt habe ich exportiert und möchte es als Kopie neu importieren. In dem neu importierten Projekt soll dann auch der Exam Datenbank-Layer verwendet werden und für den Layer "derby_project133069_0" soll ein neuer Layer angelegt werden. Dies habe ich dann mit dem FSDevTools versucht. Jedoch wurde immer sowohl für den Exam als auch für den derby_project133069_0 Layer, im importierten Projekt ein neuer Layer angelegt.
Hier der Aufruf für das cli Tool:
./fs-cli.sh -port 9000 project import --importProjectName "Testprojekt Java 11" -ipd "Temporäres Projekt für Java 11 Tests" -pf ../../../../20190917_125548_testprojekt.tar.gz
Vielleicht kann mir jemand bei dieser Problematik helfen oder sagen, ob das gewünschte Verhalten überhaupt mit dem FsDevTools möglich ist.
Vielen Dank schon mal :smileyhappy:
-
Author: hoebbel - 9/19/2019 8:51
Hallo Christian,
ab der fs-cli Version 2.5.1 sollte folgender Aufruf zum gewünschten Ergebnis führen:
./fs-cli.sh -port 9000 project import --importProjectName "Testprojekt Java 11" -ipd "Temporäres Projekt für Java 11 Tests" -pf ../../../../20190917_125548_testprojekt.tar.gz -dlm Exam:Exam
Wenn das nicht klappt, stell bitte ein Ticket bei unserem Tech Support ein, damit das genauer untersucht wird.
Anmerkung:
In älteren fs-cli Versionen gab es noch einen Bug, durch den immer ein Derby Layer angelegt wurde.
Viele Grüße,
Holger
0 -
Author: christian_brock - 9/20/2019 11:26
Hallo Holger,
danke für deine Antwort. Ich habe es mit deinem Aufruf probiert, dies hat jedoch leider nicht funktioniert.
Ich habe daraufhin ein Ticket erstellt. Dabei kam heraus, dass es sich dabei um ein bekanntes Problem in der Version 2.5.2 handelt und in der Version 2.5.3 behoben . wird.
Viele Grüße
Christian
0 -
Author: hoebbel - 9/20/2019 12:07
Hallo Christian,
wenn Du es mit der Version 2.5.1 (oder neuer, aktueller Release ist 2.5.2) versucht hast, hätte es funktionieren müssen. Die Änderung bezüglich Layer Mapping (interne ID DEVEX-289) ist in dem Release enthalten.
Sofern wir nicht die Rückmeldung bekommen, dass es mit 2.5.2 nicht funktioniert, wird es diesbezüglich in 2.5.3 keine weitere Änderung geben :smileywink:
Syntax für -dlm ist <Name des Quelllayers>:<Name des Ziellayers>
Die beiden Werte (Exam:Exam) hatte ich aufgrund der initialen Anfrage geraten. Sofern Du die aktuelle fs-cli Version nutzt, liegt es vielleicht daran, dass zumindest einer der beiden Namen falsch ist?
Es könnte auch daran liegen, dass Exam ein Read-Only/No-Schema-Sync Layer ist. Kannst Du mal testen, ob es mit einem anderen Layer, der auf eine externe Datenbank, die nicht Read-Only/No-Schema-Sync angebunden ist, funktioniert?
Viele Grüße,
Holger
0 -
Author: lobanova - 11/22/2019 22:35
Hallo.
Wir haben auch das Problem mit dem Projekt Import mit einem Read-Only/No-Schema-Sync Layer.
Die Idee ist - eine externe Datenbank für ein bestimmtes DB Schema zwischen mehreren Projekten zu scharen. Die Datenbank existiert bereits und sollte nicht nochmal beim Projekt Import angelegt werden.
Wenn wir beim Import das Layer Mapping angeben, dann kommt der Fehler:
Skipping schema import, layer 'external_db' is either not syncable or read only
Unable to sync schema - java.lang.NullPointerException
FSVersion=5.2.190808.78484#3050;JDK=1.8.0_201 64bit Oracle Corporation;OS=Linux 3.16.0-5-amd64 amd64;Date=30.10.2019 00:45:11
java.lang.NullPointerException
at de.espirit.firstspirit.server.export.importhandler.SchemaConfigHandler.analyse(SchemaConfigHandler.java:342)
at de.espirit.firstspirit.server.export.ProjectImporter.call(ProjectImporter.java:357)
at de.espirit.firstspirit.server.export.ProjectImporter.call(ProjectImporter.java:66)
at de.espirit.firstspirit.server.action.ServerActionManagerImpl$ServerActionCallableWrapper.call(ServerActionManagerImpl.java:416)
at de.espirit.firstspirit.server.action.ServerActionManagerImpl$ServerActionCallableWrapper.call(ServerActionManagerImpl.java:397)
at de.espirit.firstspirit.server.ExecutionManagerImpl$ExtendedCallable.call(ExecutionManagerImpl.java:590)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at de.espirit.common.util.BoundedExecutorService$RunnableWrapper.run(BoundedExecutorService.java:436)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:748)
at de.espirit.common.util.SuspendableThread.run(SuspendableThread.java:56)
Nach dem Import zwar ist die DB external_schema im Projekt da, aber sie ist leer: keine DB Tabellen vorhanden, die Tabellenvorlagen aber schon. Und wenn man versucht eine der verbundenenen Datenquellen zu öffnen, dann kriegt man den Fehler beim Datenbankzugriff.
Wenn wir beim Import kein Layer Mapping angeben, dann wird ein neuer Derby Layer angelegt, was auch nicht gewünscht ist. In dem Fall die DB external_schema ist mit einer Derby DB verbunden, und importierte Datenquellen sind dadurch leer.
Also, meine Frage ist:
Geht es überhaupt eine externe Datenbank mit dem Read-Only/No-Schema-Sync Layer via fs-cli zu importieren und welche Parameter dafür angegeben werden sollen?
Bzw wie ist das Verfahren beim Import von solchen DBs?
MfG,
Olga
0
Bitte melden Sie sich an, um einen Kommentar zu hinterlassen.
Kommentare
4 Kommentare