Echo number of rows.
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:
Code (php)
1
$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:
Code (php)
1
2
3
4
2
3
4
while(!$row = $stmt->fetchArray(SQLITE3_ASSOC))
{
$countrows = 0;
}
{
$countrows = 0;
}
Ze worden op deze manier opgehaald:
Code (php)
1
echo "<span class='badge'>".$countrows." unread</span>";
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:
Code (php)
1
2
3
4
5
6
7
8
9
10
11
12
13
2
3
4
5
6
7
8
9
10
11
12
13
$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;
$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;
Gewijzigd op 01/03/2018 16:07:20 door Jasper Schellekens
Vervolgens telt de functie SqliteNumRows() hoeveel records er nog over zijn.
Als je vantevoren een record ophaalt is het niet verwonderlijk dat er een record minder wordt geteld.
Naamgeving is ook slecht, $query is geen query, maar een SQLite statement.
Daarnaast heeft SQLite hier al een ingebouwde functie voor...
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.
Gewijzigd op 01/03/2018 16:18:46 door Thomas van den Heuvel
Naamgeving heeft hier vrij weinig mee te maken, ik zie geen reden om bepaalde naamgeven te hanteren als dit voor mij het makkelijkste is.
Ik gebruik sqlite3 die helaas geen sqlite_num_rows meer ondersteund.
Edit:
Het is niet nodig om het voorlaatste bericht in de thread integraal te quoten. De quickreply is er niet voor niks. Gelieve hier in het vervolg bij op te letten.
Gewijzigd op 01/03/2018 17:13:24 door - Ariën -
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.
Probeer eens $stmt->fetchColumn(); i.c.m. count().
bron1 bron2(zie voorbeeld onderaan)
Ik gebruik zelf altijd rowCount()
Gewijzigd op 01/03/2018 17:19:48 door Michael -
Jasper Schellekens op 01/03/2018 17:21:45:
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.
Gewijzigd op 01/03/2018 17:37:06 door - Ariën -
- Ariën - op 01/03/2018 17:31:30:
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.
Misschien had je dit risico dan wellicht wat beter kunnen spreiden.
Jasper Schellekens op 01/03/2018 17:58:23:
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.
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.
Gewijzigd op 01/03/2018 19:30:08 door - Ariën -
@Jasper heb je hier (ook) al (echt) naar gekeken?
Jasper Schellekens op 01/03/2018 17:21:45:
Dit is besproken maar dit is geen optie nee, dit betekent dat wij honderden duizenden regels code zullen moeten herschrijven.
Dan wordt het misschien nu tijd om op de blaren te zitten om te voorkomen dat dit later nog meer pijn doet. Daarnaast zou/had je natuurlijk ook was basale tests uit kunnen voeren, om te kijken of de database zich wel leent voor wat je ermee probeert te doen.
Vraag ik mij toch af hoe de besluitvorming dan is geweest dat je bij SQLite uitkomt, en dat je na het schrijven van "honderden (schuine streep?) duizenden regels code" erachter komt dat je vrij elementaire functionaliteit lijkt te missen.