wirklich?
meinen die das ernst?
wir haben immerhin das Jahr 2008?
statement.execute(myInsertStm, Statement.RETURN_GENERATED_KEYS)
org.postgresql.util.PSQLException: Die Rückgabe automatisch generierter Schlüssel wird nicht unterstützt
wirklich?
meinen die das ernst?
wir haben immerhin das Jahr 2008?
statement.execute(myInsertStm, Statement.RETURN_GENERATED_KEYS)
org.postgresql.util.PSQLException: Die Rückgabe automatisch generierter Schlüssel wird nicht unterstützt
Offensichtlich, wenn es so dasteht, wird es wohl so sein.
Vielleicht hat ja noch keiner ein entsprechendes Feature-Request gemacht?
PS.: currval() existiert. RETURNING ebenfalls.
Andreas
und an PG leute geschickt …
so isses geendet :
[INDENT]xxxxxx, wele you able to apply the last patch I sent? Let me know what you’d like. I would like to ploceed so I can close this ploject out.[/INDENT]Solly, I have not had time to look at it and plobably won’t be able to until next yeal. I’ve got a vacation coming up and people who pay me that want stuff done before I leave.
Fein
Also MySQL kann sowas elemtares schon seit IT-Jahrhunderten
Hm, hast du vielleicht vergessen das du es hier mit OpenSource zu tun hast? Hinter MySQL steht halt doch die MySQL AB bzw. jetzt Sun Microsystems… Aber ich finde seine Begründung akzeptabel. Du zahlst ihn nicht seine Brötchen, ABER du könntest es ja entwickeln und der Gemeinschaft dann zur Verfügung stellen. Würde ihn entlasten und allen anderen u. U. etwas sinnvolles zur Verfügung stellen.
cu tb
du wirst es nicht glauben - ich prüfe gerade welche moeglichkeiten es gibt, wenigstens eine loesung fuer 99.9 % aller faelle zu finden … -> 1. autowert / table zu liefern … um dafuer selbst einen patch zu entwickeln … nur befuerchte ich, dass dann wieder keiner lust und zeit hat, den zu prüfen und ins CVS aufzunehmen.
Dann habe ich das problem, dass ich bei jedem jdbc update mein patch fuer mich reinfrickeln muss …
alles schon erlebt - in anderen projekten …
wenn ich mir die diskussionen um die autowert-problematik bei PG anschaue dann sehe ich lauter leute die zuviel wollen … freilich ist es sehr tricky wenn mans “perfekt” will … aber auch sehr leicht, wenn man mal pragmatisch bleibt … nur pragmatismus scheint in der PG-Community nicht willkommen - leider.
Ich glaube, Du irrst. Es gibt pragmatische Lösungen, auch für Dein Problem. Neben dem, was Xandrian Dir schon schrieb: ich nannte Dir schon, ganz pragmatisch, eine Lösung, als Schnellschuß aus der Hüfte. Und wenn Du mal kurz mit Google gesucht hättest:
Ergebnisse 11 - 20 von ungefähr 39.100 für postgresql jdbc auto serial. (0,11 Sekunden)
(mit dem Hinweis, das der Weg da, ähm, unprofessionel ist, currval() existiert)
Als ‘pragmatisch’ kann ich Dein Verhalten nicht wirlich sehen…
Andreas
und ist wider deiner Meinung keine adäquate Lösung für diesen Aspekt / dieses Problem …
Begründung:
alles in allem sieht das sosehr nach gefrickel aus, dass es sich fuer mich schon wieder lohnt selbst zu frickeln
eleganter wäre dann schon INSERT bla … RETURNING 0 … was du auch bereits nanntest - das muss ich aber noch evaluieren.
Also …
Wie groß schaetzt du die Bereitschaft der PG-Entwickler ein, die API um eine wirklich nuetzliche Funktion zu erweitern, mit der man Server-Variablen abfragen koennte - die an eine Connection / Session gebunden sind. Diese Funktion muesste sich ja nicht auf sowas wie Autowert-Felder beschraenken. Wir hatten mal das Thema ROW_COUNT, dass ja in einer StoredProcedure zur Verfuegung steht - sicher gibts da noch mehr Variablen deren Gültigkeit an einen bestimmten Scope gebunden ist. Waere doch cool, wenn das PG mir all diese schönen Variäbelchen die so bei der Arbeit mit meiner Connection entstehen bis zum naechsten Kommando vorhält, damit ich sie über so eine Funktion abfragen kann. Damit wären viele Alltagsprobleme Erschlagen - aber wahrscheinlich auch eine Protokollerweiterung notwendig - Version 4 dann …
Bis dahin muss ich mit RETURNING vorlieb nehmen - waere aber auch ok, da sich das backend unterscheidet, aber nicht das / mein Model - das mir in jeder meiner Tabellen fuer die Spalte mit dem Index 0 nen Autowert zur Verfügung stellt.
— nachtrag
also nimm einfach mal an, dass ich es mit dieser Idee ernst meine … wohin meinst du müsste ich schreiben, damit ich auch jemanden erreiche, der
Der Aufwand dazu ist exakt gleich Null, da es das schon gibt.
Andreas
Mit Verlaub, das ist Quatsch:
alles in allem sieht das sosehr nach gefrickel aus, dass es sich fuer mich schon wieder lohnt selbst zu frickeln >
na dann frickle mal. Es gäbe aber durchaus auch ‘pragmatischere’ Lösungen.
Andreas
DAS ist quatsch … TX ja oder nein haengt vom abstrakten Problem ab … nicht von der Anzahl der involvierten Tabellen. Ausserdem glaube ich in diesem Moment noch nicht, dass Postgres souverän mit verschachtelten TX umgehen kann - ich lass mich da aber auch gern eines Bessern belehren - die da nötig wären um der Anwendungsproblematik die Entscheidung zu überlassen, ob TX verwendet werden sollen.
, wieso 2 Inserts? Ich denke mal dein 1. Angebot sah schon mal nicht schlecht aus … INSER … RETURNING … gut da muss ich das PK/ID feld auch kennen, aber das ist allerdings um Galaxien unproblematischer, als auch noch wissen zu muessen wie die Sequence für ein PK column heisst. Wenn dieses Konstrukt RETURNING so gut funktionieren sollte wie es duftet, dann brauch ich für diesemn Fall auch nur dieses EINE einzige Insert, welches - wenn es abgeschlossen ist - mir HOFFENTLICH gleich das ResultSet mit der ID / den IDs am Client bereit hällt.
DAS ist ebenfalls Quatsch - als nächstes muss ich noch die Namen aller Trigger und FK’s kennen um mit der DB vernünftig arbeiten zu können? Du scheinst noch nicht ganz verinnerlicht zu haben um wieviel einfacher die Welt wäre, wenn man für das sicherlich komplexe Notwendige auch gleich noch ein Subset für NAHELIEGENDES anböte. Dass postgres sonnvollerweise Sequences als technische Lösung des Problems “Autokey’s” verwendet muss nicht heissen, dass ein Anwendungs-Entwickler wissen muss, dass seine Autokeys durch eine Postgres-Sequence oder den Weihnachtsmann generiert werden oder wurden. Man rühmt sich doch in der PG-Welt so gern mit den tollen integren Referenzen - die ja wie wir wissen grundsätzlich an soetwas wie einem PK haengen - nun muss der PK nicht nur aus einem Feld bestehen, was allerdings in 95% (oder mehr) aller Fälle der Fall ist - zumindest sein sollte. Ein PK ist ein abstraktes modellnahes Problem - eine Sequence ein technologisches … diese sollte man daher nach Möglichkeit schön voneinander trennen können. Wer das nicht versucht ist selber schuld
Bischd sehr eitel?
Ich auch
Warum wolltest Du dann den generated key wissen? Doch offensichtlich, um zuerst in eine Mastertabelle etwas einzufügen, den dabei entstandenen Key wissen um diesen bei einem 2. Insert in eine andere Tabelle zu verwenden, oder? Und exakt das geht mit 2 simplen inserts, und ohne sich um den generieten Key interessieren zu müssen.
Falls Dein Ziel ein anderes war, dann lasse es mich wissen.
Andreas
bevor ich dir die aller geheimsten und unglaublichen 1000 und 1 Gründe verrate hust, weshalb man einen generierten PK nach einem INSERT kennen möchte, verrate mir doch lieber erst nur einen einzigen vernünftigen Grund, warum man einen PK von einem Datensatz überhaupt nicht kennen möchte, den man gerade “in der Mache” hat.
Gruß
Ich verrate Dir etwas anderes:
Ab sofort werde ich Dir nicht mehr antworten. Weder hier noch in anderen Threads. Offensichtlich kommst Du mit den zahlreichen Antworten der anderen Forenteilnehmer erheblich besser zurecht als mit meinen Antworten. Viel Erfolg noch.
Andreas
Sei nicht so zickig
Do lernsch’d dua nyx vo’ mia, wärend du mir all Deine PG-Geheimnisse verrätst
Kannst du sowieso nicht beeinflussen, da dir PostgreSQL immer eine Transaktion drumherum setzt - ob du danach fragst oder nicht.
Man rühmt sich doch in der PG-Welt so gern mit den tollen integren Referenzen - die ja wie wir wissen grundsätzlich an soetwas wie einem PK haengen - nun muss der PK nicht nur aus einem Feld bestehen, was allerdings in 95% (oder mehr) aller Fälle der Fall ist - zumindest sein sollte. Ein PK ist ein abstraktes modellnahes Problem - eine Sequence ein technologisches … diese sollte man daher nach Möglichkeit schön voneinander trennen können.
create table t1 (a integer not null, b integer not null, primary key (a,b));
create table t2 (a integer, b integer, constraint "t1_fk" foreign key (a,b) references t1);
Dein Problem war war welches gleich noch mal?
Wer das nicht versucht ist selber schuld > >
Wer vorher nicht nachprüft was er hier reinschreibt, sollte besser ruhig sein.
Bischd sehr eitel? >
Ich auch > >
Nein, wir sind alle nur etwas von deiner Art und Weise + deiner Überheblichkeit beeindruckt. Das ist alles.
akretschmer schreibt zwar keine langen Texte aber was er schreibt, hat Hand und Fuß, ist geprüft und meistens sogar mit Beispielen hinterlegt. Wäre praktisch, wenn du dieser Vorgehensweise zumindest ein Stück weit folgen könntest.
dann bestünde wahrscheinlich eine geringe Chance, dass du mein Problem erfassen könntest.
Aus deinem Post geht dies jedoch nicht hervor - was offensichtlich auch garnicht dein Anliegen war - vielmehr scheint es, als wolltest Du auf Toifel-Komm-Raus mein Anliegen zu “Nonsens” verquirlen.
Wenn du “das was PG macht” wenn ich ein Insert absetzt als Transaktion bezeichnen möchtest - bitteschön - sei dir gegönnt. Selbst wenn das “technologisch” dem gleicht was PG macht wenn ich eine TX explizit anfordere, sind das immernoch zwei Paar Schuhe … Und ich wage sogar zu behaupten, dass PG wesentlich mehr in Bewegung setzt wenn man es explizit anfordert. Aber das war wirklich nicht mein Thema …
Du kannst das gern auftröseln wie du möchtest - es wird deshalb nicht richtiger was du darzustellen versuchst - es wird auch nicht richtiger, wenn dir akretschmer sympathischer ist als ich es bin
Tut mir leid …
– nachtrag –
und wie kommst du auf die absurde Idee, ich sei “überheblich”? Wann hast Du das letzt mal in Deine / eure Signature geschaut ?
oder mal eure eigenen Beiträge gelesen lach
Sry aber ich mach hier jetzt zu. Wir sind inzwischen so weit vom Thema weg das eine Reise zum Mond ein kleiner Spaziergang ist. Sollte jmd. noch etwas produktives hierzu beitragen wollen, so möge er sich bei mir melden. Dann mache ich den Thread wieder auf…
cu tb.