Door
Jasper Schellekens
op 01-03-2018 16:06
gewijzigd op 01-03-2018 16:07
2.349 views
Ik ben een script aan het maken waarmee je prive berichten naar elkaar kunt versturen.
Door middel van het nummer van rijen op te halen wil ik laten zien hoeveel berichten iemand heeft.
Nu heb ik een probleempje met het laten zien van hoeveel rijen er zijn opgehaald.
Als er 5 rijen worden opgehaald, laat het script zien dat het er maar 4 zijn. Er mist er altijd eentje.
Om dit te corrigeren heb ik dit gebruikt:
$countrows += 1;
Dit zal waarschijnlijk niet de normale gang van zaken zijn. Ik heb count(*) ook geprobeerd, maar zonder resultaat. Deze liet namelijk altijd 0 zien.
Het probleem hiermee is, dat als de gebruiker geen berichten heeft, het script denkt dat de gebruiker 1 bericht heeft, terwijl er geen zijn. Dit komt door: $countrows += 1;
Nu heb ik enkele dingen geprobeerd om de boel te manipuleren om te kijken of dat wel werkte, maar helaas. Bijv:
Hoe kan ik er nou voor zorgen, dat als er geen rijen zijn er niet alsnog 1 word laten gezien.
Natuurlijk kan dit door $countrows += 1; te verwijderen maar dan laat hij er nog maar 4 ipv 5 zien.
(het script laat wel gewoon de 5 rijen zien, maar de $countrows laat er maar 4 zien)
code:
$sql = "SELECT * FROM MESSAGES WHERE RECEIVER ='$getusername' AND READ ='0'";
$stmt = $db->query($sql);
$row = $stmt->fetchArray(SQLITE3_ASSOC);
$countrows = SqliteNumRows($stmt);
$countrows += 1;
function SqliteNumRows($query){
$numRows = 0;
while($rows = $query->fetchArray()){
++$numRows;
}
return $numRows;
EDIT: tevens zorgt de functie ervoor dat er na afloop van de aanroep hiervan geen records meer over zijn om op te halen, waardoor het statement niet direct meer te gebruiken is, weet ook niet of dat de bedoeling is.
Als je PECL installeert, of laat installeren, dan juist wel.
Als je die mogelijkheid niet hebt, dan zou ik me afvragen of een overstap naar een ander DBMS een optie is.
Maar zoals eerder gezegd is, zijn dit alternatieven die je moet onderzoeken en of het op het gebruik van je applicatie aansluit.
Dit is besproken maar dit is geen optie nee, dit betekend dat wij honderden duizenden regels code zullen moeten herschrijven.
Dat lijkt mij overdreven. Met 'find & replace' heb ik zelfs in een paar uur tijd in een hele webapplicatie 'herschreven' van good-old mysql naar mysqli-OO.
Natuurlijk kan je ook een object-georiénteerde wrapper schrijven die alle databasefuncties bevat (connctie, fetchen, records tellen etc), zodat je eenvoudig een andere DBMS kan implementeren.
Maar het is net wat jij wilt, maar ik heb zo het idee dat SQLlite niet meer actief wordt geüpdated binnen PHP, en dat jij je vast moet houden aan de PECL-bibliotheek die je moet installeren om bij de tijd te blijven.
Dat lijkt mij overdreven. Met 'find & replace' heb ik zelfs in een paar uur tijd in een hele webapplicatie 'herschreven' van good-old mysql naar mysqli-OO.
Alleen spreek ik niet over een webapplicatie.
Geloof me, find & replace gebruiken gaat niet zo simpel met de code waar de game mee is gemaakt.
In de game waar ik script hebben wij bewust voor sqlite gekozen omdat dit veel makkelijker en compacter was dan mysql. We gebruiken een soort van plugin die sqlite heel uitgebreid maakt. Echter met PHP lopen we dan wel tegen vanalles aan. Waarschijnlijk omdat zoals je zei sqlite niet meer geupdate word in PHP.
Ik ga eens kijken wat ik kan met PECL.
In de game waar ik script hebben wij bewust voor sqlite gekozen omdat dit veel makkelijker en compacter was dan mysql. We gebruiken een soort van plugin die sqlite heel uitgebreid maakt. Echter met PHP lopen we dan wel tegen vanalles aan. Waarschijnlijk omdat zoals je zei sqlite niet meer geupdate word in PHP.
Ik ga eens kijken wat ik kan met PECL.
Als je zelf superuser-rechten hebt op de server, dan kan dat.
Als ik zo hoor is de keuze al een tijd geleden gelegd. Maar stiekem blijf ik toch benieuwd waarom MySQL niet de beste keuze was?
Enkele gebreken aan SQLlite is dat de performance niet te tweaken is, en dat er geen authenticatielaag in zit. En met name voor een game zou het toch handig zijn om de performance te kunnen configureren. Vooral omdat er een hoop schrijf en leesacties in plaatsvinden. Ook zou het geen kwaad kunnen om met authenticatie de rechten van je user op je database te beperken. Het zou zonde zijn als iemand een DROP TABLE; voor elkaar kreeg.