Dapper orm Nicht schließen oracle nclob auf ungepufferten Stream .Query <T>

Question

Wir verwenden ein Orakel Nclob für eine der Spalten in unserer Datenbank, während eine "gepufferte: false" Auswahl von 8 Millionen Zeilen, die wir immer aus dem Speicher laufen würde .

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 
    } 
} 

Wir haben um diese von den Standard OracleDataReader verwenden und wenn wir die NCLOB wir wickelte es mit einer using-Anweisung zugreifen wollte. Wir möchten Dapper dafür verwenden, da dies die Konvertierung viel einfacher machen würde, aber an dieser Stelle nicht möglich ist.

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 
      } 
     } 
    } 
} 

Wir glauben, dass dies ein Fehler ist, aber gibt es etwas, das wir gerade vermissen?

Answer 1

Dapper versucht sehr, nicht viel über bestimmte Anbieter wissen zu müssen. Ich vermute, dass in Ihrem Fall ist es nur gleichwertig zu tun von:

obj.YourClobMember = reader.GetValue(8); 

Das Problem dabei ist, dass in der Tat, es wird nie von adrett entsorgt werden. Ich würde vorschlagen, dass in diesem Szenario, Ihre beste Wette wäre, eine Aufreinigungsmethode haben, die Sie von Ihrer Schleife aufrufen, die überprüft, ob das Clob-Mitglied nicht null ist, und wenn so disposes ist und weist es null zu. Dies könnte sogar sein, indem Sie Ihren Zeilentyp IDisposable machen.

Es könnte auch etwas möglich sein, das einen benutzerdefinierten Typ-Handler beinhaltet, aber die Tatsache, dass der offensichtliche Typ hier byte[] sein könnte, macht es umständlich, da das bereits eine harte Handhabung hat.