Trigger instellen verstreken tijd in MySql
Pagina: « vorige 1 2 3 volgende »
Af en toe heb ik toch zo mijn bedenkingen over dit forum en het beleid erachter. Het heet toch echt PHP HULP en dan kan je ook de simpele vragen krijgen. Dan hoop ik ook op een normaal antwoord, hoe simpel het dan ook is.
En ik denk dat velen met mij mee zullen gaan.
Als ik een site zou overnemen die hier gebruik had van gemaakt, en ik wou iets hier aan veranderen, dan had ik me echt denk ik een ongeluk gezocht, tot ik hier een topic erover zou gaan schrijven. :-P
Persoonlijk vind ik dat databases moeten doen wat ze moeten doen. Data opslaan en verwerken, en de integriteit bewaken.
Maar dat is ook weer iets waar de ontwikkelaar zorg voor moet dragen. De Taakplanner in Windows, of de cronjobs in Linux zijn in mijn ogen bedoeld voor geplande taken.
Toevoeging op 02/09/2022 19:17:42:
Nanno Koerts op 02/09/2022 19:11:47:
Ik blijf het toch bijzonder vinden dat er hier heel veel tijd wordt uitgetrokken om met elkaar in discussie te gaan maar als ik iets heel simpels vraag het verwijt krijg dat ik niet even iets zelf opzoek op Google.... pffff
Nanno, het is daarom ook een discussieforum. Geen afhaalbalie voor kant-en-klare opdrachten.
Quote:
Af en toe heb ik toch zo mijn bedenkingen over dit forum en het beleid erachter. Het heet toch echt PHP HULP en dan kan je ook de simpele vragen krijgen. Dan hoop ik ook op een normaal antwoord, hoe simpel het dan ook is.
Dit is algemeen op forums, en heeft niks met het beleid te maken. Sterker zelfs, we sturen alleen maar aan, en we sluiten niet zomaar topics. We zijn er gewoon erg soepel in. Maar we verwachten wel enige zelfredzaamheid wat laat zien dat je zelf ook motivatie hebt. Jij wil iets oplossen, en wij sturen je in de juiste richting.
Gewijzigd op 02/09/2022 19:18:42 door - Ariën -
Zal het nog even een keer uitleggen.
Het betreft een website waar je kaartjes kan bestellen voor een voorstelling.
Deze website draait al ruim 10 jaar alleen heb ik hem onlangs geheel vernieuwd en dit puntje lag eigenlijk al lange tijd op de plank om te doen. En daar was nu de tijd voor.
Elke nacht om 03:00 u gooit een cronjob alle bestelling in het mandje eruit. Ik had er nooit bij stil gestaan dat ik dit ook per uur in kan stellen bij mijn hosting. Ik was het gaan zoeken in MyAdmin en iets met trigger.
Inmiddels heb ik een nieuwe cronjob aangemaakt die inderdaad kijkt naar de tijden die ouder zijn dan het tijdstip NOW. En dit werkt prima zo te zien.
Waarom dat mensen een kaartje in het mandje doen en daarna weg gaan begrijp ik al jarenlang niet. Kennelijk willen ze daarna overleggen met anderen of... Zeg jij het maar, ik krijg er geen zicht op.
De cronjob die ik nu heb ingesteld werkt prima en precies zoals ik het graag wilde, ik zag alleen de mogelijkheid niet en dan is juist een forum zo fijn dat mensen met je meedenken.
Toevoeging op 02/09/2022 19:29:12:
Quote:
Dit is algemeen op forums, en heeft niks met het beleid te maken. Sterker zelfs, we sturen alleen maar aan, en we sluiten niet zomaar topics. We zijn er gewoon erg soepel in. Maar we verwachten wel enige zelfredzaamheid wat laat zien dat je zelf ook motivatie hebt. Jij wil iets oplossen, en wij sturen je in de juiste richting.
Ik ben geen programmeur en toch heb ik een hele website draaien onder php. Dit komt omdat ik heeeeeeeeel veel gezocht heb en gevonden. En soms weet je even niet waar en hoe je iets moet zoeken. En voor de ene is dit zo logisch en voor de ander niet. En daar wringt het bij mij in de reacties af en toe.
Gewoon het feit dat ik vast zat in de gedachten om die trigger te gebruiken en dus totaal niet zou nadenken over een cronjob, dan is het fijn als er dan inderdaad iemand oppert hiervoor een cronjob in te stellen. Dat is dan iemand verder helpen. Ook als ik vraag wat het verschil is van iets.
Maar goed, ik zal nog wel weer eens langs komen met een 'simpele' vraag en dan hoop ik een goed antwoord te krijgen.
Bedankt in ieder geval voor de reacties.
Gewijzigd op 02/09/2022 19:57:50 door - Ariën -
- De sessie van de gebruikers verdwijnt, en het mandje blijft gevuld
- Het IP-adres verandert opeens, maar in dat geval hoop ik dat je niet op IP's controleert.
- Gebruiker bedenkt zich om bepaalde redenen.
Aan de andere kant hoeft het echt geen probleem te zijn. Een dergelijke record neemt maar een paar bytes is.
Je zou het ook prima elke maand kunnen opschonen.
Gewijzigd op 02/09/2022 19:58:30 door - Ariën -
- Ariën - op 02/09/2022 19:57:28:
Dat data in het mandje blijft kan diverse oorzaken hebben:
- De sessie van de gebruikers verdwijnt, en het mandje blijft gevuld
- Het IP-adres verandert opeens, maar in dat geval hoop ik dat je niet op IP's controleert.
Aan de andere kant hoeft het echt geen probleem te zijn. Een dergelijke record neemt maar een paar bytes is.
Je zou het ook prima elke maand kunnen opschonen.
- De sessie van de gebruikers verdwijnt, en het mandje blijft gevuld
- Het IP-adres verandert opeens, maar in dat geval hoop ik dat je niet op IP's controleert.
Aan de andere kant hoeft het echt geen probleem te zijn. Een dergelijke record neemt maar een paar bytes is.
Je zou het ook prima elke maand kunnen opschonen.
Ik check op de sessie id en op het ip adres. Nooit geweten dat het ip ineens kan veranderen. Ik weet ook niet hoe lang de sessie id gehandhaafd blijft, wat ik wel weet dat deze wordt opgeheven bij het sluiten van de browser. Ik heb eerlijk gezegd ook niet veel kaas gegeten over het sessie gebeuren. 99% van de bestellingen gaat echt vlekkeloos en na afronden bestelling heft het script ook alles in het mandje op.
Ik wil het juist graag elk uur omdat we maar max 57 kaartjes kunnen verkopen. En dan wil je mensen de gelegenheid geven een kaartje te reserveren als er kaarten beschikbaar zijn. En dat niet pas na 24 uur.
Elke bezoeker heeft nu dus een uur de tijd om de bestelling af te handelen, doen ze dit niet, dan worden de kaarten weer vrijgegeven.
https://theaterpand.nl
Volgens mij ben ik daar wel eens geweest voor een cabaretvoorstelling van Cindy Pieterse. :-)
Verder zou ik gewoon elke minuut een cronjob uitvoeren. Maar ik zie ook dat andere sites gewoon een maximale tijd van 20 minuten toestaan, en dat je daarna eruit wordt geknikkerd. Dat zal wel met polling werken. In het andere topic van vanavond wordt dit ook uitvoerig besproken. Ik denk dat dit ook goed van pas komt met wat jij zoekt.
Elke paar seconden pollen of er al betaald is. Dit lijkt me ook robuuster voor bij een massale kaartverkoop.
Gewijzigd op 02/09/2022 20:20:49 door - Ariën -
Onlangs geheel opnieuw geschreven en draait onder php 7.4. Ik krijg het niet voor elkaar om het naar 8 te schrijven.
De oude website heeft 10 jaar onder versie 4 gedraaid.
Ik heb ook nog een conflict in het rekenen met wijzigen van de aantallen, hier kom ik ook niet uit. Ik zie de logica gewoon niet. Ik was in overweging om dat hier eens op het forum te gooien.
Ik zou zeggen, maak een testlocatie aan op dezelfde PHP-versie en serversetup en zet display_errors aan en error_reporting op maximaal.
Nanno Koerts op 02/09/2022 19:11:47:
Ik blijf het toch bijzonder vinden dat er hier heel veel tijd wordt uitgetrokken om met elkaar in discussie te gaan maar als ik iets heel simpels vraag het verwijt krijg dat ik niet even iets zelf opzoek op Google.... pffff
Af en toe heb ik toch zo mijn bedenkingen over dit forum en het beleid erachter. Het heet toch echt PHP HULP en dan kan je ook de simpele vragen krijgen. Dan hoop ik ook op een normaal antwoord, hoe simpel het dan ook is.
Af en toe heb ik toch zo mijn bedenkingen over dit forum en het beleid erachter. Het heet toch echt PHP HULP en dan kan je ook de simpele vragen krijgen. Dan hoop ik ook op een normaal antwoord, hoe simpel het dan ook is.
Ik merk dat er wat ontevredenheid bij je zit. Misschien is het dan even zinvol om uit te leggen dat dit gewoon een forum is waarop iedereen zich kan aanmelden. Alles gebeurt vrijwillig. Ik krijg dus niet betaald om jou te helpen. Ik doe dat in m'n eigen vrije tijd. Dat is niet erg, maar je kunt dus geen 'eisen' gaan stellen dat jouw vragen beantwoord 'moeten' worden. Het staat je natuurlijk altijd vrij om iets te vragen, maar in dit geval (het verschil tussen NOW en CURDATE) had je het antwoord heel makkelijk zelf even op Google kunnen zoeken. Dat scheelt jou tijd om de vraag hier te moeten stellen, en het scheelt mij tijd om de vraag te beantwoorden (ja, ik moet dat ook op Google opzoeken).
Het is dus niet vervelend bedoeld en het is niet zo dat we je niet willen helpen, maar we verwachten wel dat je eerst zelf even je best doet alvorens een vraag te stellen. Als je er vervolgens niet uitkomt dan staat het je uiteraard vrij om hier om advies te vragen.
Hopelijk heb je er nu een wat duidelijker beeld bij en begrijp je de opmerking die ik eerder maakte wat beter.
Nanno Koerts op 02/09/2022 20:06:19:
Nooit geweten dat het ip ineens kan veranderen. [...] Ik heb eerlijk gezegd ook niet veel kaas gegeten over het sessie gebeuren.
Dan toch het schot voor open doel: hoog tijd om je in te lezen.
Voor sessie zie het Session Management Cheat Sheet, lees je ook in op het onderdeel netwerken met een tutorial.
Ik had eerder gesteld dat een cronjob bij voorkeur vermeden zou moeten worden in verband met schaalbaarheid. Maar hoe je het ook doet, je moet altijd uitkijken met het automatisch aanpassen van de database.
Je kent misschien wel die automatische regel ON UPDATE CURRENT_TIMESTAMP.
Als je geen overzicht (meer) hebt op een bepaalde database, kan een DBA bij gegevensonderhoud onbedoeld automatische triggers laten afgaan. De enige manier om dat voor te zijn is met goede communicatie. Het moet voor iedereen duidelijk zijn en blijven wanneer triggers af gaan en wat ze horen te doen.
Gewijzigd op 03/09/2022 15:53:38 door Ad Fundum
Laten we het eens omkeren: 100 personen hebben een ticket gekocht en dit fysiek op papier ontvangen.
Vanavond is een voorstelling om 20.00 en er komen 80 mensen opdagen.
Dat betekent dat er nog 20 tickets bij de mensen thuis zijn.
Wat nu? Ga je deze mensen opdracht geven om hun tickets te vernietigen? Ga je ze ophalen?
Nee toch? Op het ticket staat namelijk dat het geldig is voor voorstelling van X op datum 5 sept om 20.00. (en mogelijk laat je ze na 20.00 nog een half uur binnen komen)
Nu de analogie met je mandje:
In je mandje staat ook een geldigheidstijdstip. (of indirect: dat is de het tijdstip van in het mandje gooien + 1 uur).
Dan WEET je toch welke bestellingen er niet meer toe doen? en welke wel.
Het is dan alleen zaak om bij verschillende query's die jij kennelijk in je applicatie gebruikt niet "SELECT data FROM mandjes " te doen,
maar dat aan te passen naar
"SELECT data FROM mandjes WHERE besteltijd niet verlopen"
a) je zit niet te pielen met cronjobs of andere tijdsturingen
b) je historische data blijft staan. (bijvoorbeeld voor statistiek of voor "he klantenservice mijn bestelling komt niet binnen"
bedankt voor je zeer uitgebreide reactie.
Ik wil je hierbij graag even uitleggen hoe het bestellen in een theater werkt. Dit staat geheel los van andere evenementen omdat we hier met een vaste aantal zitplaatsen zitten. In ons geval is het enkel reserveren van een stoel en niet daadwerkelijk een zitplaats kopen.
Het is net als winkelen in de supermarkt, je pakt je producten, kiest het aantal en legt dat in je winkelwagen of mandje.
Uiteindelijk bepaal je bij de kassa welke producten je werkelijk mee de winkel uit neemt.
Helaas moest ik constateren in ons systeem dat mensen een aantal tickets in het mandje plaatsen, maar op 1 of andere duistere reden er verder niks mee doen. Oftewel, er staat ergens in de winkel een mandje met brood omdat de klant zich bedacht heeft en de winkel uit is gelopen. Even terug leggen is er dus niet bij.
Nu dus het punt dat ik mijn winkel opgeruimd wil houden en dat soort verdwaalde producten weer in het schap wil leggen. Ik had hierbij niet nagedacht dat ik hier een cronjob voor kan gebruiken. Ik zag enkel de trigger als mogelijke oplossing.
Nu draait er een cronjob die elk uur even kijkt of er geen verdwaalde (niet afgehandelde bestellingen) producten in de winkel staan. En dit werkt inderdaad helemaal zoals ik het wil.
Het mandje staat namelijk geheel los van de afgehandelde bestellingen die langs de kassa zijn geweest. Die worden vastgelegd in een andere database item Bestellingen.
Ik hoop dat je nu mijn post en wens beter begrijpt.
Dit item kan dus als opgelost worden betiteld.
Toevoeging op 05/09/2022 17:44:45:
Ivo P op 05/09/2022 09:28:48:
Wat nu? Ga je deze mensen opdracht geven om hun tickets te vernietigen? Ga je ze ophalen?
Nee toch? Op het ticket staat namelijk dat het geldig is voor voorstelling van X op datum 5 sept om 20.00. (en mogelijk laat je ze na 20.00 nog een half uur binnen komen)
Wat nu? Ga je deze mensen opdracht geven om hun tickets te vernietigen? Ga je ze ophalen?
Nee toch? Op het ticket staat namelijk dat het geldig is voor voorstelling van X op datum 5 sept om 20.00. (en mogelijk laat je ze na 20.00 nog een half uur binnen komen)
De bezoekers krijgen 5 dagen voor de desbetreffende voorstelling een herinnering per e-mail. Dit is ook een cronjob die elke week draait en alle klanten uit de database filtert. Ik krijg hier dus met regelmaat een wijziging of annulering op terug.
Dit werkt perfect want we hebben nagenoeg geen lege stoelen bij een uitverkochte voorstelling.
En nee, in een theater kom je de zaal niet meer binnen na aanvang.
Toevoeging op 05/09/2022 17:49:38:
Ivo P op 05/09/2022 09:28:48:
Dan WEET je toch welke bestellingen er niet meer toe doen? en welke wel.
Het is dan alleen zaak om bij verschillende query's die jij kennelijk in je applicatie gebruikt niet "SELECT data FROM mandjes " te doen,
maar dat aan te passen naar
"SELECT data FROM mandjes WHERE besteltijd niet verlopen"
a) je zit niet te pielen met cronjobs of andere tijdsturingen
b) je historische data blijft staan. (bijvoorbeeld voor statistiek of voor "he klantenservice mijn bestelling komt niet binnen"
Dan WEET je toch welke bestellingen er niet meer toe doen? en welke wel.
Het is dan alleen zaak om bij verschillende query's die jij kennelijk in je applicatie gebruikt niet "SELECT data FROM mandjes " te doen,
maar dat aan te passen naar
"SELECT data FROM mandjes WHERE besteltijd niet verlopen"
a) je zit niet te pielen met cronjobs of andere tijdsturingen
b) je historische data blijft staan. (bijvoorbeeld voor statistiek of voor "he klantenservice mijn bestelling komt niet binnen"
Dat is nou juist het issue, waar en hoe laat ik het script even controleren op verdwaalde niet afgehandelde bestelling na het uur van in het mandje plaatsen?
Ik begrijp niet wat je hier nou mee wil zeggen, want wie en wat activeert dan mijn script?
Dus punt A is juist mijn oplossing maar jij ziet iets anders wat ik niet zie.
als je 200 stoelen te verkopen hebt, dan kan er dus 200x een ticket in een bestelling geplaatst worden en betaald worden.
gedurende een uur na "in het mandje leggen" geef je de tickets een soort van tijdelijke status "verkocht".
Dat zijn dus de tickets die minder dan een uur in je mandje liggen.
Dus rekenvoorbeeld:
vanmorgen ging iets in de verkoop met 200 stoelen voor as. vrijdag.
om 17.00 gooit iemand 10 tickets in de reservering en doet er niets mee (betaalt niet)
om 18.00 gooit iemand 5 ticket in zijn mandje en betaalt ook nog niet.
Het is nu 18.05
Er zijn nu dus 195 tickets beschikbaar: 200 oorspronkelijk en er liggen er 5 minder dan een uur in het mandje.
Daar is geen cronjob voor nodig toch?
Je zou er zelfs voor kunnen kiezen dat als persoon 1 vanavond om 20.00 nog besluit om toch te betalen en er zijn nog steeds 10 stoelen beschikbaar, dan kan hij ze alsnog krijgen.
Ik weet niet of je op stoelnummer werkt, maar ook dan gaat het nog op:
een "mandje "( noem ik het maar even) is alleen geldig als de timestamp minder dan 1 uur in het verleden ligt.
En van opruimacties heb ik in het verleden vaak genoeg spijt gehad.
Of het nu om historische data van 5 jaar terug ging of om log-files van Apache.
Vaak genoeg staat dat een jaar te slapen en 3 dagen na het wissen komt iemand met de vraag om daar eens een gemiddelde over te berekenen.
En: cronjobs en dergelijke draaien een beetje buiten het zicht. Als die stilvallen, dan kom je daar mogelijk pas achter als je zaal bijna leeg is, omdat de reserveringen niet opgeruimd werden.
Query je beschikbaarheid op basis van "niet meer dan 1 uur oud" dan heb je daar geen probleem mee.
(en je kunt nog steeds eens per maand opschonen als je de kriebels van slapende data krijgt.)
Maar omdat je een stoel reserveert, hoe voorkom je dan dat iemand je hele kaartverkoop platlegt door met 100 man, of een gecreëerd botnet) constant winkelwagentjes staat te vullen met tickets? Niemand die dan door de kaartverkoop komt omdat al die tickets dan gereserveerd zijn.
Misschien een wachtrij maken? En een mail sturen zodra er een ticket beschikbaar is?
Ook daar moet je dan weer slimmigheidjes bedenken en drempels voor werpen.
Dat zet mij wel op het idee waarom je vaak bij ticketverkopen vaak een wachtrij-indicator ziet (vaak een externe partij) voordat je een ticket gaat kopen. Ik kan me nog een nieuwsbericht herinneren met dat er 300.000 mensen in de virtuele wachtrij stonden.
Gewijzigd op 05/09/2022 18:43:19 door - Ariën -
Er zijn 200 tickets voor een voorstelling beschikbaar.
Wanneer is een ticket niet meer beschikbaar? Enkel en alleen als deze is betaald.
Het feit dat iemand iets in z'n winkelmandje legt, moet je niet gaan beschouwen als een reservering.
Als iemand een ticket in z'n mandje gooit en hij gaat betalen, dan check je op dat moment de beschikbaarheid. In mijn optiek kan het niet zo zijn dat door iets in je winkelmandje te plaatsen (en verder niks) je daarmee een ticket reserveert. Daar zal een betaling aan vast moeten zitten.
Als ik op de website van MediaMarkt een televisie in m'n winkelmandje gooi dan heb ik die ook niet ineens gereserveerd. Als er nog maar 1 exemplaar is, en iemand anders betaalt de televisie eerder dan ik, dan heb ik gewoon pech.
Ozzie PHP op 05/09/2022 18:46:09:
Logica:
Er zijn 200 tickets voor een voorstelling beschikbaar.
Wanneer is een ticket niet meer beschikbaar? Enkel en alleen als deze is betaald.
Het feit dat iemand iets in z'n winkelmandje legt, moet je niet gaan beschouwen als een reservering.
Er zijn 200 tickets voor een voorstelling beschikbaar.
Wanneer is een ticket niet meer beschikbaar? Enkel en alleen als deze is betaald.
Het feit dat iemand iets in z'n winkelmandje legt, moet je niet gaan beschouwen als een reservering.
Zeker weten? Als ik bij het Schouwburg een ticket bestel en een stoel kies, dan wordt dit voor mij gereserveerd voor 20 minuten. Ik ben dus zeker van dat als ik betaald heb binnen de 20 minuten, dat deze voor mij is. Als het de laatste stoel is, dan zal iemand helaas een volgeboekte zaal zien. Als ik toch niet betaald heb, en de tijd is verlopen, dan is hij weer vrij voor iemand anders.
Quote:
Als ik op de website van MediaMarkt een televisie in m'n winkelmandje gooi dan heb ik die ook niet ineens gereserveerd. Als er nog maar 1 exemplaar is, en iemand anders betaalt de televisie eerder dan ik, dan heb ik gewoon pech.
En volgens mij is dat ook bij vele webwinkels zo. Ik had pas geleden het laatste product bij een webwinkel, en voordat ik deze betaald had, ging ik uit interesse kijken in de incognito-modus en daar was hij verkocht. Het ligt er naar mijn idee net aan hoe de logica gebouwd is.
Gewijzigd op 05/09/2022 19:07:21 door - Ariën -
Ozzie PHP op 05/09/2022 18:46:09:
Als ik op de website van MediaMarkt een televisie in m'n winkelmandje gooi dan heb ik die ook niet ineens gereserveerd. Als er nog maar 1 exemplaar is, en iemand anders betaalt de televisie eerder dan ik, dan heb ik gewoon pech.
Als ik op de website van MediaMarkt een televisie in m'n winkelmandje gooi dan heb ik die ook niet ineens gereserveerd. Als er nog maar 1 exemplaar is, en iemand anders betaalt de televisie eerder dan ik, dan heb ik gewoon pech.
Hier zit nou JUIST de functie van dat mandje!!
Zodra er iemand een aantal kaarten besteld, en dat zijn de laatste, dan zal mijn systeem de voorraad op nul zetten en dus de melding UITVERKOCHT weergeven.
Als ik dus niets onderneem om die kaarten na een uur niet te zijn afgehandeld, dan blijft het op uitverkocht staan totdat...???
Aangezien ik dus niets heb ingesteld in MyPHPAdmin als zijnde doe iets met die kaarten na een bepaalde tijd, waarvan ik dus ook niet weet hoe ik dit zou moeten instellen zonder een trigger of cronjob, blijven deze kaarten oneindig in het mandje staan.
Nu met de cronjob geeft hij elk uur de niet afgehandelde kaarten weer vrij. En ik kan zelf ook in het systeem kijken en actie ondernemen.
En wij werken per seizoen. De database blijft 1 jaar bestaan en daarna wordt deze verwijdert.
Ik maak dus voor elk seizoen een nieuwe database aan.
Toevoeging op 05/09/2022 19:27:47:
- Ariën - op 05/09/2022 19:06:29:
Zeker weten? Als ik bij het Schouwburg een ticket bestel en een stoel kies, dan wordt dit voor mij gereserveerd voor 20 minuten. Ik ben dus zeker van dat als ik betaald heb binnen de 20 minuten, dat deze voor mij is. Als het de laatste stoel is, dan zal iemand helaas een volgeboekte zaal zien. Als ik toch niet betaald heb, en de tijd is verlopen, dan is hij weer vrij voor iemand anders.
Zeker weten? Als ik bij het Schouwburg een ticket bestel en een stoel kies, dan wordt dit voor mij gereserveerd voor 20 minuten. Ik ben dus zeker van dat als ik betaald heb binnen de 20 minuten, dat deze voor mij is. Als het de laatste stoel is, dan zal iemand helaas een volgeboekte zaal zien. Als ik toch niet betaald heb, en de tijd is verlopen, dan is hij weer vrij voor iemand anders.
Juist!, hier zat dus mijn uitdaging van die 20 minuten, hoe regel ik dit en hoe handel ik dit met een script af? Dat was dus mijn idee van een trigger of een cronjob.
Als je een andere manier zou weten die beter zou zijn, dan verneem ik dat graag hoe jij dat zou oplossen.
Pagina: « vorige 1 2 3 volgende »