Skąd będę wiedzieć, że rekord był duplikatem lub został pomyślnie wstawiony?

Question

Oto mój stół CQL:

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

mam ten datastax Java kod sterownika

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); 

Tutaj problemem jest to, że jeśli usunąć IF NOT EXIST wszystko działa w porządku, ale jeśli umieścić go z powrotem po prostu nie robić wstaw rekordy do tabeli ani nie zgłaszaj błędów.

Skąd będę wiedzieć, że wstawiam duplikat userName?

Używam Cassandrę 2.0.1

Answer 1

Korzystając INSERT... IF NOT EXISTS, a następnie można użyć ResultSet#wasApplied() sprawdzić wynik:

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

Uwagi:

• ta kwerenda CQL to lekki transakcja , który niesie ze sobą implikacje związane z wydajnością. Aby uzyskać więcej informacji, patrz this article.
• Twój przykład jest tylko jedna instrukcja, nie trzeba partii

Answer 2

wygląda trzeba transakcję kwas i Cassandrę, mówiąc wprost, nie jest kwas. Nie masz absolutnie żadnej gwarancji, że w interwale, które sprawdziłeś, jeśli nazwa użytkownika istnieje, nie zostanie utworzone od kogoś innego. Poza tym w standardzie CQL INSERT i UPDATE robi się to samo. Oboje piszą "nowy" rekord oznaczający stare usunięte. Jeśli istnieją stare zapisy, nie jest to ważne. Jeśli chcesz uwierzytelnić lub utworzyć nowego użytkownika w locie, przypuszczam, że możesz pracować na złożonej nazwie użytkownika + hasło, a do zapytania jako aktualizacji, gdzie nazwa użytkownika = dane i hasło = dane. W ten sposób, jeśli użytkownik poda niewłaściwe hasło, zapytanie nie powiedzie się. Jeśli użytkownik jest nowy, nie może podać "złego" hasła, dlatego jego konto zostanie utworzone. Możesz teraz przetestować pole takie jak "alreadysubscribed", które ustawisz dopiero po pierwszym zalogowaniu, więc w przypadku "właśnie stworzonego" użytkownika będzie brakujące