DB CREATE-Datum wird von DB Restore-Datum überschrieben - ist DAS wirklich korrekt?

Alles was nicht direkt zu den obigen Foren passt, findet hier Platz. Also Fragen zu allem was generell firebirdspezifisch ist oder sonst einen Bezug zum Forum hat.

Moderator: martin.koeditz

Gerd
Beiträge: 234
Registriert: Di 1. Okt 2019, 17:13

vr2 hat geschrieben: Do 10. Nov 2022, 00:37 Hallo Gerd,

... welche Aussagekraft hätte das?

Grüße, Volker
Hallo Volker.

Es geht um die Vermeidung von Missverständlichkeit.
Das Erstelldatum einer zu sichernden Datenbank ist aus meiner bescheidenen Sichtweise nicht das eingesetzte Wiederherstellungsdatum zum Zeitpunkt der Rücksicherung dieser Datenbank.
Vielleicht hat ja @Martin recht, indem er anklingen lässt, dass es wohl in den philosophischen Bereich abdriftet.
Man kann aber auch zu dem Schluss kommen, dass man die Besonderheiten der EDV nutzt / zum Teil nutzt / nicht nutzt, um es sich vielleicht leichter zu machen, was sicherlich oft ausreicht.

* * *

Ich sichere mit gbak eine Datenbank.
Zu dieser Datenbank gehört nun mal auch der von Firebird dankender Weise erzeugte Erstelldatum-Stempel (SHOW DATABASE;).
Dieser Stempel landet also mit in der Sicherungsdatei (ich gehe davon aus, dass es so stattfindet).

In einer Sicherungsdatei befindet sich keine neue Datenbank, sondern eine bereits Vorhandene mit besagten Erstelldatum.
Wird jetzt die Datenbank wiederhergestellt, dann erwarte ich, dass auch dieses Erstelldatum unverändert angezeigt wird.
Warum?
Eine Sicherungsdatei kann also gegebenenfalls eine komplette vorhandene Datenbank beinhalten.
Nur, mit ihr ist etwas geschehen. Sie wurde gesichert.
Und ich finde, dass Firebird noch einen Schritt weiter gehen sollte und künftig neben dem Erstelldatum auch ein (völlig allgemein gehaltenes) Änderungsdatum als Stempel vorhalten könnte. Von Hause aus integriert wäre so der Informationswert Erstelldatum/Änderungsdatum unmissverständlich.

Darüber könnte/sollte/darf breit nachgedacht werden ... Ich bin darüber 'gestolpert' - andere bei einem anderen DB-System ebenso.

Viele Grüße
Gerd
Linux Mint 21.3 Virginia Cinnamon 6.0.4
Firebird 5.0.0., Embedded, ISQL: LI-V5.0.0.1306
Lazarus 3.0.0 - FPC 3.2.2
bfuerchau
Beiträge: 485
Registriert: Mo 7. Mai 2018, 18:09
Kontaktdaten:

Andere machen es auch nicht besser:
https://sqlandme.com/2013/02/19/sql-ser ... tion-time/
Da verhält sich die Firebird eben wie der Standard.

Der Datenbank-Backup per gback ist eine spezielle Speicherung.
Wenn du einen Zip (außerhalp von Betriebszeiten) machst und wiederherstellst, behältst hast du das Ursprungsdatum :) .
Gerd
Beiträge: 234
Registriert: Di 1. Okt 2019, 17:13

bfuerchau hat geschrieben: Do 10. Nov 2022, 13:39 ...
Der Datenbank-Backup per gback ist eine spezielle Speicherung.
...
... die man regelmäßig durchführen sollte.
Und wenn man das so "Gespeicherte" wiederherstellt, ist das Erstelldatum futsch (siehe bitte oben).
--> Das ließe sich womöglich verhindern. Im Anschluss daran wird Firebird noch besser sein - oder etwa nicht.


