functie regels

Met notices aan, dan krijg je dit:

Warning: Use of undefined constant wertwtert - assumed 'blaet' (this will throw an Error in a future version of PHP) in /tmp/preview on line 3

En dat wordt later dus een error waardoor je script stopt.
Mogelijk in PHP 7.5, of in PHP 8...

ga ik aanpassen :D

maar uhm ....

- SanThe - op 21/03/2020 21:28:03

... ORDER BY datum_invoer DESC limit 1";
....
while($cache = ...


Je krijgt dus maar 1 resultaat, dus is de while() onzin.

ik heb op die while ongeveer 1 tot 6 invoeren ik moet met 200% zekerheid hebben dat ik hier maar 1 van pak de allernieuwste

in verleden die ik een gewone select zonder while maar dan kreeg ik soms dus een error omdat hij er meerdere vond

waarom snapte ik niet en daarom die while, als iemand een betere manier weet hoor ik dit graag
ook met distinct kreeg ik toen soms errors

En even een tipje: gebruik eens wat vaker een variabele:

<?php
//in plaats van
$file_datum = date('Y-m-d H:i:s', filemtime(''.$folder.'/'.$accountid.'/'.$jaar.'/'.$maand.'/users/'.$id.'/'.$datum.''));

if (file_exists(''.$folder.'/'.$accountid.'/'.$jaar.'/'.$maand.'/users/'.$id.'/'.$datum.'') && $sql_datum > $file_datum ) {

unlink(''.$folder.'/'.$accountid.'/'.$jaar.'/'.$maand.'/users/'.$id.'/'.$datum.'');
//sql is nieuwer
}
elseif (file_exists(''.$folder.'/'.$accountid.'/'.$jaar.'/'.$maand.'/users/'.$id.'/'.$datum.'') && $sql_datum < $file_datum ) {

include(''.$cachefolder.'/'.$accountid.'/'.$jaar.'/'.$maand.'/users/'.$id.'/'.$datum.'');
//sql is ouder
}

//wordt het dan
$file_name = '/'.$accountid.'/'.$jaar.'/'.$maand.'/users/'.$id.'/'.$datum.'';
$file_datum = date('Y-m-d H:i:s', filemtime($folder . $file_name));

if (file_exists($folder . $file_name) && $sql_datum > $file_datum ) {

unlink($folder . $file_name);
//sql is nieuwer
}
elseif (file_exists($folder . $file_name) && $sql_datum < $file_datum ) {

include($cachefolder . $file_name);
//sql is ouder
}
?>

Sowieso heeft het niet veel nut om de filemtime() van een bestand op te vragen als ie toch niet bestaat (geeft je waarschijnlijk een warning in je log - die dus enorm uit de klauwen loopt). Tevens check je nu 2x of ie bestaat. En dan nog een beetje inspringen, en dan ziet het er opeens als zo uit:

<?php
$file_name = '/'.$accountid.'/'.$jaar.'/'.$maand.'/users/'.$id.'/'.$datum.'';

if (file_exists($folder . $file_name)){
  $file_datum = date('Y-m-d H:i:s', filemtime($folder . $file_name));

  if ($sql_datum > $file_datum ) {
    unlink($folder . $file_name);
    //sql is nieuwer
  }
  elseif ($sql_datum < $file_datum ) {
    include($cachefolder . $file_name);
    //sql is ouder
  }
}
?>

Doet (als het goed is ;-) ) hetzelfde - naar mijn idee beter leesbaar.

ik ga dit even uitpluizen ziet er inderdaad beter uit :)

Wat gebeurt er ingeval "sql is nieuwer"? Je verwijdert dan een bestand, maar gebeurt er dan verder nog iets? Is dat niet het uitgelezen moment om meteen een nieuw cachebestand te bouwen? En als dat dan gebeurt, waarom dan niet direct op die plek?

Een andere vraag, waarom heb je al die cache zooi nodig? Is dit niet een verkeerde oplossing (bestanden bouwen) voor een ander probleem (trage queries)?

En hoe zit het met de veiligheid van die bestanden? Staan deze buiten de webdirectory? Zijn deze nog op een andere manier afgeschermd of kan iemand door het manipuleren van het webadres/andere variabelen materiaal van andere mensen inzien?

