Nous utilisons un oracle nclob pour l'une des colonnes de notre base de données, tout en effectuant une sélection "buffered: false" de 8 millions de lignes, nous manquerions toujours de mémoire.
using (var connection = new OracleConnection(_databaseConfiguration.ConnectionString))
{
connection.Open();
var result = connection.Query<ClassWithNClob>(query, param, buffered: false);
foreach (var element in result)
{
//do something with element that has a nclob
}
}
Nous avons contourné cela en utilisant OracleDataReader par défaut et lorsque nous voulions accéder au nclob, nous l'avons enveloppé avec une instruction using. Nous aimerions utiliser Dapper pour cela car cela rendrait la conversion beaucoup plus simple, mais ne le peut pas à ce stade.
using (var connection = new OracleConnection(_databaseConfiguration.ConnectionString))
{
connection.Open();
var command = new OracleCommand(query,connection);
using (OracleDataReader oraReader = oracleCommand.ExecuteReader())
{
while(oraReader.Read())
{
using(var blobStream = reader.GetOracleClob(2))
{
//something with bloblStream.Value
}
}
}
}
Nous pensons que c'est un bug, mais y a-t-il quelque chose qui nous manque?
Dapper essaie très fort de ne pas avoir besoin d'en savoir plus sur des fournisseurs spécifiques. Je soupçonne que dans votre cas, il ne fait que l'équivalent de:
obj.YourClobMember = reader.GetValue(8);
Le problème est qu’en fait, il ne sera jamais éliminé par Dapper. Je suggère que dans ce scénario , votre meilleur pari serait d'avoir une méthode de nettoyage que vous appelez depuis votre boucle , qui vérifie si le membre clob n'est pas nul, et si c'est le cas, il l'est et l'assigne à null. Cela pourrait même être en rendant votre type de ligne IDisposable
.
Il pourrait aussi y avoir quelque chose de possible impliquant un gestionnaire de type personnalisé, mais le fait que le type évident soit l' byte[]
rend mal à l'aise, car il possède déjà une gestion rigoureuse.