aVogt
Returning Creator

Wiederherstellen (fast) gelöschter Datensätze

Jump to solution

Hallo,

ich habe dummerweise über ein Script die Datensätze einer falschen Tabelle gelöscht.

Die datensätze sind aber nocht nicht vollständig gelöscht, sondern werden noch unter "Freigegebene Datensätze" angezeigt.

mit  

   delEntities = session.getReleasedDeleted("tabelle");

bekomme ich diese. Kann ich in einem Script o.ä. die Datensätze wiederholen?

1 Solution

Accepted Solutions
hoebbel
Crownpeak employee

Den mit dem neusten FS_VALID_FROM, also den Letzten.

Eine eÄnderung führt immer dazu, dass FS_VALID_TO auf das aktuelle Datum gesetzt wird, der Datensatz kopiert wird und im kopierten Datensatz das FS_VALID_FROM auf das aktuelle Datum gesetzt wird. Bei einer Löschoperation wird FS_VALID_TO dann ebenfalls auf das aktuelle Datum gesetzt:

SnagIt1.png

Der Datensatz müsste anschließend im Client als "nicht freigegeben" markiert werden, da es ja eine Änderung (die Löschoperation) gab, die im Freigabstand nicht vorhanden ist.

View solution in original post

0 Kudos
15 Replies
gockel
Crownpeak employee
o.ä. die Datensätze wiederholen?

Im Kontextmenü der Datenquelle befindet sich die gesuchte Funktion:

restore_deleted_entities.jpg

0 Kudos
aVogt
Returning Creator

das ist mir schon bekannt, es handelt sich um mindestens 200 Datensätze und da nur jeweils einer wieder hergesetellt werden kann bin ich da sicher eine Woche beschäftigt.

Geht das nicht "irgendwie" über ein Script. die Entity habe ich ja (siehe oben)

Kleine Korrektur, es sind 5512 Datensätze (da bin ich dann einen Monat mit der manuellen Wiederherstellung beschäftigt)

Übrigens bekomme ich noch ne Warnung, bei der manuellen (ist aber augenblicklich völlig unwichtig):

WARN  31.08.2010 11:45:53.946 (de.espirit.firstspirit.client.io.HttpServerCaller): Large response size: 13,67 MB, de.espirit.firstspirit.manager.ContentManager.executeQuery
31.08.2010 11:45:56 org.apache.commons.httpclient.HttpMethodBase getResponseBody
WARNUNG: Going to buffer response body of large or unknown size. Using getResponseBodyAsStream instead is recommended.

Nachricht geändert durch Andreas Vogt

0 Kudos
aVogt
Returning Creator

Unter Session gibt es ein

restore(Identifier identifier)
          Restore the deleted entity with the identifier.

könnte das passen, aber was ist Identifier?

0 Kudos
hoebbel
Crownpeak employee

Falls nichts anders klappt:

Da es sich ja um eine temporale Datenbank handelt, könnten die Datensätze auch in der Datenbank selber wieder hergestellt werden.

Dazu muss "nur" der Wert von valid_to der entsprechenden Datensätze auf "max(long) [9223372036854775807]" gesetzt werden.

Wenn die Aktion mit einem einzelnen commit durchgeführt wurde, sollten alle Datensätze den selben Zeitstempel aufweisen.

0 Kudos
aVogt
Returning Creator

Guter Tipp, ich werde es versuchen, ich bin mir jetzt nicht ganz sicher, aber wenn Änderungen in der DB geändert werden, bekommt das FS mit (wahrscheinlich schon, da es bestehende DS sind, neue können nicht eingefügt werden)

0 Kudos
hoebbel
Crownpeak employee

Die Datensätze werden [höchstwahrscheinlich] sofort angezeigt werden. Alleridngs bleibt der Repository Eintrag bezüglich der Löschaktion mit dem Skript bestehen. Wenn Sie also die Versionshistorie des Datensatzes prüfen, werden Sie wahrscheinlich ein "gelöscht" darin finden. Je nachdem, was Sie sonst noch Soe bezüglich der datensätze im Repository überprüfen, könnte es Probleme geben [Deshalb auch der einleitende Satz "Falls nichts anderes klappt" Smiley Wink ].

Das [höchstwahrscheinlich] im ersten Satz dieses Postings bezieht sich auf den Datenbank Cache. Wenn die Datensätze nicht sofort sichtbar werden, so reicht es aus, eine beliebige Änderung an einem Datensatz in dieser Tabelle durchzuführen, und sie werden sichtbar. [Es gibt einen Cache, der die initiale Anzeige möglicherweise verhindern könnte]

0 Kudos
aVogt
Returning Creator

ist es wirklich valid_to? da erhalte ich nur 2500 und die haben ein Datum 9.22***E18

0 Kudos
hoebbel
Crownpeak employee

fs_valid_to --> aktueller Stand, gültig ab

fs_valid_from --> gültig ab [aktueller und Release Stand]

fs_release_to --> Freigabestand, gültig bis

Ein Datensatz ist gültig (wird also zum Beispiel im Client angezeigt), wenn die aktuelle Zeit zwischen fs_valid_from und fs_valid_to liegt. Beim Löschen eines Datensatzes wird fs_valid_to auf die aktuelle Zeit gesetzt. Bei Änderungen an einem Datensatz wird beim bisherigen Datensatz fs_valid_to auf das aktuelle Datum gesetzt, ein neuer Datensatz mit den geänderten Werten angelegt und fs_valid_from auf das aktuelle Datum gesetzt und fs_valid_to auf max(long)

Sorry, das "fs_" hatte ich vergessen

0 Kudos
aVogt
Returning Creator

Ok, ich habe nun nach dem Valid gesucht (leider muss ich einen zeitraum nehmen ...)

nun hab ich in der DB aber zwei Einträge mit dem gleichen valid_to. Welchen muss ich nehmen?

SnagIt1.jpg

0 Kudos