Het klinkt gewoon als enorm veel overhead voor niets.

Verder: waarom engelse en nederlandse naamgeving door elkaar...

Overigens, unlink kun je ook zonder controle uitvoeren, het maakt niet uit of het bestand vantevoren bestond, en als je dit bewust doet, is een @ (voor het onderdrukken van de notice) gerechtvaardigd.

Wat als $sql_datum precies gelijk is aan $file_datum? Hoe onwaarschijnlijk dat ook moge zijn, die case is nu ongedefinieerd...

Dit:

function checkcachefolder($folder,$accountid,$jaar,$maand,$id) {    
if (!file_exists(''.$folder.'/'.$accountid.'/'.$jaar.'/'.$maand.'/user/'.$id.''))
        {
            mkdir(''.$folder.'/'.$accountid.'/'.$jaar.'/'.$maand.'/user/'.$id.'', 0777, true);
        }      
}

(wat is er trouwens aan de hand met het inspringen in code? dit is onleesbaar)
is veel te specifiek.

Vraag jezelf af: waar ben je mee bezig? Antwoord: ik controleer op het bestaan van een directory, en als deze niet bestaat, maak ik deze aan.

Dat is dan ook precies wat de functie zou moeten doen, niet meer, en niet minder.
Al die parameters... weg ermee. Misschien wil je nog een mask meegeven ofzo, fijn, maar $accountid, $jaar, $maand, $id - weg ermee.

Je hebt voldoende aan een $path en eventueel een $mask. Maar dan, dan krijg je dus een universele functie ... die nauwelijks toegevoegde waarde heeft ten opzichte van de standaard functies (file_exists, mkdir). Wil je dit soort dingen in aparte functies vangen zodat je een soort van alias/shorthand creeert? Nou nee, niet echt.

En wil je dit echt on-the-fly bouwen of aanpassen als iemand informatie aan het opvragen is? Zou dit niet op een aparte plek in een apart proces op gezette tijden (cronjob?) moeten gebeuren zodat de klant niet hoeft te wachten en dit soort dingen ook niet in hun gezicht kunnen ontploffen?

Eigenlijk wel, of eigenlijk, je wilt dit alles (een berg aan bestanden) bij voorkeur niet. Dit zijn allemaal diskoperaties, die zijn ontzettend duur. Plus je bent je boekhouding die in je database zit nog eens dunnetjes aan het namaken in een soort van filesysteem. Waarom in hemelsnaam?!

Volgens mij is dit wat men noemt a fractal of bad design.

Stel jezelf de volgende vraag. Als jouw queries deze informatie op een efficiënte manier kunnen ophoesten, waar heb je dan al die bestanden precies voor nodig? ...

Uit het vorige topic heb ik begrepen dat dit bedoeld was om de traagheid op te vangen.
Totaal niet netjes! Maar gezien zijn enorme codebase waarover hij vertelt is het niet triviaal om even snel van deze werkwijze af te stappen. Dan liever in stappen uitfaseren.

Lekker agile en scrum related werken dus... ;-)

Ja, maar misschien was een onderzoek naar de oorzaak van die traagheid zinniger geweest :p.

Verder trekken aan dit dode paard lijkt mij redelijk zinloos. Tis waarschijnlijk ook een blokken toren, haal je een stukje ertussenuit, lazert de rest in elkaar.

Zou dit vlug reverse engineeren en parallel iets nieuws bouwen.

ok hier beginnen we weer, open een topic met gewoon een simpel iets en er wordt weer van allerlij dingen bij bedacht en dan raar vinden dat topic zo lang wordt
dus hier gaan we weer.

Wat gebeurt er ingeval "sql is nieuwer"?

