---

Hej

Jeg sidder og arbejder på en database applikation, som via JDBC og
ODBC arbejder på en MySQL database.

Ved indsættelse af data i databasen savner jeg funktionalitet til at
"escape" specialtegn, f.eks. "\" m.fl. i strenge. Findes der standard
funktionalitet i Java til dette?

Det jeg leder efter er noget i stil med php funktionen
"mysql_escape_string".

mvh
Karl Peder

---

"Karl Peder Olesen" <kpo@mail1dotstofanetdotdk> wrote in message
news:3ce93b25.709452618@news.stofanet.dk...
> Hej
>
> Jeg sidder og arbejder på en database applikation, som via JDBC og
> ODBC arbejder på en MySQL database.
>
> Ved indsættelse af data i databasen savner jeg funktionalitet til at
> "escape" specialtegn, f.eks. "\" m.fl. i strenge. Findes der standard
> funktionalitet i Java til dette?
>
> Det jeg leder efter er noget i stil med php funktionen
> "mysql_escape_string".

Nope gør der ikke.

Java udviklere skal tænke selv, og ikke bare overlade alt til sproget.

Men det er ret simpelt at lave en statisk metode der gør det, som du så bare
kalder.
På den måde har du også mere styr på helt specifikt hvad der sker.

--
With many Thanks
Soren ' Disky ' Reinke ICQ #1413069 remove 'ihsyd' when email replying
Please visit my Freshwater Aquaria Webpage
http://www.disky-design.dk/fish

---

"Soren 'Disky' Reinke" <disky@disky-design.ihsyd.dk> writes:

> "Karl Peder Olesen" <kpo@mail1dotstofanetdotdk> wrote in message
> news:3ce93b25.709452618@news.stofanet.dk...
>> Hej
>>
>> Jeg sidder og arbejder på en database applikation, som via JDBC og
>> ODBC arbejder på en MySQL database.
>>
>> Ved indsættelse af data i databasen savner jeg funktionalitet til at
>> "escape" specialtegn, f.eks. "\" m.fl. i strenge. Findes der standard
>> funktionalitet i Java til dette?
>>
>> Det jeg leder efter er noget i stil med php funktionen
>> "mysql_escape_string".
>
> Nope gør der ikke.

Og dog. Nok findes der ikke en funktion der tager en streng som argument
og returnerer en escapet streng, men bruger man PreparedStatement bliver
resultatet alligevel det samme, nemlig at man kan indsætte specialtegn i
databasen uden at bekymre sig.

> Java udviklere skal tænke selv, og ikke bare overlade alt til sproget.

Alle udviklere uanset sprog skal tænke selv.

> Men det er ret simpelt at lave en statisk metode der gør det, som du så
> bare kalder. På den måde har du også mere styr på helt specifikt hvad
> der sker.

Og du er næsten sikker på at du ikke kan flytte applikationen til en
anden database. De forskellige databaser escaper ikke helt på samme måde
, eksempel: ' escapes i MySQL med \' og i Oracle med ''.

Brug PreparedStatement og overlad escapingen til database-driveren.

--
Finn Nielsen - http://www.zznyyd.dk/

"Creatures seemed to turn up in the world randomly, and certainly not
according to any pictures in a book." - The science of Discworld

---

Finn Nielsen wrote:
> Brug PreparedStatement og overlad escapingen til database-driveren.

Det er bare synd, at PreparedStatement er noget dyrere end alternativet
i nogle situationer.

Man kunne jo også implementere en udskiftbar 'escaper' - f.eks. med
Strategy pattern.

-dennis

---

Dennis Thrysøe <dt@netnord.dk> writes:

> Det er bare synd, at PreparedStatement er noget dyrere end
> alternativet i nogle situationer.

Har du tal på det?

Jeg tænkte uvilkårligt det samme, men det er jo kun et problem hvis
man har _mange_ SQL-statements og at de er forskellige fra gang til
gang. Hvis de er ens, har det meget hurtigt tjent sig hjem.
--
Thorbjørn Ravn Andersen
http://homepage.mac.com/ravn

---

Thorbjoern Ravn Andersen wrote:
> Dennis Thrysøe <dt@netnord.dk> writes:
>
>
>>Det er bare synd, at PreparedStatement er noget dyrere end
>>alternativet i nogle situationer.
>
> Har du tal på det?

Nøh. Men der sker nogle ting i databasen, som ikke kan undgå at tage tid.

> Jeg tænkte uvilkårligt det samme, men det er jo kun et problem hvis
> man har _mange_ SQL-statements og at de er forskellige fra gang til
> gang. Hvis de er ens, har det meget hurtigt tjent sig hjem.

Helt enig. Det var derfor jeg brugte "i nogle situationer". Hvad angår
om der skal _mange_ statements til, så må det jo nok være en individuel
vurdering. Man sskal ihvertfald huske at spare lidt på dem, hvor man kan.

-dennis

---

Dennis Thrysøe <dt@netnord.dk> writes:

> >>alternativet i nogle situationer.
> > Har du tal på det?
>
> Nøh. Men der sker nogle ting i databasen, som ikke kan undgå at tage tid.