Viele Grüße
Gerd
Linux Mint 21.3 Virginia Cinnamon 6.0.4
Firebird 5.0.0., Embedded, ISQL: LI-V5.0.0.1306
Lazarus 3.0.0 - FPC 3.2.2
Benutzeravatar
martin.koeditz
Beiträge: 443
Registriert: Sa 31. Mär 2018, 14:35

Im Anschluss daran wird Firebird noch besser sein - oder etwa nicht.
Jepp, oder einfach nur um eine Funktion reicher. ;)
Martin Köditz
it & synergy GmbH
Gerd
Beiträge: 234
Registriert: Di 1. Okt 2019, 17:13

Hallo in die Runde.

Wie könnten wir zukünftig mit solchen Themen (wie dieses) im Firebird-Forum umgehen?

:: Eine Abstimmungsseite einrichten, nur für Forum-Mitglieder?
Dazu zwei bis drei Sätze, um was es geht - und wenn aktiv eine gewisse Mitgliederanzahl x JA/NEIN gewählt hat, dann als fundierten Vorschlag an die Entwickler unterbreiten.

:: Sollte vielleicht der Versuch unternommen werden in anderen vielleicht auch ausländischen Firebird-Foren Interessenten zu finden - irgendwie?

Alles in allen hat dann der Einreichende wohl mehr in der Rückhand, und kann bei den Entwicklern 'nachhaltiger' argumentieren.

Ansonsten besteht eben die latente Möglichkeit, dass so etwas im Sande verläuft.

Bisschen was könnte ich übernehmen. Aber den diesbezüglichen Kontakt zu den Firebird-Entwicklern sollte ein anderer aufnehmen ...


Viele Grüße
Gerd
Linux Mint 21.3 Virginia Cinnamon 6.0.4
Firebird 5.0.0., Embedded, ISQL: LI-V5.0.0.1306
Lazarus 3.0.0 - FPC 3.2.2
vr2
Beiträge: 214
Registriert: Fr 13. Apr 2018, 00:13

Hallo Gerd,

Im alten Firebird-Tracker JIRA gab es die Möglichkeit, einen Feature Request hochzuwählen. So wie ich das sehe, ist das nach dem Umzug auf github nicht mehr möglich, ich bin allerdings mit den Möglichkeiten von github nicht sehr vertraut, vielleicht können andere etwas dazu sagen. Zumindest gibt es bei github den Mechanismus Feature Request, und wenn Du ein Feature sinnvoll findest, wäre das der richtige Weg, Du brauchst nichts weiter als einen github-account dafür.

Ich kann schon Deine Unzufriedenheit verstehen, dass hier niemand wirklich einsteigt auf die Geschichte mit dem creation date. Ich nutze Firebird seit Tag 1 und hab es tatsächlich noch nie vermisst. Für mich ist eine Datenbank ein Stück Code, und genau wie dort ist es für mich in jeder Hinsicht egal, wann dieser Code zum ersten Mal gespeichert wurde. Code ist im Idealfall ein lebendiges Gebilde, das ständig verändert wird. Was dort irgendwann mal stand, wurde teilweise mit der Zeit verändert oder komplett durch etwas anderes ersetzt oder ganz gelöscht. Ursprüngliche Erstellungsdaten sagen da einfach nichts aus. Falls man eine Versionsgeschichte braucht, gibt es technische Verfahren und Lösungen dafür (Versionsverwaltungen, Versionsnummern, Kommentare, Verweise in Ticketsysteme, Logs). Wenn man ein Produkt vertreibt, wird oft über den Copyright-Hinweis signalisiert, dass es bereits seit Jahr x existiert und damit Kontinuität und Ausgereiftheit ausgedrückt. Aber auch da kann man reinschreiben, was man will, es ist eher Marketing und sagt belastbar nichts über die Qualität aus oder wieviel der aktuelle Code noch mit dem von vor x Jahren zu tun hat. Der Code könnte zwischenzeitlich sogar komplett neu geschrieben worden sein, dann wäre ein altes Erstellungsdatum sogar irreführend.

