Java/JDBC Statment.RETURN_GENERATED_KEYS not supported ?

wirklich?

meinen die das ernst?
wir haben immerhin das Jahr 2008?


:astonished:

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 :smiley:

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.

  • und ich sehe gerade dass ich mich da mit leuten auf einer mailing-liste auseinander setzen muss die auch noch im web verfuegbar ist, wo man meine email-adresse sieht -
  • sowas koennen doch nur selbstdarsteller oder verrueckte wollen :slight_smile: - gehts auch ETWAS “anonymer” ? - so wie hier ? -

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)

  1. Treffer:
    Accessing Auto Increment Values from PostgreSQL with Java : Bart Busschots

(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:

  1. kostspielige Transaktionen nötig - die eine / meine Anwendung garnicht bzw. nur gering dosiert einsetzt
  2. zusaetzliche Query nötig - mehr Traffic
  3. nicht besonders nützlich für mein Backend-Unabhaengiges framework, da diese zusaetzliche Query auch noch wissen muss, wie die EINE sequence heist

alles in allem sieht das sosehr nach gefrickel aus, dass es sich fuer mich schon wieder lohnt selbst zu frickeln :smiley:

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

  1. kompetent ist zu entscheiden ob ja oder nein
  2. interesse hat

Der Aufwand dazu ist exakt gleich Null, da es das schon gibt.


Andreas

Mit Verlaub, das ist Quatsch:

  • wenn Du in mehr als einer Tabelle was machst, ist eine TX drum herum kein Mehraufwand, sondern ein zwingendes Muß
  • es ist keine extra Query nötig. Dein Wunsch sind 2 Inserts, und ich sage, es geht in 2 Inserts, ohne weitere Schritte.
  • den Namen der Sequence sollte man ja wissen, so wie man auch den Tabellennamen kennt. Aber man kann ihn auch erfragen. Das würde auch Inline innerhalb des Inserts gehen


alles in allem sieht das sosehr nach gefrickel aus, dass es sich fuer mich schon wieder lohnt selbst zu frickeln > :smiley:

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 :smiley:

Bischd sehr eitel? :smiley:

Ich auch :p

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ß :sunglasses:

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 :slight_smile:

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 > :smiley: >

Wer vorher nicht nachprüft was er hier reinschreibt, sollte besser ruhig sein.


Bischd sehr eitel? > :smiley:

Ich auch > :p >

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 :smiley:

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.