Search the FirstSpirit Knowledge Base
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?
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:
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.
o.ä. die Datensätze wiederholen?
Im Kontextmenü der Datenquelle befindet sich die gesuchte Funktion:
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
Unter Session gibt es ein
restore(Identifier identifier)
Restore the deleted entity with the identifier
.
könnte das passen, aber was ist Identifier?
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.
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)
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" ].
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]
ist es wirklich valid_to? da erhalte ich nur 2500 und die haben ein Datum 9.22***E18
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
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?