Grüße, Volker
Benutzeravatar
martin.koeditz
Beiträge: 443
Registriert: Sa 31. Mär 2018, 14:35

Moin,

ich sehe das wie Volker. Jede Anfrage ist legitim und kann als Feature Request hinterlegt werden. Üblicherweise werden diese dann auch hier konkret besprochen. Im Zweifel kann ich diesen auch in deinem Sinne einstellen.

Gruß
Martin
Martin Köditz
it & synergy GmbH
bfuerchau
Beiträge: 485
Registriert: Mo 7. Mai 2018, 18:09
Kontaktdaten:

Für uns ist das CreationDate auch wichtig aber genau aus anderer Richtung heraus.
Wir machen wöchtlich einen Save & Restore der DB, da durch unserer intensive Nutzung als Datawarehouse sonst einfach zu viele Satzversionen übrigbleiben, die der Sweeper manchmal nicht wegbekommt. Unsere Transaktionen umfassen durchaus schon mahl ein paar 100.000 Zeilen.
Dazu kommen Einschränkungen wie Anzahl Änderungen an einer Tabelle, die dadurch auch zurückgesetzt werden.
Somit können wir per SQL automatisiert feststellen, dass der Restore erfolgreich war und wann er das letzte Mal durchgeführt wurde.
Wenn das Creationdate beibehalten würde ohne ein RestoreDate einzuführen wäre diese Form der Kontrolle nicht mehr gewährleistet.

Alles hat eben seine (mindestens) 2 Seiten.
Gerd
Beiträge: 234
Registriert: Di 1. Okt 2019, 17:13

Hallo in die Runde.

Volker:
Im alten Firebird-Tracker JIRA gab es die Möglichkeit, einen Feature Request hochzuwählen.

Das hatte ich hier im Forum so erfahren, einen Account dort eingerichtet und seinerzeit auch 2 - 3 Mal genutzt. Nun ist diese Möglichkeit aber in der Tat weg und mein Account auch, einfach so.


Volker:
... ich bin allerdings mit den Möglichkeiten von github nicht sehr vertraut,

Ich auch nicht. Kann mit dieser Plattform nicht so recht was anfangen.


Volker:
... Zumindest gibt es bei github den Mechanismus Feature Request, und wenn Du ein Feature sinnvoll findest, wäre das der richtige Weg, Du brauchst nichts weiter als einen github-account dafür. ...

Nein, eigentlich möchte ich dort keinen Account haben.
(Das sollte aus meiner Sicht irgendwann anders gelöst werden. Einen Account einrichten, nur um einen Vorschlag einzureichen, das geht doch bestimmt auch deutlich einfacher!)


Volker:
Ich kann schon Deine Unzufriedenheit verstehen, dass hier niemand wirklich einsteigt auf die Geschichte mit dem creation date.

Oh, nein, ich bin nicht unzufrieden!
Bin von den bisherigen Antworten und Sichtweisen sogar positiv überrascht. Alles in Ordnung so weit ... :)
Ich möchte nur anregen, dass darüber - sicherlich nicht zum ersten Male - nachgedacht wird.
Ich sage mir in meinem Stübchen einfach; wo Stempel drauf steht - sollte auch Stempel drin sein. Zugegeben, mich irritiert der derzeitige Zustand, kann aber auch damit leben.

Volker:
Für mich ist eine Datenbank ein Stück Code, ...

Kann ich nachvollziehen. Für mich ist eine von MIR erstellte Firebird Datenbank immer etwas Besonderes, denn sie wurde erschaffen!
Wann oder wie oft ich Code speichere, überlege ich mir dabei auch nicht. Es gibt aber einen Einstiegspunkt und der, so scheint es mir, ist es wert fixiert zu werden.
Wichtig ist dann noch die verlässliche Datenbank-Sicherung. Und Wiederherstellung.