ok in mijn online software heb ik een deel dat er dranken ingevoerd kunnen worden een soort dag totaal
dit wordt in sql gezet en er wordt tevens gelijk een vaste cache gemaakt van die dag onder nummer 9999 eindomzetdranken. (cache enzo kom ik zo op terug)
echter vergeet een bedrijf soms een aantal biertjes of bv een cola die niet erbij stond
ik heb bij de dranken een extra deel gemaakt dat ze dit mogen toevoegen
echter heb ik dus al een cache die dag
dus dit script stukje moet checken of de sqltijd nieuwer is dan bestand tijd, soja betekent het dus dat de cache niet klopt en moet die worden verwijdert
na de verwijdering moet hij opnieuw een cache maken
dit wordt op een ander deel gedaan omdat dit een heel zwaar en groot process is met heel veel berekeningen,
kan dit sneller NEE
ik heb dit echt op heel veel manier gedaan en kan niet sneller en niet beter
hoe ga ik nu niet weer helemaal uitleggen,
nee ook niet via sql laten berekenen want die gebruiken school rekenen en niet belasting rekenen
ik verwijs jullie even door
[link]https://www.belastingdienst.nl/wps/wcm/connect/bldcontentnl/belastingdienst/zakelijk/btw/administratie_bijhouden/facturen_maken/btw-bedrag_afronden[/link]
en ik gebruik "U rondt af per geleverd goed of verrichte prestatie."
om deze reden heb ik heel erg veel berekeningen die alleen op de manier hoe ik het doe goed is

Een andere vraag, waarom heb je al die cache zooi nodig? Is dit niet een verkeerde oplossing (bestanden bouwen) voor een ander probleem (trage queries)?

ja trage queries omdat het gegevens moet zoeken en berekenen van een heel jaar van minimaal 30 personen x minimaal 6 invoeren.
dat zijn dus minimaal 65700 rijen
dit wordt gevonden tussen rijen waar ook 10 andere bedrijven staan met 7 jaar aan rijen
dat zijn dus ongeveer 4600000 rijen waar hij door moet zoeken

O en voordat je het vraagt ja ik gebruik indexen op plekken waar dit kan
mijn grootste pagina doet over al deze berekeningen met de cache 3 sec max

En hoe zit het met de veiligheid van die bestanden? Staan deze buiten de webdirectory? Zijn deze nog op een andere manier afgeschermd of kan iemand door het manipuleren van het webadres/andere variabelen materiaal van andere mensen inzien?

ik ben nu aan het testen maar in de live cache worden de mappen en de bestanden md5 gecodeerd met een salt
tevens zijn de bestanden in de live cache alleen vie script te openen en dus alleen het bedrijf waar het om gaat zou het kunnen zien

indien iemand het wel kan zien dan hebben ze er niks aan

Wat als $sql_datum precies gelijk is aan $file_datum? Hoe onwaarschijnlijk dat ook moge zijn, die case is nu ongedefinieerd...

haha die is wel goed, echter wordt er gechecked op 0,01 sec
bestand wordt altijd pas na de sql gemaakt en dus kan deze nooit ouder zijn dan de sql :P

Vraag jezelf af: waar ben je mee bezig? Antwoord: ik controleer op het bestaan van een directory, en als deze niet bestaat, maak ik deze aan.

ik snap je dit lijkt onnodig echter in verleden heb ik door nog onbekende reden meegemaakt dat hij bestand niet wou aanmaken als de map er niet was, dus,
eerst map dan files
ik hou niet van iets dat zou moeten werken
ik wil iets dat 1000% zeker werkt ook al gaat het via een omweg.

Al die parameters

ja allemaal zijn nodig helaas, bij elke cache moet hij die gegevens meekrijgen

(cronjob?)

juist hier moeten ze op wachten mijn cache wordt in princiepe gelijk gemaakt bij het invoeren van de boekhouding in de sql

echter soms door iets aan te passen verwijder ik uit veiligheid de gehele cache en deze moet hij dan dus in 1 keer voor elke dag voor elke werknemer over een heel jaar aanmaken

je bent je boekhouding die in je database zit nog eens dunnetjes aan het namaken in een soort van filesysteem. Waarom in hemelsnaam?!

ja je hebt gelijk echter door dat filesysteem is de berekening 99% sneller
daarom dus

Als jouw queries deze informatie op een efficiënte manier kunnen ophoesten, waar heb je dan al die bestanden precies voor nodig? ...

