Come saprò che il record è stato duplicato o è stato inserito con successo?

Question

Ecco la mia tabella CQL:

CREATE TABLE user_login (
    userName varchar PRIMARY KEY, 
    userId uuid, 
    fullName varchar, 
    password text, 
    blocked boolean 
); 

Ho questo datastax java codice del driver

PreparedStatement prepareStmt= instances.getCqlSession().prepare("INSERT INTO "+ AppConstants.KEYSPACE+".user_info(userId, userName, fullName, bizzCateg, userType, blocked) VALUES(?, ?, ?, ?, ?, ?);"); 

batch.add(prepareStmt.bind(userId, userData.getEmail(), userData.getName(), userData.getBizzCategory(), userData.getUserType(), false)); 


PreparedStatement pstmtUserLogin = instances.getCqlSession().prepare("INSERT INTO "+ AppConstants.KEYSPACE+".user_login(userName, userId, fullName, password, blocked) VALUES(?, ?, ?, ?, ?) IF NOT EXIST"); 

batch.add(pstmtUserLogin.bind(userData.getEmail(), userId, userData.getName(), passwordEncoder.encode(userData.getPwd()), false)); 
      instances.getCqlSession().executeAsync(batch); 

Qui il problema è che se tolgo IF NOT EXIST tutti funzionano bene, ma se rimetterlo semplicemente non lo fanno inserire i record nella tabella e non generare alcun errore.

Quindi, come faccio a sapere che sto inserendo il duplicato userName?

Sto usando Cassandra 2.0.1

Answer 1

Usa INSERT... IF NOT EXISTS, quindi è possibile utilizzare ResultSet#wasApplied() per controllare il risultato:

ResultSet rs = session.execute("insert into user (name) values ('foo') if not exists"); 
System.out.println(rs.wasApplied()); 

Note:

• questa query CQL è una transazione leggero , che comporta implicazioni sulle prestazioni. Vedere this article per ulteriori informazioni.
• tuo esempio ha una sola dichiarazione, non è necessario un lotto

Answer 2

Sembra che avete bisogno di una transazione ACID e Cassandra, in poche parole, non è acido. Non hai assolutamente alcuna garanzia che nell'intervallo controlli se il nome utente esiste, non verrà creato da qualcun altro. Inoltre, in CQL standard INSERT e UPDATE fanno la stessa cosa. Entrambi scrivono un "nuovo" disco che contrassegna i vecchi cancellati. Se ci sono vecchi record o no non è importante. Se vuoi autenticare o creare un nuovo utente al volo, suppongo che tu possa lavorare su un nome utente + password della chiave composita e alla tua query come aggiornamento dove username = datum AND password = datum. In questo modo, se l'utente ti dà una password sbagliata la tua ricerca non riesce. Se l'utente è nuovo, non può fornire una password "errata", quindi viene creato il suo account. Ora puoi testare un campo come "alreadysubscribed" che hai impostato solo dopo il primo accesso, quindi nel caso di un utente "appena creato" mancherà