PreparedStatement Parameter mehrfach verwenden

[Landei]

Folgendes Problem: In einem PreparedStatement soll in der Where-Clause auf einen Wert getestet werden, aber nur wenn auch einer angegeben wurde. Ich hatte mir gedacht, dass ich ansonsten -1 übergebe und dann etwas schreibe wie
"SELECT * FROM bar WHERE foo=? OR ?=-1"
Nun sieht es so aus, als könnte ich die Parameter im String nicht "numerieren" (wie das z.B. bei Format-Strings geht), also müsste ich meinen Wert tatsächlich zweimal übergeben.

Hat jemand eine Idee?

 

[tfa]

Mach dir 2 verschiedene Prepared Statements - für jeden Anwendungsfall eins. Oder verwende einen ORM.

 

[SlaterB]

zweimal übergeben wäre aber auch kein Beinbruch,
notfalls baust du dir deinen eigenen Wrapper drumherum, der benannte Parameter versteht und automatisch doppelt einfügt

 

[Landei]

Mach dir 2 verschiedene Prepared Statements

Gute Idee, aber ich möchte das geschilderte Verhalten für drei Parameter haben, das macht dann 8 verschiedene PreparedStaements :-(

Oder verwende einen ORM

Das wäre mit Kanonen auf Spatzen...

 

[SlaterB]

warum willst du überhaupt ein PreparedStatement?
wenn sich dein Statement derart dynamisch ändert und manche Einschränkungen wegfallen, dann kann man da eh nix preparen,
dann kannst du auch jedes mal dynamisch ein neues Statement zusammenbauen. gerne wieder ein PreparedStatement

 

[tfa]

Mach dir 2 verschiedene Prepared Statements

Gute Idee, aber ich möchte das geschilderte Verhalten für drei Parameter haben, das macht dann 8 verschiedene PreparedStaements :-(

Dann schreibt man sich eine Methode, die die Query entsprechend vorhandener Parameter zusammenbastelt. Dann kannst du sogar beliebig viele Parameter unterstützen.

 

[Gast]

.. oder man nimmt iBatis.

 

[Landei]

Warum willst du überhaupt ein PreparedStatement?

Weil ich mich z.B. nicht damit rumschlagen will, wie irgendeine Datenbank Dates formatiert usw.

Dann schreibt man sich eine Methode, die die Query entsprechend vorhandener Parameter zusammenbastelt. Dann kannst du sogar beliebig viele Parameter unterstützen.

Darauf wird es hinauslaufen... Leider kann man die Parameter erst dann setzen, wenn der String fertig ist :-/

 

[tfa]

PreparedStatement sind schon Pflicht. Dynamische Querys sollte man nicht verwenden.

Leider kann man die Parameter erst dann setzen, wenn der String fertig ist

Das Problem versteh ich nicht. Die Parameter werden doch sowieso getrennt gesetzt.

 

[SlaterB]

> Dynamische Querys sollte man nicht verwenden.

+ vorher

> Dann schreibt man sich eine Methode, die die Query entsprechend vorhandener Parameter zusammenbastelt.

ja wie denn nun?

 

[tfa]

ja wie denn nun?

Statisch (Prepared):

update tabelle set name=? where status=? and irgendwas=?

Dynamisch:

update tabelle set name='elke mustermann' where status='xyz' and irgendwas='bla'

 

[SlaterB]

naja, diese Frage ist ja unabhängig vom sonstigen Zusammenbau

 

[tfa]

Trotzdem ein riesen Unterschied. Der Zusammenbau ist billig und kann performancemäßig vernachlässigt werden.

 

[Gast]

... oder man nimmt iBatis

 

[SlaterB]

ich meine ja nur, dass dein Satz 'Dynamische Querys sollte man nicht verwenden' verwirrend ist,

ob man nun nun
query = "update tabelle set name='elke mustermann' ";
if (x) {
query += "where status='xyz' ";
}

schreibt oder

query = "update tabelle set name=? ";
if (x) {
query += "where status=?";
}

ist die Entscheidung zwischen Statement und PreparedStatement,
aber beide Kommandos sind doch dynamisch aus mehreren Teilen zusammengebaut


'Dynamische Querys' ist doch kein Fachbegriff, der sich gegen PreparedStatement ausspricht

 

[tfa]

Es gibt jedenfalls den Fachbegriff des "dynamischen" und "statischen" SQL, und Prepared bzw. Unprepared Statements haben schon was damit zu tun. Auf welche Art das im Java-Programm zusammengesetzt wird ist völlig egal, das ist richtig.

 

[Landei]

OK, ich bastele jetzt den String "dynamisch" zusammen, und nehme nur für die Datumse ?-Parameter. Danke!

 

[tfa]

Und die anderen Parameter machst du hart in den String? Also gemischt statisch/dynamisch? Lieber nicht!

 

[Gast]

Hört sich ein bisschen nach Q&D an.