Lokale Datenbanken und Versionsverwaltung

[Der schöne Günther]

Bislang: Projekt enthält eine FireDAC-Connection für SQLite.
Auf dem DFM-Formular steckt eine absolute Pfadangabe wie c:\Users\Günther\Projekt\Data\myDB.db
Zur Laufzeit wird im

Delphi-Quellcode:

BeforeConnect

-Event der Connection die Pfadangabe nochmal in ein relatives Unterverzeichnis .\Data\ umgenudelt.

Meine Frage:
Wenn sich jemand das Projekt aus der Versionsverwaltung holt gibt es bei ihm natürlich kein c:\users\Günther\. Somit muss man hier jedes mal erstmal herumspielen, um die DB-Komponenten zur Entwurfszeit wieder "live" zu bekommen. Geht das besser? Ja, das ist wohl eher FireDAC-spezifisch.

Zweite Frage:
Ich bin unsicher ob die SQLite-DB überhaupt in die Versionsverwaltung gehört. Bleiben wir nicht nur bei einer paar KB großen SQLite-Datenbank zur Konfiguration, nehmen wir ein lokales Datengrab (Sybase) das ein paar Monate nach Auslieferung auf ein paar GB wächst. Ich würde nach dem Auschecken immer gerne schon ein paar Testdaten zum Spielen drin haben.
Ich werde es auch in die Versionsverwaltung packen müssen, oder?

Oder gibt es hier einen Ansatz den ich nicht kenne?

Wäre es annehmbar für das Ausführen vorauszusetzen, dass sich der Entwickler ein künstliches Laufwerk X:\ einrichtet in dem die zu verwendende, lokale Datenbank liegt?
Baut man eine Konfigurationsdatei ein die dann jeder Entwickler vor dem ersten Ausführen so abändern kann muss wie er mag?

Es geht mir nur um die Entwicklung, keine Auslieferung.

[Nersgatt]

Zitat:

Zitat von Der schöne Günther (Beitrag 1264944)

Wäre es annehmbar für das Ausführen vorauszusetzen, dass sich der Entwickler ein künstliches Laufwerk X:\ einrichtet in dem die zu verwendende, lokale Datenbank liegt?

Also ich persönlich habe eine Umgebungsvariable, die in Deinem Fall "c:\Users\Günther\" enthalten würde. In meinem Fall würde "d:\dev\" drin stehen. Alle Pfadangaben zum Projekt sind bei mir entweder relative Pfadangaben oder verwenden diese Umgebungsvariable.
So kann sich jeder seinen Projektordner hinlegen, wo er möchte. Oder man kann ihn leicht verschieben.

[Der schöne Günther]

Klasse Idee! :thumb:

Die Umgebungsvariablen die sich jeder unter Tools -> Optionen -> Umgebungsoptionen -> Umgebungsvariablen selber setzen kann funktionieren tatsächlich. Das beantwortet schon einmal bestens die erste Frage. :bounce1:

[Nersgatt]

Zitat:

Zitat von Der schöne Günther (Beitrag 1264948)

Die Umgebungsvariablen die sich jeder unter Tools -> Optionen -> Umgebungsoptionen -> Umgebungsvariablen selber setzen kann funktionieren tatsächlich.

Wobei das die Umgebungsvariable von Windows sind. Die kannst Du z.B. auch Batchdateien, etc. benutzen.

[himitsu]

Umgebungsvariable: Das geht nur, wenn die Komponente solche Variablen auch auflöst.

Und dann müssen die auch überall vorhanden sein.
Wie ist das zur Laufzeit der Komponente?


Oder du leitest die Komponente ab und verpasst ihr ein neues Property, für den relativen Pfad.
Oder gar zwei Pfade, je DesignTime und Runtime.
Da drin kannst du dann relative Pfade in absolute umwandeln und an das originale Property übergeben und es können auch Pfadvariablen aufgelöst werden, bei der Übergabe.
Das Originalproperty wird dann natürlich auf

Delphi-Quellcode:

stored False

gesetzt.

Falls sich Getter und Setter überschreiben lassen, dann kann man das natürlich auch alles im Originalproperty machen.

[mkinzler]

Datenbanken haben in der Versionsverwaltung nichts zu suchen, es sei den es handelt sich nur um eine Strukturvorlage

[Uwe Raabe]

Zitat:

Zitat von mkinzler (Beitrag 1264953)

Datenbanken haben in der Versionsverwaltung nichts zu suchen, es sei den es handelt sich nur um eine Strukturvorlage

Wobei sich da eigentlich besser der entsprechende SQL-Extract eignet.

[Nersgatt]

Zitat:

Zitat von mkinzler (Beitrag 1264953)

Datenbanken haben in der Versionsverwaltung nichts zu suchen, es sei den es handelt sich nur um eine Strukturvorlage

Prinzipiell stimme ich zu. Strukturvorlagen werden bei mir aber in Form von Scripten abgelegt.
Eine Ausnahme stellen für mich Datenbanken dar, die für Unittests als Testcase benötigt werden. Aber das sind ja sehr spezielle Datenbanken, die sich nicht ständig ändern.
Reine Testdaten (z.B. Kundendaten), etc. gehören aber für mich auch nicht in die Versionverwaltung.

[Der schöne Günther]

DDL, klar, das muss versioniert werden.

Die reinen Daten? Habe ich auf meiner GUI eine Ansicht "Die letzten zwei Wochen" dann brauche ich natürlich auch Daten um mir dort etwas anzeigen zu lassen.

Wovor ich mich halt "fürchte" ist: Würde man diese Daten nicht im Repo mitschleppen ist der Fall gegeben, die Dinge schlichtweg zu "vergessen" für unterwegs mitzunehmen, irgendwo hin zu packen und ggf Konfigurationen anzupassen.

Oder halt immer Daten dafür auf Halde liegen hat, irgendwann ändert sich etwas an der Struktur und ich habe seit Monaten alte Daten auf der Platte liegen die mittlerweile nicht mehr passen.

[mkinzler]

Dann erzeuge die eine "Populate"-Skript und packe dies in Repo