Re: FOREIGN KEY

Am Monday 26 January 2009 12:46:09 schrieb Andreas 'ads' Scherbaum:
> Hallo,
>
> On Mon, 26 Jan 2009 00:20:53 +0100 Olaf Radicke wrote:
> > Am Sunday 25 January 2009 21:49:37 schrieb Andreas Kretschmer:
> >
> > Also, PostgreSQL trifft keine Schuld. Mit pgAdminIII ist nicht immer
> > zuverlässig. So fragt mich das Tool jedesmal nach dem Passwort der DB und
> > jedes mal fragt pgAdminIII ob es das Passwort speichern soll, und jedes
> > mal sage ich "ja" und trotzdem werde ich wieder nach dem Passwort
> > gefragt.
>
> Das funktioniert hier ohne Probleme. Aber so oft nutze ich pgAdminIII
> nicht.

Ich verwende hier Version 1.4.8 unter Debian testing.

> > Ich sitze jetzt in dem Dilemma, das ich jetzt nicht genau weiß, wie die
> > aktuellen Tabellen meiner Anwender meiner Software aussehen. Mit jedem
> > Update wächst die Gefahr, das die Tabellen die durch eine Neuinstallation
> > angelegt werden, anders aussehen, als die, die den Update-Prozess
> > durchlaufen haben. Durch das Refactoring wurde das Problem auch noch
> > verschärft.
>
> Nun, psql zeigt die Informationen doch richtig an, oder? Wo ist das
> Problem?
>
> Wenn sich allerdings Update und Neuinstallation unterscheiden, ist euer
> Update Prozess gehörig faul. Wie genau schaut so ein Update bei euch
> aus?

Also. Hier findest du die Aktuelle Version:
http://sourceforge.net/project/showfiles.php?group_id=182673&package_id=241269
Als LiveCD mit "sudo su" und "su postgres" wirst du dir die DB detailliert
ansehen können.

Unter
http://sourceforge.net/project/showfiles.php?group_id=182673&package_id=307319

Findest du eine LiveCD mit einem SVN-Snapshot vom 23.1.09

Und hier findest du das geplante Update von 0.x.x auf 1.x.x:
http://artikel23.svn.sourceforge.net/viewvc/artikel23/trunk/doc/table_updates/update_1.0.0.sql?view=log

Ich will ja nicht ausschlissen, das wir was vergurkt haben, beim
Programmieren. Das Programm kommuniziert über die Lib npsql mit PostgreSQL
und die war/ist auch nicht Fehlerfrei. So gab es z.B. Probleme mit dem
Maskieren von Sonderzeichen (Funktionszeichen). Zu dem habe ich die
Entwicklerdatenbank unzählige male mit fehlerhaften Programmen oder Tests
zerschossen und immer wieder neu eingespielt. In den Letzten zwei Jahren der
Entwicklung habe ich das Programm auf meinen PC knapp 33.000 mal neu
übersetzt und getestet. Es währe ein Wunder, wenn sich da keine Fehler
eingeschlichen hätten. Die große Preisfrage lautet: wie gehe ich am besten
damit um und wie kann ich sicherstellen, das alle nach dem Upgrade die
Gleichen Tabellenstruckturen haben?

> > Vielleicht muss ich für den Upgrade einfach Test schreiben um herraus zu
> > bekommen, ob die Tabellen so aussehen wie sie sollen. Also
> > Dummy-Datensätze schreiben, lesen und löschen. Oh, mich grausts... Nur
> > allein das Refactoring-Upgrade hat schon 1500 Zeilen SQL.
>
> *brr* Testdaten in einer Produktivumgebung? Was genau wird das zum
> Schluss? Die Tabellenstruktur kann man auch ohne Testdaten
> herausfinden. Da gibt es zum einen "information_schema" und zum anderen
> die Systemkataloge. Beides kann man abfragen und die Struktur
> herausfinden.

Den Vorteil von Testdaten sehe ich darin, das man prüft, welche Operationen
alle gehen müssen und welche nicht gehen dürfen. Bei Fehlern sucht man dann
nach der Ursache, die vielerlei Gründe haben kann. Gut, das mit einem
Produktivsystem zu machen, ist wahrscheinlich nicht so eine glorreiche Idee.
Aber als Entwicklertool? Ein vorgeschlagener Weg, fängt das Problem von der
anderen Seite an aufzurollen. Den Nachteil den ich sehe ist, das man
eigentlich das Problem schon kennen muss, um sinnvolle Tests zu machen.
Ansonsten gibt es einfach zufiel worauf man testen könnte.

MfG

Olaf

--
Meine Rechtschreibfehler stehen unter der Creative Commons Lizenz.
(Bearbeitungen und Weitergabe unter gleichen Bedingungen):
http://creativecommons.org/licenses/by-sa/2.0/de/