nicht angemeldet
Satzänderung von mehreren Benutzern
Hallöle,
woltte mal eben hören, wie ihr das Problem behandelt, dass ja mehrere Benutzer einen Satz ändern können.
Nehmen wir mal eine Adresse. Benutzer A lässt sie anzeigen und ändert die Strasse. Benutzer B lässt sie anzeigen und ändert die Telefonnummer.
Nun schickt A das Formular ab, alle Felder werden per UPDATE in die Datenbank geschrieben.
Anschliessend schickt B das Formular ab und schwupps - ist die alte Strasse wieder drin.
Ich könnte zwar für alle Felder den alten Wert in hidden- inputs mitsenden, vergleichen und nur bei Änderung eines Feldes diesen Inhalt in die Datenbank schreiben. Da B die Strasse nicht geändert hat, wird sie auch nicht in die Datenbank übernommen.
Alternative (aus alten DOS- Zeiten):
Ein Satz muss ausdrücklich zum Ändern (nicht nur zum Anzeigen) aufgerufen werden, der Benutzer wird eingetragen. Alle anderen erhalten die Info, dass der Satz für "Harald" gesperrt ist (bis eine Rückmeldung eingeht). Sollte Harald während der Sperrung Feierabend machen, was dann ?
Wie macht ihr das?
LG Kalle
-
Wie macht ihr das?
einen hash des aktuellen datensatzes speichern und mitschicken, wenn sich der hash geändert hat, eine meldung ausspucken "in der zwischenzeit wurde der datensatz geändert, sieht jetzt so aus: xxxx" - abc um abzubrechen, def um trotzdem zu speichern, ghi um die daten erneut zu bearbeiten
mediawiki macht das zb so - da wird der datensatz nicht gesperrt
-
Wie macht ihr das?
einen hash des aktuellen datensatzes speichern und mitschicken, wenn sich der hash geändert hat, eine meldung ausspucken "in der zwischenzeit wurde der datensatz geändert, sieht jetzt so aus: xxxx" - abc um abzubrechen, def um trotzdem zu speichern, ghi um die daten erneut zu bearbeiten
mediawiki macht das zb so - da wird der datensatz nicht gesperrt
ich mach das auch so, hat sich bewährt.
--
Wenn der Kommentar nicht zum Code passt, kann auch der Code falsch sein.
-
-
Hello,
Alternative (aus alten DOS- Zeiten):
das ist die Variante "pessimistic locking" - da wird was schiefgehen...
Die andere Variante ist das optimistic locking, erstmal machen lassen, gucken ob es einen Konflikt gab. Verfahren wirst du wahrscheinlich ergoogeln können, Hash ist sicherlich eine Möglichkeit, bei Modellen mit verschiedenen Tabellen und Foreign Keys kann man z.B. eine Kombination aus ID und Datum der letzten Änderung wählen. Die wird immer mitgeschickt, eine Änderung ist nur dann zulässig, wenn das Pärchen nach wie vor den aktuellen Stand der Daten widerspiegelt.
MfG
Rouven--
-------------------
sh:| fo:} ch:? rl:( br:& n4:{ ie:| mo:} va:) js:| de:] zu:| fl:( ss:) ls:& (SelfCode)
Friendships are a lot like a backyard garden. We plan to tend to them, but we just always seem to put it off until next week. -- Christian Clemenson as Jerry Espenson in Boston Legal: "Patriot Acts"