nicht angemeldet
atrikel editieren lock
hallo,
artikel(*) sollen von mehreren Leuten (via web-frontend) ediertiert werden können. Nun möchte ich natürlich verhindern, dass mehrere Leute einen Artikel gleichzeitig editieren. Dazu muss ein lock-Status her.
user öffnet Artikel, per UPDATE wird irgendwo in der DB ein status locked auf true gesetzt.
user speichert Artikel, per UPDATE wird locked auf false gesetzt.
ist locked auf false, kann anderer User Artikel nicht öffen (bzw. editieren)
offensichtliches Problem: User speichert Artikel nicht, sondern schließt Browserfenster einfach so. Oder Browser stürzt ab. Was auch immer.
Lösung
per JavaScript jede Minute (bzw. Interval X min) einen Status senden, dass User noch aktiv ist. Wenn Artikel locked ist, aber 5 Minuten mehr kein Status gesendet wurde, sollte locked wieder auf true gesetzt werden.
Allerdings: Javascript fände ich gar nicht so schön dafür. Was gibt's noch für Lösungen für dieses spezielle Problem? Bitte auch * beachten. Danke!
grüße
Mehe
* es handelt sich um relativ komplexe Artikel. Die User müssen dazu recherchieren und stöbern. Ein Bearbeiten eines Artikels kann durchaus mehrere Stunden dauern. Auch Offzeiten von mehreren Stunden (also Zeiten, in denen der User nichts am Frontend macht) sind durch möglich.
-
Tach!
user öffnet Artikel, per UPDATE wird irgendwo in der DB ein status locked auf true gesetzt.
user speichert Artikel, per UPDATE wird locked auf false gesetzt.
ist locked auf false, kann anderer User Artikel nicht öffen (bzw. editieren)offensichtliches Problem: User speichert Artikel nicht, sondern schließt Browserfenster einfach so. Oder Browser stürzt ab. Was auch immer.
Statt true/false die User-ID speichern, dann kann man zum Beispiel den anderen anzeigen, wer den Artikel bearbeitet und auch nach einem Absturz eine Wiederaufnahme (Liste der selbst geöffneten Artikel) anbieten.
dedlfix.
-
hi,
ist locked auf false, kann anderer User Artikel nicht öffen (bzw. editieren)
Genau, bringt Problems. Aber es gänge auch ohne Lock: Bei jedem Update schlägt ein Trigger zu und schreibt eine Repository.
Locker arbeiten, statt Arbeit locken.
Horst Locke
-
Tach!
ist locked auf false, kann anderer User Artikel nicht öffen (bzw. editieren)
Genau, bringt Problems. Aber es gänge auch ohne Lock: Bei jedem Update schlägt ein Trigger zu und schreibt eine Repository.Wenn du jetzt noch erklärst, was du unter "schreibt eine Repository" verstehst, dann wird es vielleicht sogar verständlich.
Üblicherweise ist ein Repository schon von der direkten Übersetzung her ein Lager, Depot, Aufbewahrungsort. Man steckt etwas hinein oder holt es von dort. "ein Repository schreiben" ergibt keinen Sinn. Selbst wenn du nur "in" vergessen haben solltest, besteht immer noch Erklärungsbedarf, was du in das Repository schreiben willst - und was man dann damit in Bezug auf das Problem erreicht.
http://community.de.selfhtml.org/zitatesammlung/zitat1388
dedlfix.
-
Hallo,
ist locked auf false, kann anderer User Artikel nicht öffen (bzw. editieren)
Genau, bringt Problems. Aber es gänge auch ohne Lock: Bei jedem Update schlägt ein Trigger zu und schreibt eine Repository.Wenn du jetzt noch erklärst, was du unter "schreibt eine Repository" verstehst, dann wird es vielleicht sogar verständlich.
Wieso verstehst du das nicht? Man nehme einen Trigger, schreibe in das Repository eines handelsüblichen CVS und beim Speichern (eventuell über ein Template) wird ein merge ausgelöst. Rubbeldikatz: Artikel von mehreren Usern verteilt erstellt ist fertig und ergibt Sinn! ;-)
Viele Grüße
Siri-
Hallo,
Hi
ist locked auf false, kann anderer User Artikel nicht öffen (bzw. editieren)
Genau, bringt Problems. Aber es gänge auch ohne Lock: Bei jedem Update schlägt ein Trigger zu und schreibt eine Repository.Wenn du jetzt noch erklärst, was du unter "schreibt eine Repository" verstehst, dann wird es vielleicht sogar verständlich.
Wieso verstehst du das nicht? Man nehme einen Trigger, schreibe in das Repository eines handelsüblichen CVS und beim Speichern (eventuell über ein Template) wird ein merge ausgelöst. Rubbeldikatz: Artikel von mehreren Usern verteilt erstellt ist fertig und ergibt Sinn! ;-)
Die idee ist nicht übel, allerdings ist es ganz so trivial dann doch nicht. Es könnte ein konflikt geben. Auf jeden fall könnte am ende etwas rauskommen was die user so nicht wollten.
Mfg entropie
--
Whenever people agree with me I always feel I must be wrong.
-- Oscar Wilde-
Die idee ist nicht übel, allerdings ist es ganz so trivial dann doch nicht. Es könnte ein konflikt geben. Auf jeden fall könnte am ende etwas rauskommen was die user so nicht wollten.
Ich hätte wohl ein <ironie> setzen müssen, aber der dedlfix hat mich bestimmt verstanden.
-
-
-
-
-
Hallo,
Lösung
per JavaScript jede Minute (bzw. Interval X min) einen Status senden, dass User noch aktiv ist. Wenn Artikel locked ist, aber 5 Minuten mehr kein Status gesendet wurde, sollte locked wieder auf true gesetzt werden.Allerdings: Javascript fände ich gar nicht so schön dafür. Was gibt's noch für Lösungen für dieses spezielle Problem? Bitte auch * beachten. Danke!
Der Server kann ja keine Informationen anfordern nach dem Motto "User X möchte editieren, ich schau mal nach ob User Y überhaupt noch verbunden ist". Es muss also ein regelmäßig Meldung erfolgen, dass der User Y noch auf der Seite mit dem Artikel ist. Deshalb ist dein Ansatz schon richtig.
Eventuell kannst du eine Freigabe nach dem Ende einer Session machen, auf jeden Fall solltest Du einen "Redakteur" vorsehen, der die Macht hat, den Artikel wieder frei zu schalten. Ansonsten wäre nur noch eine Kommunikation unter den Beteiligten möglich.
Viele Grüße
Siri