Archive for the ‘ Development ’ Category

Statement vs PreparedStatement

Quando frequentavo l’università mi chiedevo quale fosse effettivamente la differenza tra uno Statement e un PreparedStatement Java. Fondamentalmente mi permettevano di raggiungere lo stesso risultato in maniera lievemente diversa.

In realtà i due costrutti sono molto più diversi di quanto non si creda. Ogni comando SQL ricevuto dal DBMS viene elaborato seguendo 3 fasi:

  1. Compilazione (parsing del comando SQL);
  2. Esecuzione;
  3. Fetching (restituzione del risultato al client).

Supponendo che vengano eseguite molte operazioni, la classe PreparedStatement permette di eseguire il passo di compilazione una sola volta, la prima, e poi di aggiornarne i valori in seguito:

PreparedStatement pstmt = conn.prepareStatement(
         "SELECT * FROM TABELLA WHERE CAMPO = ?");
Iterator ricerca = lista.iterator();
while(ricerca.hasNext()){

   pstmt.setString(1, (String)ricerca.next());
   ResultSet rs = pstmt.executeQuery();

   while(rs.next()){
      //Get results
   }
   //...
}

Questo si concretizza in un miglioramento delle performance, generalmente. Ciò non è sempre vero, ci sono altri fattori che entrano in gioco che possono rendere uno Statement più veloce di un PreparedStatement. A mio avviso anche se fosse, una leggera diminuzione di performance (che dipende moltissimo dal database utilizzato) per il PreparedStatement è sicuramente ben accetta data la sua grande flessibilità. Non solo, dalle FAQ Oracle ho appreso anche che ci sono dei benefici in termini di sicurezza nell’utilizzo di PreparedStatement: il binding dei dati, infatti, eviterebbe un considerevole numero di attacchi di tipo SQL Injection. La FAQ infatti riporta:

“Statements may be slightly faster if you are only going to execute the SQL once. PreparedStatements are much faster when the SQL will be executed more than once. If you are using the statement cache, which you should, getting a statement from the cache is the same as executing the same statement.

In general we strongly recommend that you use PreparedStatements. This is especially true if you are sending user provided data in the SQL. By binding the data to a PreparedStatement parameter you can prevent most SQL injection attacks. Any performance advantage of using Statements is negligible.”

Insomma, per i miei gusti, non c’è motivo di usare Statement e PreparedStatement è la classe vincente.

Java – Esecuzione comandi su CLI

Prima o poi può essere utile astrarre un po’ meno dalla macchina e tornare a interfacciarsi con il Sistema Operativo sottostante. Quello che può tornare utile è quindi un metodo per eseguire comandi di sistema dalla VirtualMachine Java. Il seguente è un metodo che ho scritto in fretta e furia, ma che su sistemi UNIX sembra funzionare molto molto bene:

public static String execCommand(String cmd) throws IOException{
   String result = null;
   BufferedReader stdout = null;
   BufferedReader stderr = null;
   Runtime runtime = null;
   Process proc = null;

   runtime = Runtime.getRuntime();
   proc = runtime.exec(cmd);
   stderr = new BufferedReader(new InputStreamReader(
                                          proc.getErrorStream()));
   String temp = stderr.readLine();

   /*check if errors occurred*/
   if(temp!=null){
      do{
         if(result==null)
            result = temp+"\n";
         else
            result += temp+"\n";

         temp = stderr.readLine();
      }while(temp!=null);

      stderr.close();
      throw new IOException(result);
   }

   /*if no exceptions occurred then proceed to return the output*/
   stdout = new BufferedReader(new InputStreamReader(
                                           proc.getInputStream()));
   temp = stdout.readLine();

   while(temp!=null){
      if(result==null)
         result = temp+"\n";
      else
         result += temp+"\n";
      temp = stdout.readLine();
  }

  stdout.close();
  return result;
}

L’idea è semplice: se il comando fallisce, restituisco l’esito del comando (lo standard error) come un’eccezione di I/O, altrimenti il metodo torna l’esito del comando (lo standard output).

A questo punto possiamo, per esempio, scrivere il seguente main, un po’ inutile, ma rende l’idea

public static void main(String args[]){
   try{
      String result = execCommand("ls -lrt");
      System.out.println(result);
   }catch(IOException e){
      System.err.println(e.getMessage());
   }
}

