Onverwachte volgorde? Opgelost.
Oeps! Sorry!
Ach, toch gevonden.
Het lag aan een extra test-aanroep die ik over het hoofd gezien had.
Gewijzigd op 27/05/2017 21:54:55 door Paul Ulje
(Ik wilde het bericht wissen maar dat ging niet.)
aLijst wordt uit een db opgehaald, op- of aflopend
Code (php)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
function __construct($status = '9', $volgorde = 'asc', $begin = '-', $eind = 'z') {
$this->fillLetters();
$eind = $eind . 'zzzz';
$q = " select * from lemmaas where lemma >= '$begin' and lemma <= '$eind' ";
if ($status < '9')
$q = $q . " and status='$status' ";
if ($volgorde == 'asc')
$q = $q . " order by lemma asc ";
else
$q = $q . " order by lemma desc ";
$db = openDB('otn');
$p = $db->query($q);
while ($row = $p->fetch_array()) {
// deze dus
$this->aLijst[] = array($row[0], $row[1], $row[2]);
}
$db->close();
}
$this->fillLetters();
$eind = $eind . 'zzzz';
$q = " select * from lemmaas where lemma >= '$begin' and lemma <= '$eind' ";
if ($status < '9')
$q = $q . " and status='$status' ";
if ($volgorde == 'asc')
$q = $q . " order by lemma asc ";
else
$q = $q . " order by lemma desc ";
$db = openDB('otn');
$p = $db->query($q);
while ($row = $p->fetch_array()) {
// deze dus
$this->aLijst[] = array($row[0], $row[1], $row[2]);
}
$db->close();
}
Vervolgens wordt aLijst gebruikt om meerdere gegevens uit andere bronnen op te halen.
en omdat aLijst als 'foreach loop' gebruikt wordt zou die volgorde ook in aAlleRecodrs gehandhaafd worden.
Dat bleek niet zo te zijn.
Code (php)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
private function alleRecords() {
$db = openDB('otn');
//aLijst staat in de juiste volgorde
foreach ($this->aLijst as $aLemma):
$lid = $aLemma[0];
$aVarianten = array();
$p = $db->query(" select * from varianten where lid='$lid' order by volgnr ");
while ($row = $p->fetch_array())
$aVarianten[] = $row;
$aVervangers = array();
$p = $db->query(" select * from vervangers where lid='$lid' order by vervanger ");
while ($row = $p->fetch_array())
$aVervangers[] = $row;
// dan zou dit toch ook dezelfde volgorde moeten hebben?
$this->aAlleRecords[] = [$aLemma, $aVarianten, $aVervangers];
endforeach;
$db->close();
}
$db = openDB('otn');
//aLijst staat in de juiste volgorde
foreach ($this->aLijst as $aLemma):
$lid = $aLemma[0];
$aVarianten = array();
$p = $db->query(" select * from varianten where lid='$lid' order by volgnr ");
while ($row = $p->fetch_array())
$aVarianten[] = $row;
$aVervangers = array();
$p = $db->query(" select * from vervangers where lid='$lid' order by vervanger ");
while ($row = $p->fetch_array())
$aVervangers[] = $row;
// dan zou dit toch ook dezelfde volgorde moeten hebben?
$this->aAlleRecords[] = [$aLemma, $aVarianten, $aVervangers];
endforeach;
$db->close();
}
Tot mijn stomme verbazing gaf deze hulpfunctie de omgekeerde volgorde!
Code (php)
1
2
3
4
5
6
7
8
9
10
2
3
4
5
6
7
8
9
10
public function printBoeklijst() {
$this->alleRecords();
// verkeerde volgorde
foreach ($this->aAlleRecords as $aR)
print "<br/>" . $aR[0][1];
$this->boekLijst();
// dus deze ook
foreach ($this->aBoekRegels as $r)
print "<br/>$r";
}
$this->alleRecords();
// verkeerde volgorde
foreach ($this->aAlleRecords as $aR)
print "<br/>" . $aR[0][1];
$this->boekLijst();
// dus deze ook
foreach ($this->aBoekRegels as $r)
print "<br/>$r";
}
Denkend ergens iets over het hoofd te hebben gezien of een eigenaardigheid van PHP niet te kennen, besloot ik ten einde raad dit forum te bevragen.
En terwijl ik na het posten de testcode die deze classLemmaLijst gebruikt opschoon en naloop, zie ik dat er na de 'actieve' test-variabele (instantie, object?) achteraan nog een vergeten aanroep staat. Dus:
1. Ik test aLijst bewust en correct.
2. Ik test onbewust aAlleRecords via een andere aanroep.
Zoiets heb ik ook al eens met css gehad. Dat ik me tot gekwordens toe afvraag wat er verkeerd gaat, en dan pas later zie dat ná mijn inspanning dezelfde selector nog en keer voorkomt....
Ja lach maar. Wees maar blij dat jullie die zeer zeldzame aandoening niet hebben. :-)
Gewijzigd op 28/05/2017 15:36:48 door Paul Ulje
Alleen op het moment dat er db-contact nodig is.
Dus zo kort mogelijk een open db-verbinding.
Vaak is die dan wel elegant in een functie onder te brengen
if (isLemma('dittum')) [then] doe-iets..
Waarbij in function isLemma() een db-contact nodig is.
Is dat niet goed?
Vertel me aub waarom niet en vooral hoe dan beter kan.
p.s. De voorbeelden zijn de enige twee functies uit een grote class die db-contact hebben en worden onafhankelijk van elkaar aangeroepen en uitgevoerd. Ze bouwen/vullen verschillende datastructuren op. Daarom zijn ze hier opgenomen.
Alvast dank!
Gewijzigd op 28/05/2017 20:00:36 door Paul Ulje
Dan hoef je hem alleen maar bij in initiëren te gebruiken.
Vroeger zei men:
1. Zo zuinig mogelijk met 'servertijd' want dat is duur en er zijn anderen die er ook gebruik van willen maken.
2. Hoe korter de verbindingstijd hoe minder risico op dataverminking/procesverstoring.
Ik heb weinig kijk op de moderne afwikkeling van connecties, in deze tijd van plenty...
Extreem enerzijds (zuinig) is mijn ouderwetse benadering van deze materie: zo kort mogelijk, dus vaak herhaald.
Extreem anderzijds (gemak) openen aan het begin van een sessie en sluiten als de sessie vernietigd wordt.
Daartussen vele verstandige mogelijkheden.
Om die goed af te wegen ontbreekt me de kennis van de afwikkeling.
Sta me toe dat ik daarom deze vragen opwerp:
1. Blijft in dat (jouw tip) geval de connectie open zolang de instantie bestaat?
2. Hoe wordt de connectie afgesloten?
3. Kan 'mijn' programma(-instantie) 'eindeloos' veel connecties openhouden
4. Hebben anderen gebruikers van het zelfde programma (i.c. dezelfde tabellen) er last van als ik een db/tabel openhoud?
Alvast dank!
Dit houdt dan in dat je connectie maar een enkele keer gebruikt wordt, maar je kan dan wel alle bijbehorende objecten aanroepen (in het geval van MySQLi). Ook het het procedurele MySQLi heeft de resources van je connectie nodig. Puur vanwege het feit dat hij weet welke verbinding hij moet gebruiken, gezien je ook meerdere connecties en dus resources kan gebruiken.
Tegenwoordig is een 'close' van je database niet nodig. Na de laatste query ruimt hij zijn rommel in het RAM weer netjes op. Hoewel het soms ook wel eens nuttig is om de rotzooi tussendoor op te ruimen, bij draken van queries.
Gewijzigd op 30/05/2017 11:29:34 door - Ariën -
>> 2. Hoe korter de verbindingstijd hoe minder risico op dataverminking/procesverstoring.
Op punt 1 kan ik heel kort zijn, het maken van een databaseverbinding kost onevenredig veel tijd, wat je dus servertijd kost, andere argumenten nog daargelaten. Op punt 2 geldt eigenlijk dat iemand dat uit zijn achterste heeft getrokken. Het hebben van een verbinding zorgt niet voor verminking van je data.
Om nu nog over te gaan op de overige 4 punten:
1. Ja, en dat is helemaal niet erg. Connecties blijven openen en sluiten binnen 1 script is funest voor je performance. Gebruik dus gewoon 1 databaseverbinding en geef die via parameters door aan de rest van je applicatie
2. Bij het eindigen van je script worden verbindingen gesloten
3. Nee, en dat is het probleem ook als je meerdere verbindingen maakt in je script.
4. Ja, maar dat moet ook juist, dit is 1 van de speerpunten voor het hebben van 1 verbinding. Je kunt dan je dataintegriteit garanderen met o.a. transacties. Wanneer je je verbinding constant sluit en opnieuw opent kan dit niet.
Ik ga dat proberen.
p.s. "Tegenwoordig is een 'close' van je database niet nodig."
NetBeans geeft me telkens het advies de php sluittag ?> aan het eind van een script wegens overbodig weg te halen. Het doet mijn Pascalhart pijn....
Gewijzigd op 28/05/2017 20:47:40 door Paul Ulje
Paul Ulje op 28/05/2017 20:45:10:
p.s. "Tegenwoordig is een 'close' van je database niet nodig."
NetBeans geeft me telkens het advies de php sluittag ?> aan het eind van een script wegens overbodig weg te halen. Het doet mijn Pascalhart pijn....
NetBeans geeft me telkens het advies de php sluittag ?> aan het eind van een script wegens overbodig weg te halen. Het doet mijn Pascalhart pijn....
Wat heeft het sluiten van een database met een PHP-sluittag te maken?
Dat die sluittag wordt afgeraden is waarschijnlijk omdat er dan geen eventuele witruimte komt te staan, maar die sluittag kun je er gewoon prima neerzetten hoor. Ik doe dat zelf ook ... omdat ik het persoonlijk netter vind. Alleen altijd even opletten dat er na de sluittag geen enters / witruimte volgt, want anders komt die witruimte (whitespace) op je pagina terecht.
Gewijzigd op 28/05/2017 21:02:33 door Ozzie PHP
En ja, die afsluitende ?> tag is soms echt annoying. ZO ben ik pas nog in een project hard op zoek gegaan naar witregels omdat ik een header() niet uitgevoerd kreeg :-/
Het zou goed kunnen hoor wat je zegt. Bij een bedrijf waar ik werkte werd het ook nooit afgesloten. Toch vind ik het persoonlijk niet mooi. Je <html> sluit je ook af ... waarom je PHP dan niet? Alleen wel even opletten dus dat er geen witregels onder staan.
Programmeursesthetiek.
Maar wat gebeurt er als er witregels resteren?
(Ariën heeft het over een headerprobleem.)
Ik heb het gelijk geprobeerd natuurlijk, en hoewel de editor (NetbBeans) ze NIET automagisch weghaalt, lijkt er niks engs te gebeuren (ik heb een ongeijzigde XAmpp installatie)?
Gewijzigd op 29/05/2017 14:46:53 door Paul Ulje
Paul Ulje op 29/05/2017 14:35:23:
Maar wat gebeurt er als er witregels resteren?
Als je het bestand include en daarna nog een header() gebruikt gaat het fout.
Dan geldt dat van die witregels zeker ook voor code als:
Code (php)
1
2
3
4
5
6
7
8
9
2
3
4
5
6
7
8
9
<?php
session_start();
include_once "otn.inc";
if (!isset($_SESSION['toegangscode']))
header('Location: otn.php');
?>
session_start();
include_once "otn.inc";
if (!isset($_SESSION['toegangscode']))
header('Location: otn.php');
?>
Want dat staat nog op mijn 'zoek uit waarom het niet werkt lijst'.
Ik bedoel de witregels in 'dit' document.
Gewijzigd op 29/05/2017 15:07:33 door Paul Ulje
Paul Ulje op 29/05/2017 14:51:14:
Geldt dat van die witregels ook voor code als:
Code (php)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
2
3
4
5
6
7
8
9
10
11
12
13
14
==> wel witregels hier
<?php
==> niet als zij tussen php-tags staan.
session_start();
include_once "otn.inc";
if (!isset($_SESSION['toegangscode']))
header('Location: otn.php');
?>
<?php
==> niet als zij tussen php-tags staan.
session_start();
include_once "otn.inc";
if (!isset($_SESSION['toegangscode']))
header('Location: otn.php');
?>
De header() van regel 8 kan dan niet meer uitgevoerd worden. (tenzij automagische output buffering aan staat en je niet over die limiet heen gaat)
Ik snap nu het probleem.
De .inc heeft wel een sluittag maar geen witregels.
En voorheen in een oude versie werkte het ook.
Vermoedelijkhad ik toen (bij stom toeval) geen witregels.
Maar sinds ik NetBeans gebruik niet meer.
Die voegt graag zelf witregels aan de opmaak toe (ook een direct na de openingstag!), zodat ik ook zelf maar met witregels aan het strooien ben gegaan...
Weer een hoofdpijndossier geparacetemolleert. :-)