Lazy loading in een collectie met paging

[Michali]

Ik heb al redelijk veel geëxperimenteerd met lazy loading en ik heb het gevoel dat is wel redelijk weet hoe het goed toe te passen. Nu wil ik naar de volgende stap en dat is lazy loading binnen een collectie die paging moet ondersteunen.

Stel dat ik een lijst van 10.000 producten heb, welke gesorteerd zijn op naam, dan wil ik ervoor zorgen dat ik ze in stappen van 50 per keer kan laden, waarbij ik kan aangeven welke 'page' ik wil hebben. Page 1 is dan product 1 tot en met 50, page 2 is 51 tot en met 100 enz.

Dat is op zich geen probleem. Waar ik alleen moeite mee heb is het aangegeven waarop gesorteerd moet worden. Ik heb bijvoorbeeld een lazy loading collectie class, die ik bij het instantiëren een loader object meegeef, die er voor zorgt dat de objecten geladen worden. Het is dan taak van de collectie class zelf om de al geladen objecten te cachen, zodat dit niet dubbel gebeurt.

Maar wat als de sorteringscriteria nu eens veranderen? Stel ik wil de producten op prijs sorteren en ik heb al enkele pages op naam uit de collectie gehaald. Invalidate je dan gewoon je complete cache en begin je opnieuw met laden? Ik zie geen andere oplossing. Ik zou dan het loader object moeten laten controleren van de criteria waarop gesorteerd wordt gewijzigd zijn en dan eventueel de cache laten weggooien, omdat deze niet meer klopt.

Of vind je dat het paging gedeelte geen goede taak voor een collectie class is met lazy loading en implementeer je dit op een andere manier? Het in 1 keer inladen van 10.000 producten zie ik niet zo zitten, dus het inladen met pages wil ik wel zo houden.

Hopelijk heeft iemand hier wat zinnigs over te zeggen, ik ben er wel benieuwd naar.

[Alarmnummer]

Ik zou het niet zo lazy maken, maar expliciet. Er is niets mis mee om een database te raadplegen op zoek naar informatie. Het is niet de bedoeling dat het zo ver mogelijk weggestopt gaat worden.

Zie de db als een collectie op een veilige plek

[Michali]

Ik gebruik de DB al zoals je het zegt. Middels het repository pattern. (Als dat is wat je bedoeld.) Maar ik snap niet zo goed hoe ik nu het lazy gedeelte weg moet laten en dan expliciet moet gaan werken.

Als ik een set producten wil ophalen, welke nog niet geladen zijn, dan moeten deze bij de repository opgehaald worden. Als ik dit doe via een collectie class die de lazy loading voor me regelt, dan hoef ik daar niet meer naar om te kijken.

Als ik dit echter expliciet doe, dan zou dit betekenen dat de repository de caching voor me regelt, waardoor ik de tweede call voor de zelfde page heel snel kan doen. Maar omdat de repository al een soort van collectie class is, komt dit dan bijna op hetzelfde neer.

Of denk je er meer aan om het laden van die tweede page gewoon te laten voor wat het is? Dat dus niet cachen en gewoon opnieuw de query uitvoeren.

Misschien snap ik het gewoon niet goed. Kun je me nog iets verder in de goede richting duwen?

[whoami]

Is het zo'n probleem om 10.000 records in één keer te laden ? Je hoeft daarom toch niet 10.000 volledige producten laden ? Je kan toch een 'ProductListInfo' object oid laden, waarbij je enkel het Id en de naam (en evt andere info die je wilt tonen) ophaalt ?

Ik denk dat, als je dit mbhv lazy loading wilt gaan doen, dat het boeltje wel heel complex wordt.

Als het echt te veel is om 10.000 records in één keer te laden, dan zou ik gewoon een repository-method aanroepen die mij gewoon een collectie heeft van product X tot X+50, en de vorige idd niet cachen.
(Heeft het nut om, als je door je result-lijst wilt scrollen om de vorige n producten in een List te cachen ? Ik denk het niet.... Het is veel simpeler om gewoon iedere keer je de volgende / vorige 50 producten opvraagt, een query te doen.
En de performance zal er imho ook niet onder lijden.

[Michali]

Ok, bedankt, dat lijkt me wel duidelijk dan. Ik zit blijkbaar weer iets te moeilijk te denken. Ik ga het eens proberen wat simpeler aan te pakken.

[whoami]

Michali schreef op vrijdag 15 december 2006 @ 11:14:
Ok, bedankt, dat lijkt me wel duidelijk dan. Ik zit blijkbaar weer iets te moeilijk te denken.

Soms heb ik dat ook; en dan zit je uren op een probleem omdat je het zo 'mooi' mogelijk wil aanpakken, maar uiteindlijk ga je dan bijna niet vooruit omdat je iedere keer weer op wat anders botst.
En dan denk je: f*ck it, ik doe het zo, en het zal ook werken. Misschien wat minder 'mooi' of minder generiek aangepakt, maar het doet wat het moet doen, en het is ook nog duidelijk en goed.

[EfBe]

Dit heeft niet zoveel met lazy loading te maken. Lazy loading is het inladen van related entities wanneer je ze expliciet wilt gebruiken en ze niet aanwezig zijn. Ik zou inderdaad gewoon zoals alarmnummer zegt: expliciet de collection fetchen en wel de page die je wilt.

Wanneer sorting wordt gewijzigd, is dat een reset van de complete view op de totale set aan entities. Dus je MOET weer van voren af aan, anders mis je entities.

[Michali]

Op zich is dat wel precies wat ik wil.

Stel je hebt een entity ProductCatalogus, met een relatie naar Product. Deze producten zouden dan in een collectie class kunnen zitten. Ik wil de producten per 50 stuks bekijken, maar niet zorgen dat ze dan allemaal geladen worden. Dat is wel een vorm van expliciet gebruiken terwijl ze mogelijk niet aanwezig zijn.

Ik wilde het zo verwerken dat de class ProductCatalogus gewoon zijn collectie kan gebruiken, zonder dat deze doorheeft dat achter de schermen het laden van objecten gebeurt. Probeer dus waarschijnlijk idd. te veel weg te stoppen terwijl het veel gemakkelijker kan.

Een generieke collectie class die paging en lazy loading ondersteund is misschien niet zo'n goed idee. Beter is om dan bijvoorbeeld een class als ProductCatalogus de data source direct (expliciet dus) te vragen voor iedere benodigde page van producten.