2009-01-22 5 views
0

J'écris une application qui doit périodiquement (chaque semaine par exemple) parcourir plusieurs millions d'enregistrements dans une base de données et exécuter du code sur les résultats de chaque ligne.Lazy Reads dans Castle.ActiveRecord

Depuis la table est si grande, je soupçonne que lorsque j'appelle SomeObject.FindAll() il lit toutes les 1,4millions de rangées et essaie de retourner toutes les lignes dans un SomeObject [].

Existe-t-il un moyen d'exécuter une expression SomeObject.FindAll(), mais de charger les valeurs de manière plus conviviale avec le SGBD?

Répondre

0

Pas avec FindAll() - ce qui, comme vous l'avez supposé, va essayer de charger toutes les instances du type spécifié à la fois (et, selon la façon dont vous avez configuré NHibernate, peut générer un nombre prodigieux de SQL requêtes pour le faire).

chargement Lazy ne fonctionne que sur les propriétés des objets, donc par exemple si vous aviez un type persistant SomeObjectContainer qui avait comme propriété une liste de SomeObject cartographié de telle sorte qu'il doit correspondre à tous les SomeObject s et avec lazy="true", puis a fait Sur cette propriété de liste, vous obtiendrez ce que vous voulez, sorte-de; Par défaut, NHibernate émet une requête pour chaque élément de la liste, en n'en chargeant qu'un seul à la fois. Bien sûr, le cache de lecture deviendrait gigantesque, donc vous auriez probablement besoin de vider beaucoup. Ce que vous pouvez faire est de lancer une requête HQL (ou même Embedded SQL) pour récupérer tous les ID de tous les objets SomeObjects, puis de parcourir les ID un par un en récupérant l'objet correspondant à l'aide de FindByPrimaryKey. Encore une fois, ce n'est pas particulièrement élégant. Pour être honnête, dans une telle situation, je devrais probablement transformer cela en un travail de maintenance planifiée dans un proc stocké - sauf si vous devez vraiment exécuter code sur l'objet plutôt que de manipuler les données en quelque sorte. Cela pourrait déranger les puristes d'objets, mais parfois un proc stocké est la bonne façon de procéder, en particulier dans ce genre de scénario de travail par lots.