Technical Support Knowledge Base

[TechSupport]

FirstSpirit benutzt UUIDs für die eindeutige Identifikation von Datensätzen. Diese UUIDs, im folgenden GIDs genannt, werden beispielsweise für die Verlinkung von Datensätzen verwendet, wenn diese nicht über eine Fremdschlüsselbeziehung in der Datenbank abgebildet werden und auch für die Identifikation von Datensätzen, wenn diese mittels Content Transport in ein Projekt eingespielt werden (gibt es einen Datensatz mit derselben GID, so wird dieser aktualisiert, ansonsten wird ein neuer Datensatz angelegt).

Aus technischen Gründen werden diese GIDs an zwei Stellen gespeichert. Einmal in der Spalte FS_GID an dem Datensatz selber und einmal in einer Backend Datenbank, genannt Registry.

Die Fehlermeldung

de.espirit.firstspirit.common.DuplicateGidException: Entry already exits with different gid '<GID>': EntityGidEntry[<GID> | schema=<ID des Schemas 1>, dbTable=<Datenbanktabelle 1>, id=<FS_ID 1>], EntityGidEntry[<GID> | schema=<ID des Schemas 2>, dbTable=<Datenbanktabelle 2>, id=<FS_ID 2>]

bedeutet nun, dass FirstSpirit festgestellt hat, dass die GID, die beim Speichern des aktuellen Datensatzes verwendet werden soll, bereits für einen anderen Datensatz verwendet wird.

Mögliche Ursachen

1. Das Schema inkl. Daten wurde zweimal importiert. Hierbei spielt es keine Rolle, ob das Schema vor dem zweiten Import gelöscht wurde oder nicht. Oder die Datenbank wird [z.B. über zwei verschiedene Layer] zweimal im Projekt angebunden.Erkennbar ist dies daran, dass sich in der Fehlermeldung nur die ID des Schemas unterscheidet.
2. Der Datensatz wurde in der Datenbank dupliziert oder der Wert in der FS_GID Spalte wurde auf einen anderen Datensatz kopiert oder es wurde eine neue GID per API für den Datensatz geschrieben, die bereits für einen anderen Datensatz besteht.Erkennbar ist dies daran, dass sich in der Fehlermeldung die ID des Datensatzes unterscheidet und/oder der Name der Tabelle und/oder der Name des Schemas.
3. Die Datenbank Tabelle wird zweimal im Schema bzw. in verschiedenen Schemata referenziert.Erkennbar ist dies daran, dass die beiden FS_ID in der Fehlermeldung identisch sind. Der Name des Schemas und/oder der Tabelle unterscheidet sich aber.
4. Das Projekt wurde ohne Datenbankinhalte exportiert und wieder importiert und es wird nun versucht, die Datenbankinhalte per ContentTransport zu übernehmen.

Auswirkungen

• In allen Fällen sind die Auswirkungen des Problems identisch. Der Datensatz, dessen GID bereits für einen anderen Datensatz in der Registry gespeichert wurde, lässt sich nicht speichern.

Lösungen

1. Wenn dieselben Datenbankinhalte über zwei verschiedene Schemata referenziert werden, sollte das entsprechende Konzept überdacht werden. Wenn das Schema zweimal importiert wurde, so müssen die fehlerhaften GIDs aus der Registry entfernt werden. Je nach Anzahl der Datensätze kann dies entweder manuell für jeden Datensatz geschehen oder es können alle GIDs für alle Datensätze des Projektes gelöscht werden. Eine entsprechende Anleitung für die beiden Fälle bekommen Sie von unserem Technical Support. Bitte stellen Sie dazu ein Ticket mit der entsprechenden Fehlerbeschreibung ein.Aus Performancegründen sollten danach die GIDs neu gesetzt werden. Dies ist mit den unten stehenden Skript möglich
2. Da es sich hierbei wahrscheinlich nur um wenige betroffene Datensätze handelt, sollten diese gelöscht und deren GIDs manuell bereinigt werden. Eine entsprechende Anleitung für die Bereinigung bekommen Sie von unserem Technical Support.
3. Die doppelte Tabelle sollte aus dem Schema entfernt werden.
4. Die Datensätze sollten direkt in der Datenbank in den neuen Tabellenraum transferiert werden, wie dies für diesen Anwendungsfall vorgesehen ist. Ist dies nicht möglich, so müssen die GID Informationen in der Registry gelöscht werden. Eine entsprechende Anleitung bekommen Sie von unserem Technical Support. Bitte stellen Sie dazu ein Ticket mit der entsprechenden Fehlerbeschreibung ein.Aus Performancegründen sollten danach die GIDs neu gesetzt werden. Dies ist mit den unten stehenden Skript möglich.

Hinweis:

Dieses Skript darf nicht verwendet werden, wenn CaaS V3 in diesem Projekt verwendet wird. In diesem Fall kontaktieren Sie bitte den Technical Support wie gewohnt über unser Ticketsystem.

import de.espirit.firstspirit.agency.StoreAgent;

import de.espirit.firstspirit.access.store.Store;

import de.espirit.firstspirit.common.GidAgent;

import de.espirit.firstspirit.access.store.contentstore.Content2;

storeAgent  = context.requestSpecialist(StoreAgent.TYPE);

contentStore = storeAgent.getStore(Store.Type.CONTENTSTORE);

gidAgent = context.requireSpecialist(GidAgent.TYPE);

storeElements = contentStore.getChildren(Content2.class,true);

storeElementCounter = storeElements.iterator();

while (storeElementCounter.hasNext()) {

  content2 = storeElementCounter.next();

  schema = content2.getSchema(); 

  try {

    orSession = gidAgent.migrateSchema(schema);

    select = orSession.createSelect(content2.getEntityType().getName());

    entityList = orSession.executeQuery(select);

    context.logInfo("EntityList.size(): " + entityList.size().toString());

//    gidAdaptionResult = gidAgent.adaptGid(schema, entityList, false);

//    context.logInfo("gidAdaptionResult.size(): " + gidAdaptionResult.size().toString());

    for (entity:entityList) {

      gidAgent.adaptGid(schema, Collections.singletonMap(entity, entity.getGid()), true);

    }

  } catch (Exception e) {

    context.logError("ERROR: "+e);

  }

}

Anmerkung: Die beiden auskommentierten Zeilen sollte man einkommentieren, wenn man nicht sicherstellen kann, dass alle Datensätze bereits eine GID haben (das Projekt also aus der Version 4 stammt und man die GIDs noch nicht per Skript gesetzt hat)