RZoller
Returning Observer

Konfigurieren von gemeinsamen und nicht gemeinsam verwendeten Datenbanken mit der Paketverwaltung

Hallo zusammen,

leider werde ich aus der Doku für die Paketverwaltung nicht schlau genug, um folgendes Problem zu lösen:

Wir haben ein Projekt, das wir als Master-Projekt für weitere Projekte benutzen wollen. Dabei sollen zwei unterschiedliche "Arten" von Datenquellen möglich sein.

Zum einen soll es Datenquellen geben, deren Daten nur über das Masterprojekt gepflegt werden und in den Zielprojekten verwendet werden sollen. Zum anderen gibt es Datenquellen/ Schemata, die von jedem Projekt selbst gepflegt werden sollen.

Wie man den gemeinsamen Datenbank konfiguriert ist in der Dokumentation unter 10.1 beschrieben. Wie bringe ich jetzt aber das Paket dazu bei den nicht gemeinsam verwendeten Datenquellen einen anderen DB-Layer zu verwenden?

ich muss noch dazu sagen, dass alle Datenbanken/ Schemata in dem Masterprojekt über den gleichen Layer in eine DB geschrieben werden.

Muss man hier einen zweiten Layer vorsehen für die unabhängigen Datenbanken/ Schemata?

Vielen Dank für Eure Ideen

René

0 Kudos
3 Replies
witt
I'm new here

Hallo Herr Zoller,

eine erste Antwort auf ihre Frage finden sie hier: javascript:;

Gruß,

Daniel Witt

0 Kudos
RZoller
Returning Observer

Hallo Herr Witt,

vielen Dank für den Hinweis. Vielen Dank für Ihre schnelle Antwort. Die ersten beiden Punkte Ihres Beitrages sind bei uns schon erledigt:

1) Der Masterlayer muss im Slaveprojekt auf Ausgewählt/Schreibgeschützt/Kein Schema Sync stehen. Des weiteren bekommt jeder Slave seinen eigenen Layer zugeordnet

2) Das Paket im Master bekommt einen Workflow spendiert. Der Workflow hat eine automatische Aktivität in der ein Skript ausgeführt wird.


Ich verstehe jetzt noch nicht ganz den Ablauf des Skripts:

2) Das Skript macht jetzt folgendes (Dabei ist es egal ob es ein automatisches oder manuelles Paket ist!)

    Nach dem Ausrollen holt sich das Skript das Schema und macht folgendes

       + Setzen des projektlokalen Layers

       + Setzen des dbName Attributs im Schema

          de.espirit.or.schema.Schema orSchema = schema.getOrSchema();

          orSchema.setName(...);

          templateSchema.setOrSchema(orSchema);


- Wie finde ich den projektlokalen Layer und wie kann ich den projektlokalen Layer setzen? Ich habe nur eine Funktion getLayer mit dem Rückgabetyp String gefunden aber keine Funktion zum setzen.

Außerdem stellt sich mir dir Frage, was bei Aktualisierungen des Pakets passiert. Werden evtl. Änderungen am Schema dann auch in die Schemata die sich in den projektspezifischen Layern befinden übertragen?

0 Kudos

Hallo Herr Zoller,

Wie finde ich den projektlokalen Layer und wie kann ich den projektlokalen Layer setzen? Ich habe nur eine Funktion getLayer mit dem Rückgabetyp String gefunden aber keine Funktion zum setzen.

die Layer holen sie sich über das Projekt (Project#getLayers()). Um die Zielidentifikation zu erleichtern können sie hier zum Vergleich noch mit Project#getNoSchemaSyncLayers() arbeiten. Wenn sie mehrere Layer in einem Projekt verwenden, müssen sie sich eine geeignete Möglichkeit ausdenken, wie sie an den richtigen Zielprojektlayer gelangen.

Das setzen des Layers wird derzeit noch nicht offiziell über die API unterstützt. Hier können sie sich alternativ das XML des Schemas holen und dort die Attribute dbSchema und/oder name setzen.

Zu ihrer zweiten Frage:

Außerdem stellt sich mir dir Frage, was bei Aktualisierungen des Pakets passiert. Werden evtl. Änderungen am Schema dann auch in die Schemata die sich in den projektspezifischen Layern befinden übertragen?

Ja, beim Ausrollen des Paketes würde ja immer der Workflow mit ausgeführt werden. Der Workflow sieht ja vor das Schema zu holen, den Layer zu ermitteln, die Daten zu setzen und schlussendlich einen (unlock)/save durchzuführen. Somit wären Änderungen am Schema auch nachträglich in den Slaves vorhanden.

MfG,

Daniel Witt

0 Kudos