Volker:
Falls man eine Versionsgeschichte braucht, gibt es technische Verfahren und Lösungen dafür (Versionsverwaltungen, Versionsnummern, Kommentare, Verweise in Ticketsysteme, Logs). Wenn man ein Produkt vertreibt, wird oft über den Copyright-Hinweis signalisiert, dass es bereits seit Jahr x existiert und damit Kontinuität und Ausgereiftheit ausgedrückt. Aber auch da kann man reinschreiben, was man will, es ist eher Marketing und sagt belastbar nichts über die Qualität aus oder wieviel der aktuelle Code noch mit dem von vor x Jahren zu tun hat. Der Code könnte zwischenzeitlich sogar komplett neu geschrieben worden sein, dann wäre ein altes Erstellungsdatum sogar irreführend.

Ich verstehe Dich!
Jedoch diese Passage ist geeignet, das Thema hier aus den Fugen geraten zu lassen. :-)
Ich versuche eine sehr kurze Antwort zu geben und wiederhole mich dabei zum Teil:
Wenn ich bei jemanden unter Linux eine Firebird Datenbank mittels Firebird ISQL-Tool erstelle, sollte wenigstens das Erstelldatum als solches erhalten bleiben - von Hause aus bitte, das fände ich perfekt. Das tut es nicht, wie wir wissen, also beame ich es (als Übergangslösung) in den Datenbank-Kommentar oder bringe es in einer DB-Tabelle "Entwicklung" unter. Mit Versionsgeschichte hätte das wohl eher nichts zu tun.


Martin:
Im Zweifel kann ich diesen auch in deinem Sinne einstellen.

Danke, gerne. :-)
Aber zurzeit bin ich hier der Einzige, der sich dafür 'erwärmt' - hat wohl wenig Sinn sich die Arbeit zu machen.

Ich werde es an anderer Kontaktstelle tun. Jedoch bedeutet diese Stelle ein großer Umweg. Fraglich ist zudem, ob die Funktion es bis in das Firebird-System schafft.



bfuerchau:
Für uns ist das CreationDate auch wichtig aber genau aus anderer Richtung heraus.
...
Wenn das Creationdate beibehalten würde ohne ein RestoreDate einzuführen wäre diese Form der Kontrolle nicht mehr gewährleistet.



Und das genau soll so nicht stattfinden.
Sehr wahrscheinlich wird ein Feld Änderungsdatum (RestoreDate) eingeführt werden müssen. Die entsprechenden gbak-Schalter müssten angepasst werden. Das entscheiden andere.


Viele Grüße
Gerd
Linux Mint 21.3 Virginia Cinnamon 6.0.4
Firebird 5.0.0., Embedded, ISQL: LI-V5.0.0.1306
Lazarus 3.0.0 - FPC 3.2.2
Gerd
Beiträge: 234
Registriert: Di 1. Okt 2019, 17:13

Hallo in die Runde.

So, ich habe das Anliegen via E-Mail formuliert und abgeschickt.

Vielleicht landet ja die E-Mail beim (ehemaligen) FirebirdSQL-Chefentwickler Dmitry Yemanov* auf dem Rechner.
Mehr unternehme ICH erst mal nicht, bin aber gerne bereit, Aufgaben zu übernehmen.

* Man wird ja noch Träumen dürfen. :D

Mir hat der Verlauf hier echt Spaß gemacht und darüber hinaus auch neue Sichten vermittelt. Das hängt wohl damit zusammen, wie wir alle unterwegs sind.

Danke an alle Beteiligten.

Viele Grüße
Gerd
Linux Mint 21.3 Virginia Cinnamon 6.0.4
Firebird 5.0.0., Embedded, ISQL: LI-V5.0.0.1306
Lazarus 3.0.0 - FPC 3.2.2
Antworten