Wenn ich aus meinem Framework ein


mache, bekomme ich eine zutreffende Antwort (1 Zeile mit column_name = 'address_id'). Lasse ich mir den Text loggen und füge ihn in psql ein, findet er keine Zeile.

Ich habe auch schon abgetippt, um etwaige Code-Probleme auszuschließen.

Wieso führt psql die Anfrage nicht richtig aus?
Jemand eine Ahnung?
Thomas?

constraint_column_usage, nicht constraint_table_sage.


Ich habe herausgefunden, woran es liegt. Ich war in psql noch als postgres eingeloggt, weil ich vorher den Server gestartet hatte. Offenbar teilt er diese Information nicht jedem mit? Das wäre für mich unter Umständen fatal. Muss mal schauen.

Ob das wirklich so gewollte ist ...

Zum Hintergrund (deinen KOmmentar habe ich nicht ganz verstanden.) Bisher scanne ch nur nach einem Primary Key, damit ich Änderungen durchführen kann. Derzeit habe ich einen simplen einspaltigen PK. Ich wollte mich gerade an die Änderungen machen:
a) Jedes Constraints kann vom Designer aus gesetzt werden
b) Der PK kann zusammengesetzt sein
c) Es gibt nur Table-Constraints

Da bekam ich auf einmal überraschende Ergebnisse beim Debuggen in psql.

Scheiße, du hast recht. Naja, da muss ich wohl zu table_constraints wechseln.

Mal schauen, wie ich das mache. Heute wird mal wieder eine lange Nacht. Gibt es Fußball?

Das ist sogar von vorzüglicher Scheiße. Ich kann schlicht nicht herausfinden, was da eingestellt ist.

Das wird mir Kopfzerbrechen bereiten ...

Ich wollte mit der Tabelle ja gar nichts anstellen, sondern mit der *colum*-Tabelle.

Ich habe das oben ja schon rudimentär beschrieben. Stell dir den NSTableView vor, indem die Zeilen auftauchen. Jetzt ändert der Nutzer da irgendeinen Wert. Gut, das Dingens muss ein UPDATE - Kommando bekommen. Schön. Wie selektiere ich sicher eine Zeile? Richtig, einfach den PK entsprechend in der WHERE-Klausel setzen. Was ist der PK? Gar kein Problem: Darüber gibt die *column*-Tabelle Auskunft.

So läuft das bisher. Wenn ich allerdings die Tabelle gar nicht abfragen kann, kann ich auch nicht den PK ermitteln. Wenn ich das nicht kann, kann ich nicht sicher sein, dass nur die gewünschte Spalte geändert wird. Das nennen wir: TOM SITZT GANZ SCHÖN IN DER SCHEISSE! Und zwar bis zum Hals.

Als Work-Aroung fällt mir nur ein, jede Spalte in die WHERE - Klausel aufzunehmen -- wie praktisch ...

Ja, so habe ich das früher gemacht. Das will ich aber nicht mehr, weil es mir zu properitär ist. Egal. Ich mache das jetzt erst einmal über ein Assume, dass die Spalte <table_name>_id heißt. Es geht ja nur darum, was der liest, wenn man einfach ein Objekt in den nib legt. Programmatisch kann man das ja ohnehin



machen.

Später werden die Klassen ohnehin von NSController abgeleitet und sie bekommen ein Pane im IB. Dann muss man das dort halt händisch eingeben.

Was ich machen will? Was machst du denn für ein SQL-Statement, wenn du etwa die Telefonnummer einer Person in einer Adresstabelle ändern willst?

?

Danke für deine Mühe, aber das hilft mir nicht wirklich. Die SQL-Definition (ich glaube seit 99) sieht nunmal die information_schema als Instanz für die Abfrage an. Offenbar waren die, was die Zugriffsrechte angeht, der Meinung, dass der Client-Programmierer die notwendigen Informationen hat, also nicht aus der Datenbank lesen muss. Ich hätte das halt ganz gerne automatisch implementiert.

Ist nicht schön, aber auch kein wirklicher Beinbruch. Wenn jemand noch irgendwann einmal den Link auf den Artikel findet, mit dem man sich eigene Panes im IB machen kann, ist das Ganze ohnehin gegessen.

Danke!

Siehst du, so mache ich das auch. Und woher weißt du, dass du person_id nehmen musst? Das hat dir mutmaßlich jemand gesagt, oder du hast es dir selbst mal festgelegt.

Ich wollte es eben so machen, dass bei Öffnen der Tabelle das Framework automatisch erkennt, was der Primary Key ist. Dazu müsste ich aber eben nachfragen können ...

Die Strategie ist jetzt:
1 Gibt es überhaupt einen PK? Das kann ich feststellen.
2 -Falls ja, gibt es eine Spalte mit der Bezeichnung "<table_nam>_id"? Das kann ich feststellen.
3 --Falls wieder ja, nehme an, dass diese der PK ist.
4 Andernfalls nehme keinen PK an.

Solange kein PK erkannt ist, werden Änderungen nicht akzeptiert.

Selbstverständlich hat man im Code jederzeit die Möglichkeit, selbst einen PK zu setzen.