update werkt niet bij een bepaald aantal tabelrijen

Hangt er ook vanaf wat je allemaal tegelijkertijd wilt bewerken. Dit doe je zelden tot nooit met een compleet ledenbestand.

Ook over het doel van de code zou je het kunnen hebben, maar ik heb nog steeds geen code gezien.

Misschien iets van betalingen afvinken, of iets dergelijks. Maar dan is het onzinnig om alles te updaten.
Daarom is het handig om een diff'je te trekken over de POST en diens gelijkliggende arraystructuur uit de database.

Maar zelfs dat doe je niet in bulk, tenzij je dat geautomatiseerd doet :p.

Het gaat juist prima bij het bijhouden van lijsten. Het trekken van een diff'je bespaart het aantal queries.
Het ligt meer aan de data die je beheert. Zo houd ik op deze manier een lijst van treinstel/-stamnummers en de status ervan bij.

Ik ben al blij dat ik geen single-page heb voor een treinstel/treinstam. ;-)

- Ariën - op 29/03/2019 17:18:11

<?php
function array_diff_assoc_recursive($array1, $array2) {
foreach ($array1 as $key => $value) {
if (is_array($value)) {
if (!isset($array2[$key])) {
$difference[$key] = $value;
} elseif (!is_array($array2[$key])) {
$difference[$key] = $value;
} else {
$new_diff = array_diff_assoc_recursive($value, $array2[$key]);
if ($new_diff != FALSE) {
$difference[$key] = $new_diff;
}
}
} elseif (!isset($array2[$key]) || $array2[$key] != $value) {
$difference[$key] = $value;
}
}
return !isset($difference) ? 0 : $difference;
}

// loop de arrays recursief door en toon de verschillen.
$diff = array_diff_assoc_recursive($_POST['items'], $data);

// toon je de array
echo "<pre>".print_r($diff,1)."</pre>";
?>

Wat zou dit precies moeten doen? De oorspronkelijke array_diff(a, b[, c...]) functie bekijkt namelijk wat enkel in "a" voorkomt, en niet in "b", "c" et cetera. De vraag is of dit precies het verschil dekt (en wat betekent dit verschil precies? en hoe gebruik je dit?). En als dit niet in $_POST voorkomt, zou dit ook in kunnen houden dat er informatie verwijderd zou moeten worden, maar als die informatie afwezig is zul je dit alsnog in zijn geheel moeten spiegelen met de database-inhoud?

Let wel: array_diff() geeft dus mogelijk niet exact het verschil tussen twee arrays retour, maar alles wat verschilt ten opzichte van het eerste array (en dat is niet helemaal hetzelfde). Als dat recursieve ding op een soortgelijke wijze werkt is het misleidend als je het op de eerstgenoemde manier probeert te gebruiken.

Vergelijk:

<?php
$test1 = array('een', 'twee', 'drie');
$test2 = array('een');

echo '<pre>'.print_r(array_diff($test1, $test2), true).'</pre>';
/*
levert
Array
(
    [1] => twee
    [2] => drie
)
*/
echo '<pre>'.print_r(array_diff($test2, $test1), true).'</pre>';
/*
levert
Array
(
)
*/
?>

Oftewel, array_diff() is niet commutatief.

Dan is er nog de mogelijke complicatie in bovenstaande implementatie met isset() in combinatie met NULL-waarden. isset() levert false op indien een variabele een NULL-waarde heeft. NULL-waarden kunnen mogelijk betekenis hebben in arrays, dus het lijkt mij onverstandig om deze op voorhand uit te sluiten. array_key_exists() lijkt mij een veiliger alternatief.

Maar los hiervan, ik zou eigenlijk nooit met verschillen werken maar gewoon alles leeggooien en opnieuw vullen in een database-transactie. Of gewoon een andere aanpak kiezen.

Topicstarter heeft ook nog steeds niet duidelijk gemaakt wat nu eigenlijk de bedoeling is. Daaruit moet nog blijken of de reeds ingeslagen weg wel een verstandige was. Het begint met een analyse, niet met een of andere knip-en-plak oplossing voor een onbekend probleem.

Iedereen bedankt voor het meedenken. Ik ga er vanuit dat hier het probleem ligt: max_input_vars.

Deze is max 1000 en ik krijg het via htaccess en php.ini niet aangepast en ga het dus bij de provider voorleggen.

Alle andere (scripts)oplossingen zijn heel mooi en daar ga ik ook wel mee aan de slag, alleen gaat me dat op dit moment teveel tijd kosten. Temeer omdat het systeempje prima draait tot ik tegen een limiet aan loop. Ik zal nog eentestversie aanmaken en daarbij het aantal te verwerken velden verminderen. Kijken wat er dan gebeurt.

Bedankt en goed weekend verder.

Als je tegen de max_input_vars aanloopt, dan moet je hiervan een error te zien krijgen, of deze uit de logs kunnen vissen.

Ikzelf raad aan om het aantal velden te minimaliseren, en iets van een pagina-navigatie inbouwen.

Pagination ingebouwd en daarmee het probleem opgelost.

Altijd een goed idee! :-)

Hoe je een applicatie vormgeeft hangt sterk af van de aard van de informatie, en hoe je deze wilt bewerken.

Zonder verdere informatie over wat deze informatie nu precies inhoudt lijkt het mij nogal voorbarig om te zeggen dat het in bulk behandelen van deze data en/of deze pagineren "altijd een goed idee" is. Misschien kom je met wat filters of sorteeropties verder dan simpelweg een paginering.

Ook kan ik mij weinig voorstellen bij het batchgewijs verwerken van data enkel op het criterium "X opeenvolgende records". Tenzij er op een specifieke manier gesorteerd wordt? Wederom, hier kan ik niets over zeggen omdat ik niets weet over de aard van de data.

Dan rijst dus ook de vraag of paginering ook echt de juiste oplossing is, of dat je daarmee enkel het directe probleem wegneemt waarbij het om een of andere reden niet mogelijk was om alles in één keer te verwerken (en Joost mag weten of dat ook echt wenselijk is).

Een alternatieve oplossing zou je bijvoorbeeld ook kunnen zoeken in de richting van het groeperen van data op grond van een kenmerk (categorie, soort, rol, type et cetera). Vervolgens kun je op dit kenmerk je data filteren, zodat je waarschijnlijk inzoomt op dat specifieke deel waarin je geïnteresseerd bent.

Het lijkt mij (extreem) foutgevoelig om elke keer (en ik heb nog steeds geen argument gehoord waarom dit ook echt noodzakelijk zou zijn) in bulk grote updates op informatie uit te voeren.

En als dit daadwerkelijk een soort van administratief systeem betreft waarbij dit nodig is dan hoop ik van harte dat je ook van database-transacties gebruik maakt. Want stel nu dat er halverwege zo'n batch iets misgaat, en je gebruikt geen transactie? Dat houdt dan in dat de helft van de relevante records is geupdate, en de andere helft niet?

Nu heb je nog relatief weinig records en is alles nog te overzien. Maar als je niet in een vroeg stadium alles zo aanpakt dat er niets/zo min mogelijk fout kan gaan dan heb je binnen de kortst mogelijke tijd een enorme hoeveelheid stront in je database zitten.

Laat ik het anders verwoorden: als je niet uitlegt:
- wat voor data het betreft
- hoe je deze wenst te bewerken
(- en waarom)

Dan kunnen wij je eigenlijk op geen enkele manier voorzien van goed advies over de vormgeving of aanpak.