uhm de queries zijn niet het probleem
het zijn de noodzakelijke berekeningen
ik heb dit ook via andere manieren geprobeerd maar ik moet alle gegevens los hebben voor een speciale dag loonstrook
uitleggen ga ik nu allemaal niet doen maar ik moet het dus zo doen en kan niet anders


als 1 van jullie persoonlijk langskomt kan ik het laten zien
want het is niet zo simpel als jullie denken
ik heb scripters ooit ingehuurd die net zoals jullie denken
allemaal het nieuwste van nieuwste willen want oud is ouderwets bla bla
deze goeie scripter werd na het tonen van mijn idee helemaal stapelgek
zijn antwoordt kwam neer op dit kan helemaal niet, is onmogelijk
laat een boekhouder dit lekker doen enz enz

ik heb zeg maar 6 rijen
met deze 6 rijen moet ik heel veel verschillende variabelen creeeren die niet in de sql staan
alles moet worden berekent via de belasting regel van 3
dus handmatig
nadat alle berekeningen klaar zijn hou ik ongeveer 72 variabelen over in 1 cache
om deze bedragen te krijgen heb ik dus nog veel meer

dus stop allemaal met het zeuren van het kan beter
kom langs en laat zien en hou anders gewoon je mond
tuurlijk zit er een beetje ruimte in voor verbetering en dat ben ik ook echt wel aan het doen

Al die parameters

ja allemaal zijn nodig helaas, bij elke cache moet hij die gegevens meekrijgen

Nee, die zijn niet nodig. Het is voor de functie niet relevant hoe het pad is opgebouwd, het is de taak van de functie om het pad te controleren en hier iets mee te doen.

Vergelijk:

<?php
function checkcachefolder($folder,$accountid,$jaar,$maand,$id) {    
if (!file_exists(''.$folder.'/'.$accountid.'/'.$jaar.'/'.$maand.'/user/'.$id.''))
        {
            mkdir(''.$folder.'/'.$accountid.'/'.$jaar.'/'.$maand.'/user/'.$id.'', 0777, true);
        }      
}
?>

Met:

<?php
function createDirectoryIfNotExists($path) {
    if (file_exists($path) === false) {
        mkdir($path, 0777, true);
    }
}
?>

Dat is wat de code functioneel zou moeten doen.

Dat het pad gelijk is aan $folder.'/'.$accountid.'/'.$jaar.'/'.$maand.'/user/'.$id zal de functie echt worst wezen. Dat is niet aan de functie.

Op het moment dat je deze functie aanroept stel je $path gewoon gelijk aan het bovenstaande, dus heel concreet, bij de aanroep doe je dit:

<?php
createDirectoryIfNotExists($folder.'/'.$accountid.'/'.$jaar.'/'.$maand.'/user/'.$id);
?>

Maar dit is nog steeds niet echt een fantastisch idee omdat:
- er van alles mis kan gaan indien je geen rechten hebt, of het aanmaken faalt, of wat dan ook
- er geen enkele melding terug wordt gegeven over de toestand / het eindresultaat (bewerking geslaagd of niet)
- wat er functioneel gebeurt niets toevoegt aan het simpelweg controleren op het bestaan met file_exists en het eventueel aanmaken met mkdir; de functie heeft 0,0 meerwaarde

Noch wordt hier in code gevolg aan gegeven, het proces staakt niet als er een fout optreedt maar ratelt vrolijk door, en haalt alles ondertussen door de vleesmolen.

ok lol dus inplaats van de parameters aan de functie mee te geven moet ik 1 parameter meegeven met dezelfde info in 1 parameter
het maakt in feite dus helemaal niks uit
datum moet daar ook nog ergens in...

alles is met een reden gedaan
als er geen rechten zijn is site gewoon traag omdat hij dan geen cache kan maken en vinden,
dit kan alleen gebeuren als er een idiote hacker in mijn dediserver dit zou hebben gelocked

als jullie je nou allemaal even met andere dingen bezig gaan en niet gaan bemoeien waar jullie blijkbaar toch geen verstand van hebben

dan kan iedereen stoppen met het volspammen van deze site en dan kunnen mensen reageren die echt goede ideeen hebben en inbrengen

dank u