Ovviamente il codice non è ottimizzato essendo la prima stesura di getto, alcune cose potevano essere evitate (i due BufferedReader per esempio), ma spero che a qualcuno questo metodo torni utile.

Oracle 10g – Upsert

Recentemente mi è capitato di dover eseguire una insert or update, anche detta upsert, su Oracle 10g. Su MySQL ero solito usare la forma “INSERT … ON DUPLICATE KEY UPDATE …” che funziona piuttosto bene, ma che non era supportata dal database che stavo utilizzando.

La versione 10g di Oracle, però, supporta l’operazione “MERGE”, entrata a far parte dello standard SQL nel 2003, e si è rivelata molto comoda utilizzandola tramite JDBC.

Supponiamo di dover memorizzare in una tabella l’ultima pagina visitata da un utente in un dato giorno, possiamo utilizzare il seguente prepared statement java:

PreparedStatement pstmt = conn.prepareStatement(
"MERGE INTO last_page_table dst "+
   "USING ( "+
"SELECT \'"+username+"\' USER_ID, "+
   "TO_DATE(\'"+
      new java.sql.Date(System.currentTimeMillis())+
   "\'YYYY-MM-DD')  DATE_FIELD, "+
   "\'"+lastPage+"\' LAST_PAGE "+
"FROM DUAL) src "+
   "ON (dst.USER_ID = src.USER_ID AND "+
      "dst.DATE_FIELD = src.DATE_FIELD) "+
"WHEN MATCHED THEN "+
   "UPDATE SET dst.LAST_PAGE = src.LAST_PAGE "+
"WHEN NOT MATCHED THEN "+
   "INSERT (dst.USER_ID, "+
      "dst.DATE_FIELD, "+
      "dst.LAST_PAGE) "+
  "VALUES (src.USER_ID, "+
      "src.DATE_FIELD, "+
      "src.LAST_PAGE)");

In sostanza, l’operazione “MERGE” funziona tra tabelle, prende i valori di una e li inserisce o aggiorna nell’altra in base al matching della condizione nella clausola “ON”.
Tuttavia, la necessità non era di utilizzare valori preesistenti di una tabella ed inserirli o aggiornarli nell’altra, ma l’effettivo popolamento della tabella. Esigenza risolta appoggiandosi alla tabella “DUAL”.
Ovviamente, invece di inserire direttamente nella stringa i valori necessari, si poteva utilizzare anche il ‘?’ e chiamare poi le funzioni della classe PreparedStatement.

PreparedStatement pstmt = conn.prepareStatement(
"MERGE INTO last_page_table dst "+
   "USING ( "+
"SELECT ? USER_ID, ?  DATE_FIELD, ? LAST_PAGE "+
   "FROM DUAL) src "+
   "ON (dst.USER_ID = src.USER_ID AND "+
      "dst.DATE_FIELD = src.DATE_FIELD) "+
   "WHEN MATCHED THEN "+
      "UPDATE SET dst.LAST_PAGE = src.LAST_PAGE "+
   "WHEN NOT MATCHED THEN "+
      "INSERT (dst.USER_ID, "+
         "dst.DATE_FIELD, "+
         "dst.LAST_PAGE) "+
      "VALUES (src.USER_ID, "+
         "src.DATE_FIELD, "+
         "src.LAST_PAGE)");

Se non vi sono particolari necessità in termini di performance, sicurezza, flessibilità, in genere preferisco inserire tutto direttamente nella stringa in modo da poterla scrivere facilmente su un file di log prima di inviarla al driver:

String sqlMerge = "MERGE INTO ...";
PreparedStatement pstmt = conn.prepareStatement(sqlMerge);
logger.debug("Executing "+sqlMerge);
pstmt.executeUpdate();

Hello world!

Perché non iniziare col più classico dei messaggi anche qui? Mi ricordo il mio primo programma, come quello di quasi tutti penso, il classico “hello world!” in ogni parte del mondo si inizia così:

int main(void)
{
printf("Hello world!\n");
return 0;
}

a seconda del linguaggio con cui si inizia ovviamente… Per me fu il Pascal, ma il C fu il linguaggio che mi appassionò di più.