Selvfølgelig tager det tid. Spørgsmålet er hvor meget tid det tager i
forhold til at parse et statment fra bunden hver gang.

Jeg har ikke lige en MySQL klar. Er der nogen der kan frembringe
nogen måleresultater?

> Helt enig. Det var derfor jeg brugte "i nogle situationer". Hvad angår
> om der skal _mange_ statements til, så må det jo nok være en
> individuel vurdering. Man sskal ihvertfald huske at spare lidt på dem,
> hvor man kan.

Hvorfor spare? Man skal vel bruge dem man skal.

--
Thorbjørn Ravn Andersen
http://homepage.mac.com/ravn

---

Dennis Thrysøe wrote:
>
>
> Thorbjoern Ravn Andersen wrote:
>
>> Dennis Thrysøe <dt@netnord.dk> writes:
>>
>>
>>> Det er bare synd, at PreparedStatement er noget dyrere end
>>> alternativet i nogle situationer.
>>
>>
>> Har du tal på det?
>
>
> Nøh. Men der sker nogle ting i databasen, som ikke kan undgå at tage tid.

Det er netop det prepared statements sparer dig for "ting i databasen".
De skal blot oprettes een gang - det kan måske tage en smule tid, men
bestemt ikke så meget mere end at parse den samme query. Se nedenfor.

>> Jeg tænkte uvilkårligt det samme, men det er jo kun et problem hvis
>> man har _mange_ SQL-statements og at de er forskellige fra gang til
>> gang. Hvis de er ens, har det meget hurtigt tjent sig hjem.
>
>
> Helt enig. Det var derfor jeg brugte "i nogle situationer". Hvad angår
> om der skal _mange_ statements til, så må det jo nok være en individuel
> vurdering. Man sskal ihvertfald huske at spare lidt på dem, hvor man kan.

Hvorfor skal man spare?

Det må komme an på din DB. For fex. Oracle, betyder prepared statements
at din query ikke skal parses på hvert request, hvilket som regel er den
mest ressource intentisive del af en query. Den skal ligeledes heller
ikke serialiseres ved hvert request.

Hvis din løsning skal skalere skal du bruge prepared statements.

Hvis du har statements der modtager N argumenter, kan man klare det med
en strategi for prepared statements. Fex. lave prepared statements for
alle muligheder for <= 10 argumenter, og så ellers splitte argument
sekvensen op i klumper af <= 10.

Jeg vil meget gerne høre argumenter imod brugen af prepared statements.

Mvh Morten

---

Morten wrote:
> Hvorfor skal man spare?

Det skal man naturligvis også kun i de situationer, hvor det ville være
dyrere at bruge PreparedStatements. Hvor ofte det så er (og om
overhovedet nogensinde i praksis) skal jeg ikke kunne sige. (Dette
besvarer forøvrigt også Thorbjørns post).

> Jeg vil meget gerne høre argumenter imod brugen af prepared statements.

Jeg mener, at kunne huske noget om, at der kun kan være én
PreparedStatement åben pr. connection. Så derfor vil det være et problem
når mange tråde der skal deles om et mindre antal connections, og disse
tråde har brug for at eksekvere forskellige statements.

Man jeg kan jo også have husket forkert?

-dennis

---

Dennis Thrysøe <dt@netnord.dk> writes:

> > Hvorfor skal man spare?
>
> Det skal man naturligvis også kun i de situationer, hvor det ville
> være dyrere at bruge PreparedStatements. Hvor ofte det så er (og om
> overhovedet nogensinde i praksis) skal jeg ikke kunne sige. (Dette
> besvarer forøvrigt også Thorbjørns post).

Så er det tiden at måle

> > Jeg vil meget gerne høre argumenter imod brugen af prepared statements.
>
> Jeg mener, at kunne huske noget om, at der kun kan være én
> PreparedStatement åben pr. connection. Så derfor vil det være et
> problem når mange tråde der skal deles om et mindre antal connections,
> og disse tråde har brug for at eksekvere forskellige statements.
>
> Man jeg kan jo også have husket forkert?

Det må være noget driverspecifikt og lyder som en meget uheldig
begrænsning. Oracles drivere har ikke den slags problemer.
--
Thorbjørn Ravn Andersen
http://homepage.mac.com/ravn

---

Finn Nielsen <usenet02@zznyyd.dk> writes:

> Og du er næsten sikker på at du ikke kan flytte applikationen til en
> anden database. De forskellige databaser escaper ikke helt på samme måde
> , eksempel: ' escapes i MySQL med \' og i Oracle med ''.

Så vidt jeg ved er '' standard for angivelse af et '. Selv i MySQL

Bortset fra det er rådet ikke dårligt med at bruge PreparedStatement.
Kode har det med at blive meget pænere.

--
Thorbjørn Ravn Andersen
http://homepage.mac.com/ravn

---

Thorbjoern Ravn Andersen <thunderbear@bigfoot.com> writes:

