natürlich speichere ich das passwort in der selben zeile, für mein beispiel hatte ich aber nur id und username ausgewählt…ich will ja nicht ablenken

die tabelle heißt natürlich immernoch “password” was etwas irritierend wirkt (ursprünglich gab es im system nur passwörter und keine name, aber das wollte jemand anders…)

vielleicht guck ich mal, ob hibernate ja dieses deffered constraint checking kann? (denn die alternative wäre, dass es z.b. unter oracle über hibernate nicht nutzbar wäre)

USER
– ID (PK)
– USER_NAME
– PASSWORD
– …

Okay, auch dann dürftest du den Benutzernamen nicht unique (auf Datenbankebene) machen. Schwieriger Fall. Aber wenn du an MySQL gebunden bist und die das nicht unterstützen, würde ich es so machen und auf Programmebene sicherstellen, dass der Benutzername eindeutig ist.

das mit dem Hilfswert ist eine Variante, die ich nicht wirklich nutzen kann. Ich nutze Hibernate und da ändere ich bloß die reinen Java-Klassen und Hibernate macht den Rest. Außerdem kann man lange zirkuläre kreise bilden, wenn man lust hätte

und ob ein Truncate table; die lösung ist, geht doch auch um die userids! das macht nur noch mehr ärger.

ich hab folgende 2 varianten überlegt:
- dieses Tauschen erkennen und ablehnen = zwingt im zweifel den admin selbst zu einem temporären namen
- oder die spalte nicht auf unique zu setzen sondern das per hand sicherstellen, dass am ende des tages (der transaktion) kein name doppelt ist = schwaches design

bisher hab ich auch noch viel größere probleme mit anderen teilen der anwendung, so dass der admin hier bei derartigen versuchen nur einen stacktrace einer exception präsentiert bekommt, wenn er so einen mist versucht

Da du ja anscheinend “alle” Datensätze in einem Grid darstellst, könntest du auch die komplette Table beim Submit neu schreiben. Dann werden alle Änderungen “übernommen”.

3 a > 3 x
4 b > 4 a
3 x > 3 b

‘x’ muss dann irgendein Wert sein, der garantiert kein Benutzername sein kann.

Wie bereits gesagt, nicht sehr hübsch, aber zumindest eine Lösung.