DbDataReader reads all rows as empty from IEnumerable<object> about sylvan HOT 5 CLOSED

This is expected when the record type is Object. You'd just need to change the return type of GetRecords to pass through the testRecord type:

IEnumerable<testRecord> GetRecords()

This will then use the properties defined on the testRecord type, as expected.

from sylvan.

My context is I am implementing a WebAPI custom formatter to outpuit CSV, and I would love to make use of Sylvan's superior performance (vs. CsvHelper).

Microsoft's WriteResponseBodyAsync method gets an object, not a concrete type, and it isn't generic.
var type = context.ObjectType!; gets the System.Type, and context.Object provides the boxes object (which in my case can be cast to an IEnumerable, except the object is not known).

I do not know if it is practical to unbox an object with just its System.Type prior to passing it into Sylvan. JSON Serialization/deserialization will do it, but that's an ocean of overhead.
What are the chances that this could be enabled with an overload that accepts a System.Type, like Dapper's overload: connection.Query(type, sql, new { limit = 100 });, or would this defeat the purpose of Sylvan's performance optimizations?

using System.Collections;
using System.Text;
using Microsoft.AspNetCore.Mvc.Formatters;
using Sylvan.Data;
using Sylvan.Data.Csv;

namespace FastCoreLib.WebService.Formatters.Csv;

/// <inheritdoc />
public class CsvOutputFormatter : TextOutputFormatter
{
	/// <inheritdoc />
	public CsvOutputFormatter()
	{
		SupportedMediaTypes.Add(CsvFormatterConstants.MediaType);
		SupportedEncodings.Add(Encoding.ASCII);
		SupportedEncodings.Add(Encoding.UTF8);
	}

	/// <inheritdoc />
	protected override bool CanWriteType(Type? type)
		=> typeof(IEnumerable).IsAssignableFrom(type);

	/// <inheritdoc />
	public override async Task WriteResponseBodyAsync(OutputFormatterWriteContext context, Encoding selectedEncoding)
	{
		var recordReader = ((IEnumerable<object>)context.Object!).AsDataReader();
		var type = context.ObjectType!;

		using var stream = new MemoryStream();
		await using TextWriter textWriter = new StreamWriter(stream);
		await using var csvWriter = CsvDataWriter.Create(textWriter);

		await csvWriter.WriteAsync(recordReader);
		await textWriter.FlushAsync();

		var output = "??String";
		await context.HttpContext.Response.WriteAsync(output, selectedEncoding);
	}
}

CsvHelper can return data in such a case with similar code:

	public static byte[] ToCsv<T>(this IEnumerable<T> fastRows) where T : class, IFastRow
	{
		using var stream = new MemoryStream();
		using TextWriter textWriter = new StreamWriter(stream);
		using var csv = new CsvWriter(textWriter, CultureInfo.InvariantCulture);
		csv.WriteRecords(fastRows);
		textWriter.Flush();
		return stream.ToArray();
	}

from sylvan.

I might have already implemented what you're looking for in Sylvan.AspNetCore. It contains implementations of CSV/Excel aspnet MVC formatters.

The documentation is pretty limited, but you can add them to your application with the following line in your startup:

builder.Services.AddControllersWithViews(o => o.AddSylvanCsvFormatters());

Then, in your controller, you can define an action such as:

[Produces("text/csv")]
public object GetTest()
{
    return new[]
    {
        new {A =1,B="Jim"},
        new {A =2,B="Kim"}
    };            
}

Note, that there is no explicit T here. It returns object, and the element type is anonymous. When hitting ~/Home/GetTest, it would return a CSV.

A,B
1,Jim
2,Kim

The [Produces] attribute causes text/csv to be the default. If you omit it, this would serve JSON by default, and the client could use content-negotiation via the accepts HTTP header to request CSV instead, or even an Excel file if you also added the Sylvan.AspNetCore.Mvc.Excel package and registered the Excel formatter.

If my implementation doesn't do what you need, you can certainly use it as a reference. As this shows, it doesn't require an explicit type to be provided in order to function.

from sylvan.

That is... exactly what I was working on, but yours is better.
How do you feel about documentation contributions? No guarantees yet, but I feel as if Sylvan would be more used if its functionality was more easily discoverable. Its performance is clearly, clearly there. I'm posting about it at Reddit now. Thank you for your work and taking the time to reply!

from sylvan.

Any improvements to the documentation would certainly be welcome. Thanks for the shoutout on reddit.

from sylvan.