> Finn Nielsen <usenet02@zznyyd.dk> writes:
>
>> Og du er næsten sikker på at du ikke kan flytte applikationen til en
>> anden database. De forskellige databaser escaper ikke helt på samme måde
>> , eksempel: ' escapes i MySQL med \' og i Oracle med ''.
>
> Så vidt jeg ved er '' standard for angivelse af et '. Selv i MySQL

Det er muligt, jeg har aldrig prøvet med '' i MySQL. Jeg har dog prøvet
med \' i både MySQL og Oracle, MySQL havde ingen problemer med det,
Oracle kunne ikke li' det.

> Bortset fra det er rådet ikke dårligt med at bruge PreparedStatement.
> Kode har det med at blive meget pænere.

Nemmerlig.

--
Finn Nielsen - http://www.zznyyd.dk/

"Creatures seemed to turn up in the world randomly, and certainly not
according to any pictures in a book." - The science of Discworld

---

Finn Nielsen <usenet02@zznyyd.dk> writes:

> > Så vidt jeg ved er '' standard for angivelse af et '. Selv i MySQL
>
> Det er muligt, jeg har aldrig prøvet med '' i MySQL. Jeg har dog prøvet
> med \' i både MySQL og Oracle, MySQL havde ingen problemer med det,
> Oracle kunne ikke li' det.

Det skyldes nok at '' er standard og \' ikke er.

>
> > Bortset fra det er rådet ikke dårligt med at bruge PreparedStatement.
> > Kode har det med at blive meget pænere.
>
> Nemmerlig.

Der er dog stadig problemet med at det er noget bøvl at have lange
SQL-sætninger i sin kode, idet der er totalt umuligt at flytte det
frem og tilbage mellem et databasvinude og java-koden.
--
Thorbjørn Ravn Andersen
http://homepage.mac.com/ravn

---

Dennis Thrysøe <dt@netnord.dk> writes:

> Finn Nielsen wrote:
>> Brug PreparedStatement og overlad escapingen til database-driveren.
>
> Det er bare synd, at PreparedStatement er noget dyrere end alternativet i
> nogle situationer.

Måske, men man er sikker på at det virker.

> Man kunne jo også implementere en udskiftbar 'escaper' - f.eks. med
> Strategy pattern.

Hellere lade databasedriveren gøre det, så er man sikker på at der ikke
er evt. særheder man skal tage hensyn til.

--
Finn Nielsen - http://www.zznyyd.dk/

"Creatures seemed to turn up in the world randomly, and certainly not
according to any pictures in a book." - The science of Discworld

---

Finn Nielsen wrote:
> Dennis Thrysøe <dt@netnord.dk> writes:
>
>>Finn Nielsen wrote:
>>Man kunne jo også implementere en udskiftbar 'escaper' - f.eks. med
>>Strategy pattern.
>
> Hellere lade databasedriveren gøre det, så er man sikker på at der ikke
> er evt. særheder man skal tage hensyn til.

Det vi har gjort i det system jeg arbejder på nyu er faktisk en
kombination. Vi bruger (eller vil bruge) PreparedStatements hvor vi kan,
og almindelige hvor det ikke er muligt.

På grund af de store syntax-forskelle mellem databaserne har vi været
nødsaget til at implementere en mekanisme, som pakker disse forskelle
ind. Det er lavet lidt som med et Strategy pattern.


-dennis

---

Thorbjoern Ravn Andersen <thunderbear@bigfoot.com> writes:

> Finn Nielsen <usenet02@zznyyd.dk> writes:
>
>> > Så vidt jeg ved er '' standard for angivelse af et '. Selv i MySQL
>>
>> Det er muligt, jeg har aldrig prøvet med '' i MySQL. Jeg har dog prøvet
>> med \' i både MySQL og Oracle, MySQL havde ingen problemer med det,
>> Oracle kunne ikke li' det.
>
> Det skyldes nok at '' er standard og \' ikke er.

Det er sikkert rigtigt, men Karl spurgte til noget tilsvarende
mysql_escape_string() i PHP. Både mysql_escape_string() og addslashes()
(som også tit bruges til at escape data til sql-queries) bruger \'. Så
hvis man bare efterligner disse funktioner kan man få problemer med andre
databaser.

> Der er dog stadig problemet med at det er noget bøvl at have lange
> SQL-sætninger i sin kode, idet der er totalt umuligt at flytte det
> frem og tilbage mellem et databasvinude og java-koden.

Ja, det er kedeligt, men man kan ikke få det hele..

--
Finn Nielsen - http://www.zznyyd.dk/

"Creatures seemed to turn up in the world randomly, and certainly not
according to any pictures in a book." - The science of Discworld

---

Hej

Jeg takker for rådene. Spændende debat iøvrigt.

Min umiddelbare løsning blev at skrive en lille metode, der escaper
specialtegn i en streng. Sandsynligheden for at jeg skal flytte til
noget andet end MySQL i den aktuelle situation er ret lav, men det er
selvfølgelig ikke principielt korrekt at lave kode, som afhænger af
den konkrete database - så jeg tror jeg vil tage et kig på
"PreparedStatement" (når tiden tillader at jeg "nørder videre").

mvh
Karl Peder