Record lock
MySQL gaat niet automatisch kijken of hij op eigen houtje db velden kan gaan wijzigen, dat moet je aansturen en in jou geval is dat middels PHP.
Dus nogmaals mijn vraag: Hoe vertel jij MySQL dat ze daar xx datum weer op null komen?
Datum = 0 --> geen lock
Datum < huidige datum --> geen lock
Sessie niet meer actief --> geen lock
In PHP zou je daarnaast inderdaad sessies kunnen gebruiken: gaat de sessie verloren, dan worden alle in die sessie uitgecheckte records weer ingecheckt.
Punt is dan wel dat iemand die nog op kantoor is ingelogd ook de sessie moet kunnen verliezen wanneer hij thuis aan een document wil verder werken. Meteen koppelen aan gebruikersaccounts dus.
Nee, hoor grapje. Inderdaad nog even gebruikersacc. opnemen.
Thx.
Ozzie PHP op 13/06/2013 18:01:12:
Eddy, dat gaat toch niet werken? Dan kunnen 2 mensen nog steeds tegelijkertijd in hetzelfde record werken.
Werken wel, maar als de traagste (haha, loser :P) dan wil opslaan krijgt hij een melding dat het niet opgeslagen kan worden omdat het record inmiddels is gewijzigd.
En dan de vraag of hij de nieuwe gegevens wil openen of toch wil overschrijven (wat waarschijnlijk 100% kans is).
Maar dat kan in een seconde al naast elkaar lopen.
Persoon 1 gaat bewerken. Het slot wordt ingeschakeld. Persoon 2 wil het record bewerken, maar krijgt keurig een melding dat het record niet bewerkt kan worden omdat iemand anders er mee bezig is. Prima toch? Zo voorkom je dat 2 mensen gelijktijdig tijd en moeite in iets investeren, terwijl uitsluitend het resultaat van 1 van deze personen behouden zal blijven.
Ward van der Put op 14/06/2013 14:22:35:
In MySQL kun je events gebruiken die automatisch een query uitvoeren.
In PHP zou je daarnaast inderdaad sessies kunnen gebruiken: gaat de sessie verloren, dan worden alle in die sessie uitgecheckte records weer ingecheckt.
Punt is dan wel dat iemand die nog op kantoor is ingelogd ook de sessie moet kunnen verliezen wanneer hij thuis aan een document wil verder werken. Meteen koppelen aan gebruikersaccounts dus.
In PHP zou je daarnaast inderdaad sessies kunnen gebruiken: gaat de sessie verloren, dan worden alle in die sessie uitgecheckte records weer ingecheckt.
Punt is dan wel dat iemand die nog op kantoor is ingelogd ook de sessie moet kunnen verliezen wanneer hij thuis aan een document wil verder werken. Meteen koppelen aan gebruikersaccounts dus.
Dit laatste is niet juist !
Omdat op deze manier er toch twee personen een record kunnen wijzigen. Het zijn dan wel dezelfde personen. De zelfde persoon zal toch op kantoor eerst moeten uitloggen of een melding moeten krijgen (op kantoor) dat het record is gewijzigd en wordt er vervolgens uit gegooid.
P.S. Goed boek: 'WebDesign met PHP 5' --> momenteel geleend in de Bieb !
Gewijzigd op 16/06/2013 23:38:51 door Paco de Wulp
1. Op kantoor inloggen.
2. Document uitchecken om het te bewerken.
3. Thuis opnieuw inloggen = op kantoor uitloggen en document weer inchecken.
4. Eventueel document weer uitchecken wanneer de gebruiker het thuis opnieuw opent.
Paco de Wulp op 17/06/2013 10:05:30:
Is het beter / handiger / sneller om de locks in een aparte tabel te stoppen of kan ik deze in het desbetreffende record vastleggen ?
Hangt van verschillende beslissingen af. Kan één gebruiker bijvoorbeeld aan meerdere records tegelijk werken? Of wordt bij het openen van een record een ander door die gebruiker geopend record gesloten?
Welke soorten rechten wil je laten gelden voor de locks? Kan bijvoorbeeld een hoger geplaatste "manager" de lock van een lager geplaatste "medewerker" overrulen?
Dus een tabel waar je alles inzet (even als voorbeeld nieuwsberichten)
Tabel: nieuwsberichten
Velden: id, author, title, summay, message, date, locked
Echter is dit de werkwijze die ik zou hanteren, dit is voor iedereen anders. Ik maak namelijk ook vaak een log tabel, waar ik dit soort wijzigingen in vast leg. Op deze manier kun je snel achter problemen komen, en eventueel je klant/gebruikers erop aan spreken.
Gewijzigd op 17/06/2013 12:15:23 door Ozzie PHP
Daarom maak ik meestal een log tabel waar ik dus dit soort info in vast leg. Daar sla ik meestal in op.
id, user_id, record_id, changedate, action, error_log
Hier kun je dus eventueel een locked aan toe voegen als je dit gebruikt, zo kun je dus ook makkelijk uit de log de username halen die het momenteel aan het bewerken is.
Maar zoals ik al zei is dit een persoonlijke manier van werken, ik wil perse log's hebben zodat wanneer een klant komt klagen over de werking ik snel kan zien en eventueel aan kan tonen waar het probleem ligt.
Ozzie PHP op 17/06/2013 13:27:46:
Ah oke... da's inderdaad wel handig. Lastige klanten willen we natuurlijk niet :-)
Het is niet zo zeer voor 'lastige' klanten, maar om verschillende redenen.
1. Snel zien waar het fout gaat.
2. Kunnen aantonen waar het fout gaat.
3. Snel het probleem oplossen.
Tja en lastige klanten zul je toch wel krijgen :-P