Questions & Answers

[rolf_siebachmey]

Hallo zusammen,

Auf unseren Testumgebungen haben wir mehrere Projekte, in denen wir das selbe Feature installieren wollen. Dieses Feature beinhaltet neben ein paar Templates auch ein Datenbank-Schema.

Das Datenbank-Schema wurde in jedem der Zielprojekte bereits manuell angelegt. Außderdem nutzen alle Zielprojekt für das Schema den gleichen Datenbank-Layer. Vor dem Einspielen des Features kann ich also in jedem Zielprojekt eigene Daten in den Datenquellen pflegen und habe keinen Zugriff auf die Daten der anderen Projekte.

Wenn nun das Feature in den Zielprojekten eingespielt wird, ändert sich in jedem der Zielprojekte die Datenbank-Schema-Einstellung und es greifen nach dem Update alle Zielprojekte auf die gleichen Daten zu.

Mein Ursprüngliches Verhalten kann ich nur wieder herstellen, wenn ich in jedem der Zeilprojekte im schema-xml die Attribute dbname und name auf den Stand vor dem Update zurücksetze. Das halte ich bei der hohen Zahl von Projekten in Zukunft für kaum machbar.

Meine Frage hierzu, ist dieses Verhalten gewünscht? Meine Erwartung wäre gewesen, dass diese Einstellungen von dem Feature-Install nicht verändert werden, sondern lediglich neue Tabellen/Spalten angelegt werden.

Beste Grüße

Rolf

[rednoss]

Hallo Rolf,

meinst Du CorporateContent oder CorporateTransport? Um zu verhindern, dass die Datenbankschema-Einstellungen überschrieben werden kannst Du in den Projekteinstellungen unter dem Punkt Datenbanken den Haken bei "Kein Schema Sync" setzen.

Viele Grüße

Rene

[pavone]

Hallo Rolf,

benötigst Du noch weitere Hilfe oder hat Dir Renes Antwort bereits geholfen? In diesem Fall wäre es super, wenn Du die "richtige Antwort" entsprechend markierst, damit auch andere Community-Teilnehmer diese auf den ersten Blick finden. Solltest Du zwischenzeitlich eine eigene Lösung gefunden haben, wäre es nett, wenn Du diese hier bereitstellst.

Viele Grüße

Tim

[vijay1v]

Schema update can be a straight forward unless the schema copied from another schema which got bad references. If the table exist in the underlying database, it will update otherwise it will create new table.

Content2 transport can be troublesome because in the same server there can't be 2 rows FS_GID means Content2 can not be transaported between 2 projects in the same FS server and content transport is totally unreliable if foreign key relationships applied on the table.

Its better to use scripting to do Content2 transport across the projects which can be perfectly controlled as per the requirement.