Newsgroup: it.comp.java
Titolo: problema jdbc

come e' possibile recuperare valori di record appena inseriti (eg. con 
Statement.executeUpdate("INSERT ...") ) di campi di tipo SERIAL 
(postgres) o il cui default e' preso da una sequence (postgres/oracle, 
etc.) ?
il caso e' quello in cui quando aggiungo un record non specifico il 
valore per tutti i campi, ne tralascio uno il cui default e' un intero 
che si auto incrementa e che e' la chiave primaria della tabella.
quindi voglio ripescare il valore di questa chiave primaria, come e' 
possibile?
in caso di un unico client basta fare una qualche select, ma nel caso in 
cui piu' client possano inserire record come gestire le race conditions?
nelle api native di solito e' garantito un qualche meccanismo (postgres 
restituisce l'oid, mysql il valore dell'autoincrement, oracle mette a 
disposizione RETURNING) ma a livello di jdbc non ho trovato niente, 
possibile?
grazie
Simone

 etc.) ?
Facendo una SELECT specificando tutti i campi appena inseriti come
clausola WHERE.
Davide

 clausola WHERE.
non e' una garanzia sufficiente, per quanto remota c'e' la possibilita' 
che 2 client facciano la stessa insert producendo 2 record distinti solo 
dal campo serial (quanto questo abbia senso me lo sto chiedendo...)
bye
Simone

 dal campo serial (quanto questo abbia senso me lo sto chiedendo...)
E dove sta' il problema anche in quel caso ?
tu hai due record "padre" corrispondenti a "rossi mario", il fatto che
tu attacchi i record "figli" a "rossi mario" con ID 1 o "rossi mario"
con ID 2 (quando tutti i campi sono identici) non dovrebbe essere un 
gran problema no ?
Davide


il problema sta che entrambi i client potrebbero attaccare i figli allo 
stesso rossi mario (quindi rimarrebbe un record "fantasma" e 
impropriamente tutti i figli attaccati all'altro)
bye
Touch

 
Ciao,
e' possibile, dal momento che i campi autoincrementanti non fanno parte
dello standard SQL (almeno fino all'SQL/92). Di solito io preferisco non
usarli e creare i valori "a mano" (o al massimo sfruttando le sequence, se
il dbms lo permette). Fra l'altro in questo modo si aumenta la
portabilita' dell'applicazione.
Un modo semplice per gestire campi di questo tipo (che contenrranno
valori in sequenza, ma senza usare campi autoincrementanti o sequence),
e' di creare una tabella con il prossimo valore per tali campi da cui
tutti i client vanno a pescare nel momento in cui hanno bisogno di un
nuovo valore per un campo autoincrementante.
Ad esempio:
CREATE TABLE object_ids (
  id_number     BIGINT,
  entity_name   VARCHAR(32)
);
INSERT INTO object_ids VALUES(0, 'person');
INSERT INTO object_ids VALUES(0, 'address');
...
Quando un client ha bisogno di un nuovo id per la tabella person fara'
qualcosa del genere:
SELECT id_number FROM object_ids WHERE entity_name='person';
UPDATE object_ids SET id_number=id_number+1 WHERE entity_name='person';
...ovviamente il tutto dentro ad una transazione per evitare che client
concorrenti prendano lo stesso id e modifichino in maniera inconsistente
la tabella.
-- 
Lucio Benfante
Brainbench MVP for Java 1
http://www.brainbench.com
MyTranscript: 
http://www.brainbench.com/transcript.jsp?pid=167064

 etc.) ?
Recuperi il "prossimo valore" dalla sequence prima di fare la INSERT.
con postgres:
SELECT nextval('nome_sequence')
e poi fai la insert specificando anche l'ID.
nextval() è atomica e incrementa la sequence su cui è invocata. Quindi sei
non ci sono problemi per accessi concorrenti.
per Oracle non conosco il nome della chiamata, ma dovrebbe valere lo stesso
meccanismo.
y.

 ...ovviamente il tutto dentro ad una transazione per evitare che client
NO! una transazione NON e' sufficiente, e' necessario il lock della 
tabella, che e' una cosa diversa, e purtroppo anche qui si esce dallo 
std SQL...
con le transazioni hai la garanzia di non far vedere agli altri 
modifiche che stai apportando ma non hai l'atomicita' delle operazioni
per questo motivo pensavo di generare i valori si' a mano, ma da codice 
java avendo un metodo synchronized che mi garantisca che tutti i client 
ricevano valori effettivamente univoci
bye
Simone

 ricevano valori effettivamente univoci
...questo sicuramente e comunque.
