2012-11-13 8 views
6

Io sto usando un compilato SQLiteStatement con le transazioni per ottimizzare le operazioni di SQLite, ma sto leggendo la documentazione per la funzione execute:SQLiteStatement eseguire un SELECT/INSERT/DELETE/UPDATE

eseguire questa istruzione SQL, se non è un SELECT/INSERT/DELETE/UPDATE, ad esempio CREATE/Drop table, vista, grilletto, indice ecc

questo sembra implicare che questa funzione non deve essere usato con SELECT/INSERT/DELETE/UPDATE dichiarazioni, ma Io ho codice che lo utilizza con un inserto e funziona.

Sono a conoscenza di executeInsert e degli altri metodi, ma executeUpdateDelete non è disponibile nel mio livello API, quindi posso usare execute?

Anche se non ho bisogno dell'ultimo ID di inserimento o il numero di righe interessate dovrei usare execute invece di executeInsert e così via, in altre parole è più efficiente?

risposta

3

execute probabilmente non è più veloce di executeInsert, potrebbe anche essere più lento (su ICS execute invita executeUpdateDelete e scarta il valore di ritorno). Devi testarlo, ma dubito che qui troverai una vera differenza.

AFAIK, è sicuro utilizzare solo execute se non è necessario restituire valori ma non ci conterei su quello vero nelle future versioni di Android. La documentazione dice no, quindi forse qualcuno cambierà il comportamento per riflettere questo. Le implementazioni precedenti sembrano utilizzare anche execute (ad esempio 2.1 delete() sourcecode). Jelly Bean per esempio cambiato a lot dietro le quinte di SQLite, ma dovrebbe funzionare anche quando si utilizza execute

Inoltre, se non si utilizza lo stesso SQLiteStatement più e più volte, mentre solo rebinding args è probabilmente non vale la pena di usarlo . Costruirne uno nuovo ogni volta che si chiama il normale insert, update, ... i metodi sono veloci rispetto all'accesso effettivo al database e all'I/O del disco richiesto. Le transazioni d'altra parte aiutano molto, poiché la sincronizzazione dello stato del database sul disco per ciascuna istruzione è molto lenta.

+0

Quindi vuoi dire che non c'è alcuna garanzia che 'execute()' funzionerà anche in futuro, rilasciato con 'INSERT statement' anche i documenti non fanno altro che dirlo' Esegui questa istruzione SQL, se non è un SELECT/INSERT/.... 'allora non dovrebbe eseguire' INSERT' (perché questa è solo una dichiarazione che ho testato) e il suo funzionamento! E grazie per le preziose informazioni :) –

+0

Anche 'statement.executeUpdateDelete();' questo è disponibile nell'API 11 qualsiasi soluzione alternativa per 2.2? –

+1

@MuhammadBabar La documentazione prova a dirti che il metodo 'execute' non è inteso per le istruzioni che hanno un risultato. Come una serie impostata per una selezione, il conteggio delle modifiche per l'aggiornamento/eliminazione o l'ultimo ID riga per un inserimento. Finora non esiste un codice che impedisca il funzionamento di quelle istruzioni non intenzionali. Forse una futura modifica all'architettura del database non lo so.Gli ingegneri del framework Android potrebbero facilmente aggiungere una tale modifica senza preavviso perché la descrizione del metodo avverte che non funzionerà da anni. – zapl

1

Utilizzare SQLiteDatabase anziché SQLiteStatement per l'interazione con il database. SQLiteStatements non è thread sicuro quindi non li userei per SELECT/INSERT/DELETE/UPDATE. Inoltre, dovresti provare a non utilizzare query di database non elaborate per qualcosa di diverso da Selects. Ci sono funzioni di supporto integrate che aumentano le prestazioni del database. Sulla tua istanza di SQLiteDatabase hai .insert, .update, .delete e io uso .rawQuery per Seleziona.

+0

ma essere "THREAD-SAFE" implica solo l'applicazione * multi-thread *. Per il thread singolo vale la pena utilizzarlo se si desidera l'inserimento di massa. –

+0

um, ogni app con un DB dovrebbe essere multi-thread. Qualsiasi richiesta su disco, DB o servizio Web dovrebbe essere fuori dal thread dell'interfaccia utente. Se stai bloccando il thread dell'interfaccia utente per fare inserimenti collettivi, stai sbagliando. – JustinMorris

+0

Beh, stavo parlando di thread diversi da Main. –