collision vermijden backend

Overzicht Reageren

Sponsored by: Vacatures door Monsterboard

Henk de Vriep

Henk de Vriep

12/01/2015 12:48:45
Quote Anchor link
Ik loop momenteel tegen het volgende probleem aan:

Voor de backend van een zelf geschreven webshop krijg ik van de feedback van de gebruikers dat er collision ontstaat.

User A is gedurende de dag bezig met het schrijven van teksten voor producten en het uploaden van foto's. De gebruiker slaat het product op en er lijkt niks aan de hand te zijn. Een user B heeft het product 's ochtends geopend en iets kleins aangepast. Aan het eind van de dag sluit user B hij een paar tabbladen en weet niet meer zeker of die het product heeft opgeslagen. User B slaat het product op en overschrijft alle data van user A.

Hoe kan ik hier het best voorkomen dat er collision ontstaat. Graag tips
 
PHP hulp

PHP hulp

29/03/2024 12:42:01
 
Ward van der Put
Moderator

Ward van der Put

12/01/2015 13:02:47
Quote Anchor link
Je zou de UPDATE kunnen beperken tot data die daadwerkelijk zijn gewijzigd.
Bij de GET voor het openen van het product registreer je in de sessie welke data de gebruiker heeft ontvangen.
Vervolgens voer je bij de POST alleen een UPDATE uit van data die in de POST anders zijn dan in de eerdere GET.
(Voor die vergelijkingen kun je een hash gebruiken, je hoeft niet alle data letterlijk te kopiëren.)

Daaraan kun je nog een datum plus tijd toevoegen. Als A hetzelfde gegeven wijzigt als B, kun je degene met de laatste POST dan waarschuwen en een keuze bieden: "Let op, terwijl u x bewerkte, heeft gebruiker y dit gewijzigd in z. Wilt u de wijziging opslaan of annuleren?"
 
Henk de Vriep

Henk de Vriep

12/01/2015 13:40:56
Quote Anchor link
Bedankt, dat is inderdaad een goed idee!

Hoe kan ik het het best aanpakken door bijvoorbeeld een artikel te vergrendelen en de opslaan knop alleen zichtbaar te maken voor diegene die het artikel gelockd heeft. Het komt niet bijster vaak voor namelijk en het zijn zo rond de 50 velden. Ik wil het graag zo simpel mogelijk houden.
 
Ward van der Put
Moderator

Ward van der Put

12/01/2015 13:50:17
Quote Anchor link
Je kunt inderdaad ook een systeem voor het "in- en uitchecken" van producten maken. Dan registreer je bijvoorbeeld een "locked_on" met een TIMESTAMP en "locked_by" met een user-ID.

Een product moet dan echter niet te lang locked zijn. Hooguit een halfuur, dus niet het eerder geschetste scenario: 's ochtends ergens aan beginnen en er bij het verlaten van het kantoor aan het einde van de middag achter komen dat er nog wat tabbladen met niet-opgeslagen data open staan. Daar zou je dan toch wat op moeten vinden.
 
- wes  -

- wes -

12/01/2015 13:54:22
Quote Anchor link
Andere optie is het toevoegen van een archive_id in je database. Bij het updaten van een item doe je alleen geen update, maar doe je een insert met als archive_id (en archive_date idealiter) het id van het item dat je hebt 'aangepast'. Op deze manier krijg je een soort version-control van het item.

Vanaf hier kan je gemakkelijk bepalen wie wanneer iets heeft aangepast en nog belangrijker , of dit gedaan is uit hetzelfde item (wat je probleem was). Hiermee kan je een keuze creëren tussen de nieuwe items, waarbij je er 1 published en 1 zo laat (voor archief-doeleinden).
 
Henk de Vriep

Henk de Vriep

12/01/2015 13:54:50
Quote Anchor link
Dat klopt, het is een afweging. Het komt niet bijster vaak voor alleen je eerste suggestie daar gaat uren aan programmeer werk in zitten. Ik ga het eens afwegen. Bedankt voor je input en snelle reactie. Mocht er nog iemand zijn die andere optie's heeft dan hoor ik dat uiteraard graag.
 
John D

John D

12/01/2015 13:57:23
Quote Anchor link
Daarnaast is het zo dat de locking veel problemen kan veroorzaken: Een gebruiker heeft een product geselecteerd voor update en gaat koffiedrinken, lunchen, prive internetten met duistere sites en klikt op een gegeven moment op het kruisje rechtsboven omdat de baas langsloopt of vergeet de locking en denkt ik doe het morgen wel, sluit de browser.
De ICT afdeling kan vervolgens lockjes opheffen....
Ik vind de waarschuwing: "Het product is vandaag om xx:xx gewijzigd nadat u de gegevens hebt opgehaald voor wijziging" de meest fraaie en onderhoudsvrije oplossing.
 
- wes  -

- wes -

12/01/2015 13:59:16
Quote Anchor link
Henk de Vriep op 12/01/2015 13:54:50:
Dat klopt, het is een afweging. Het komt niet bijster vaak voor alleen je eerste suggestie daar gaat uren aan programmeer werk in zitten. Ik ga het eens afwegen. Bedankt voor je input en snelle reactie. Mocht er nog iemand zijn die andere optie's heeft dan hoor ik dat uiteraard graag.



Je zit alleen niet met locking en behoudt netjes de wijzigingen van iedereen. Je kan wel alle kanten op met deze oplossing, maar is inderdaad niet echt 1-2-3 te implementeren. Maar wel erg handig :)
 
Ozzie PHP

Ozzie PHP

12/01/2015 14:03:11
Quote Anchor link
Hmmm ... even uit de losse pols hè ...

Je hebt dus een producttekst. Op het moment dat iemand de tekst opent om te editen, genereer je van de huidige tekst een hash.

Vervolgens krijg je dus een formulier te zien waar de producttekst in staat (om te kunnen editen). Als hidden field voeg je aan het formulier de hash toe. Voel je 'm al aankomen ... ?

Op het moment dat je het formulier gaat verzenden, vergelijk je de hash in het hidden field met de hash van de huidige tekst. Als de tekst in de tussentijd is gewijzigd, is de hash dus anders en kun je een melding tonen: de tekst is om 14.00 uur nog gewijzigd door Pietje Puk. Wilt u deze tekst overschrijven?
Gewijzigd op 12/01/2015 14:03:51 door Ozzie PHP
 



Overzicht Reageren

 
 

Om de gebruiksvriendelijkheid van onze website en diensten te optimaliseren maken wij gebruik van cookies. Deze cookies gebruiken wij voor functionaliteiten, analytische gegevens en marketing doeleinden. U vindt meer informatie in onze privacy statement.