DEV Community: Oleksandr Viktor

NPoco vs UkrGuru.Sql: When Streaming Beats Buffering

Oleksandr Viktor — Thu, 02 Apr 2026 18:29:25 +0000

When we talk about database performance in .NET, we often compare ORMs as if they were interchangeable. In practice, the API shape matters just as much as the implementation.

In this post, I benchmark NPoco and UkrGuru.Sql using BenchmarkDotNet, focusing on a very common task: reading a large table from SQL Server. The interesting part is not which library wins, but why the numbers differ so much.

TL;DR: Streaming rows with IAsyncEnumerable<T> is faster, allocates less, and scales better than loading everything into a list.

Test Scenario

The setup is intentionally simple and realistic.

Database: SQL Server
Table: Customers
Dataset: SampleStoreLarge (large enough to stress allocations)
Columns:
- CustomerId
- FullName
- Email
- CreatedAt

All benchmarks execute the same SQL:

SELECT CustomerId, FullName, Email, CreatedAt FROM Customers

No filters, no projections — just raw read performance.

Benchmark Code

using BenchmarkDotNet.Attributes;
using Microsoft.Data.SqlClient;
using NPoco;
using UkrGuru.Sql;

public class SqlBenchmark
{
    private const string ConnectionString =
        "Server=(local);Database=SampleStoreLarge;Trusted_Connection=True;TrustServerCertificate=True;";

    private const string CommandText =
        "SELECT CustomerId, FullName, Email, CreatedAt FROM Customers";

    [Benchmark]
    public async Task<int> NPoco_LoadList()
    {
        using var connection = new SqlConnection(ConnectionString);
        await connection.OpenAsync();

        using var db = new Database(connection);

        var list = await db.FetchAsync<Customer>(CommandText);
        return list.Count;
    }

    [Benchmark]
    public async Task<int> UkrGuru_LoadList()
    {
        await using var connection = await DbHelper.CreateConnectionAsync(ConnectionString);

        var list = await connection.ReadAsync<Customer>(CommandText);
        return list.Count();
    }

    [Benchmark]
    public async Task<int> UkrGuru_StreamRows()
    {
        int count = 0;

        await using var command = await DbHelper.CreateCommandAsync(
            CommandText,
            connectionString: ConnectionString);

        await foreach (var _ in command.ReadAsync<Customer>())
            count++;

        return count;
    }
}

All benchmarks were run in Release mode with BenchmarkDotNet.

Results (Execution Time)

Method	Mean	StdDev	Median
NPoco_LoadList	8.23 ms	0.33 ms	8.22 ms
UkrGuru_LoadList	5.30 ms	0.57 ms	5.34 ms
UkrGuru_StreamRows	3.29 ms	0.14 ms	3.22 ms

At first glance, streaming is already ~2.5× faster than NPoco. But the real story starts when we look at memory.

Results (Memory & GC)

Method	Gen0	Gen1	Gen2	Allocated
NPoco_LoadList	367	258	109	4.39 MB
UkrGuru_LoadList	203	188	70	2.33 MB
UkrGuru_StreamRows	164	–	–	2.08 MB

This table explains almost everything.

What’s Actually Being Measured?

NPoco_LoadList

Uses FetchAsync<T>()
Fully materializes a List<Customer>
Allocates buffers and intermediate objects

✅ Idiomatic NPoco usage

❌ No streaming support

NPoco optimizes for developer productivity, not minimal allocations. That’s a valid trade‑off, but it shows up clearly in GC pressure.

UkrGuru_LoadList

Also builds a full list
Uses a leaner mapping pipeline
Roughly half the allocations of NPoco

✅ Same algorithm as NPoco

✅ Less overhead

This is a fair apple‑to‑apple comparison with NPoco’s approach.

UkrGuru_StreamRows

Uses IAsyncEnumerable<T>
Processes rows one at a time
No list allocation
No Gen2 collections

✅ True async streaming

✅ Lowest latency

✅ Most stable GC behavior

This is not a micro‑optimization — it’s a different execution model.

Why Streaming Wins

The biggest improvement is not raw speed — it’s memory behavior.

Fewer allocations
Almost no object promotion
No Gen2 collections

That matters a lot under real load: ASP.NET requests, background workers, message consumers, etc.

Streaming doesn’t just run faster — it scales better.

About Fairness

This benchmark is not trying to prove that one ORM is “better” than another.

It compares three distinct patterns:

Buffered list materialization (NPoco)
Buffered list materialization with fewer abstractions
True async streaming

Comparing streaming to buffering is not “ORM vs ORM” — it’s algorithm vs algorithm.

When Should You Use Each?

Use NPoco when:

You want simple, expressive data access
Loading lists is acceptable
Developer time matters more than raw throughput

Use streaming (e.g. UkrGuru.Sql) when:

Result sets are large
Latency and GC pressure matter
You want full control over execution

Final Thoughts

Benchmarks don’t just measure libraries — they measure abstractions and APIs.

If your workload is dominated by large reads, switching from buffered lists to async streaming can cut both execution time and memory pressure dramatically.

Choose the tool that matches your data access pattern, not just the one you’re used to.

🚀 Simplify ADO.NET Stream Rows ...

Oleksandr Viktor — Wed, 01 Apr 2026 10:04:53 +0000

SqlLoadListBenchmark – Simple ADO.NET vs UkrGuru.Sql Demo

This demo shows how ADO.NET and UkrGuru.Sql perform the same work using different coding styles, along with benchmark results.

🖼 1. LoadList Demo (ADO.NET vs UkrGuru)

ADO.NET_LoadList

public async Task<int> ADONET_LoadList()
{
    var list = new List<Customer>();
    using var conn = new SqlConnection(ConnectionString);
    await conn.OpenAsync();
    using var cmd = new SqlCommand(CommandText, conn);
    using var reader = await cmd.ExecuteReaderAsync();

    while (await reader.ReadAsync())
    {
        list.Add(new Customer
        {
            CustomerId = reader.GetInt32(0),
            FullName   = reader.GetString(1),
            Email      = reader.GetString(2),
            CreatedAt  = reader.GetDateTime(3)
        });
    }

    return list.Count;
}

UkrGuru_LoadList

public async Task<int> UkrGuru_LoadList()
{
    await using var connection = await DbHelper.CreateConnectionAsync(ConnectionString);
    var list = await connection.ReadAsync<Customer>(CommandText);
    return list.Count();
}

🖼 2. StreamRows Demo (ADO.NET vs UkrGuru)

ADO.NET_StreamRows

public async Task<int> ADONET_StreamRows()
{
    int count = 0;
    await foreach (var row in StreamCustomersAsync())
        count++;

    return count;

    async IAsyncEnumerable<Customer> StreamCustomersAsync(
        [EnumeratorCancellation] CancellationToken cancellationToken = default)
    {
        using var conn = new SqlConnection(ConnectionString);
        await conn.OpenAsync(cancellationToken);
        using var cmd = new SqlCommand(CommandText, conn);
        using var reader = await cmd.ExecuteReaderAsync(
            System.Data.CommandBehavior.SequentialAccess, cancellationToken);

        while (await reader.ReadAsync(cancellationToken))
        {
            yield return new Customer
            {
                CustomerId = reader.GetInt32(0),
                FullName   = reader.GetString(1),
                Email      = reader.GetString(2),
                CreatedAt  = reader.GetDateTime(3)
            };
        }
    }
}

UkrGuru_StreamRows

public async Task<int> UkrGuru_StreamRows()
{
    int count = 0;
    await using var command =
        await DbHelper.CreateCommandAsync(CommandText, connectionString: ConnectionString);

    await foreach (var item in command.ReadAsync<Customer>())
        count++;

    return count;
}

📊 Benchmark Results

Method	Mean	Error	StdDev
ADONET_StreamRows	2.953 ms	0.0472 ms	0.0441 ms
UkrGuru_StreamRows	3.141 ms	0.0415 ms	0.0407 ms
ADONET_LoadList	4.309 ms	0.0721 ms	0.0675 ms
UkrGuru_LoadList	4.713 ms	0.0908 ms	0.1116 ms

📝 Summary

StreamRows: Both are fast; ADO.NET is slightly faster in this raw sequential benchmark.
LoadList: UkrGuru.Sql is a bit slower in this scenario but provides much cleaner code with far less boilerplate.
Code simplicity vs raw speed:
- ADO.NET = faster, more verbose
- UkrGuru.Sql = cleaner, safer, more maintainable Check it out 👇

🔗 https://github.com/UkrGuru/Sql/tree/main/demos/SqlLoadListBenchmark

UkrGuru vs Microsoft Copilot: Benchmark Results That Speak for Themselves

Oleksandr Viktor — Wed, 25 Mar 2026 14:05:13 +0000

UkrGuru vs Microsoft Copilot: Benchmark Results That Speak for Themselves

When you optimize for real‑world performance, microseconds matter — sometimes nanoseconds matter.

This benchmark compares UkrGuru implementations with Microsoft Copilot‑generated equivalents across common low-level operations: primitives, arrays, serialization, and structs.

The results were surprising — especially considering that Copilot code tends to follow “safe defaults,” while UkrGuru focuses heavily on allocation‑free, branch‑minimal, CPU‑friendly implementation patterns.

This article summarizes the benchmark results and provides a downloadable table for transparency.

📊 Benchmark Summary

The table below shows Mean execution time, Error, StdDev, Rank, and Memory Allocation.

Lower Mean and Rank are better.

Lower Allocated (ideally 0 bytes) is also better.

| Method        | Mean        | Error      | StdDev    | Rank | Gen0   | Allocated |
|-------------- |------------:|-----------:|----------:|-----:|-------:|----------:|
| Ukr_Bool      |   0.9436 ns |  0.0552 ns | 0.0030 ns |    2 |      - |         - |
| Cop_Bool      |   5.5047 ns |  0.2465 ns | 0.0135 ns |    4 |      - |         - |
| Ukr_Int       |   5.4953 ns |  0.6840 ns | 0.0375 ns |    4 |      - |         - |
| Cop_Int       |  12.9375 ns |  0.1144 ns | 0.0063 ns |    8 |      - |         - |
| Ukr_Double    |  23.5338 ns |  0.9775 ns | 0.0536 ns |   13 |      - |         - |
| Cop_Double    |  22.5574 ns |  1.4858 ns | 0.0814 ns |   12 |      - |         - |
| Ukr_Decimal   |  29.7762 ns |  0.9910 ns | 0.0543 ns |   15 |      - |         - |
| Cop_Decimal   |  30.6302 ns |  2.3973 ns | 0.1314 ns |   16 |      - |         - |
| Ukr_Guid      |  12.7784 ns |  0.3671 ns | 0.0201 ns |    7 |      - |         - |
| Cop_Guid      |  12.1073 ns |  1.8873 ns | 0.1035 ns |    6 |      - |         - |
| Ukr_DateOnly  |  52.5456 ns |  2.6977 ns | 0.1479 ns |   17 |      - |         - |
| Cop_DateOnly  |  57.3368 ns |  2.9485 ns | 0.1616 ns |   18 | 0.0036 |      48 B |
| Ukr_TimeOnly  | 109.1004 ns |  1.9878 ns | 0.1090 ns |   20 |      - |         - |
| Cop_TimeOnly  | 119.5629 ns | 10.2523 ns | 0.5620 ns |   21 | 0.0041 |      56 B |
| Ukr_TimeSpan  |  52.4028 ns |  1.9116 ns | 0.1048 ns |   17 |      - |         - |
| Cop_TimeSpan  |  62.9908 ns | 15.9374 ns | 0.8736 ns |   19 | 0.0030 |      40 B |
| Ukr_ByteArray |  15.5711 ns |  0.7072 ns | 0.0388 ns |    9 | 0.0055 |      72 B |
| Cop_ByteArray |  15.7549 ns |  0.7830 ns | 0.0429 ns |   10 | 0.0055 |      72 B |
| Ukr_CharArray |   0.9538 ns |  0.3159 ns | 0.0173 ns |    3 |      - |         - |
| Cop_CharArray |   0.8838 ns |  0.1034 ns | 0.0057 ns |    1 |      - |         - |
| Ukr_Serialize |   5.6374 ns |  0.6384 ns | 0.0350 ns |    5 | 0.0043 |      56 B |
| Cop_Serialize |  12.0702 ns |  0.5457 ns | 0.0299 ns |    6 | 0.0067 |      88 B |
| Ukr_Enum      |  24.4368 ns |  2.8392 ns | 0.1556 ns |   14 | 0.0018 |      24 B |
| Cop_Enum      |  21.3234 ns |  1.0134 ns | 0.0555 ns |   11 | 0.0043 |      56 B |

🔥 Key Observations

1. UkrGuru wins most primitive operations

Especially in:

Bool
Int
Decimal
TimeSpan

These results highlight extremely efficient, allocation‑free handling of simple .NET types.

2. Copilot sometimes wins — but only occasionally

There are categories where Copilot’s code came out slightly ahead (e.g., CharArray).

This is good — benchmarks should challenge both sides.

It makes the overall results more meaningful.

3. Memory allocations reveal the biggest gap

In several operations, Copilot-generated code allocates:

48 B in DateOnly
56 B in TimeOnly
40 B in TimeSpan
88 B in Serialize
56 B in Enum conversions

Meanwhile, most UkrGuru methods remain 0‑allocation, which is critical for:

high-throughput APIs
microservices
real-time pipelines
game loops
tight CPU‑bound workloads

🤖 Why Copilot Can’t Keep Up

Microsoft Copilot is great at generating safe general-purpose code, but not specialized for:

nanosecond‑level optimization
allocation‑free pipelines
branch elimination
struct‑level micro-optimizations
IL-friendly patterns

That’s exactly where UkrGuru excels — handcrafted low-level performance-oriented code.

🏁 Conclusion

This benchmark doesn’t say “Copilot is bad.”

It simply shows that generic AI-generated code cannot outperform hand‑tuned, purpose-built UkrGuru implementations.

If your application needs maximum performance with minimal allocations — UkrGuru wins.

📦 Want to reproduce the benchmark?

Full source code, including benchmark classes and configuration, is available here:

👉 https://github.com/UkrGuru/Sql/tree/main/dev/ResultsBench/ResultsBench

updated for WJb 0.25.0-beta

Oleksandr Viktor — Tue, 13 Jan 2026 05:53:17 +0000

Basics (Getting Started) with WJb

Oleksandr Viktor ・ Dec 17 '25

#programming #webdev #ai

https://github.com/UkrGuru/Sql - simple and the best

Oleksandr Viktor — Wed, 08 Oct 2025 19:51:55 +0000

GitHub - UkrGuru/Sql

Contribute to UkrGuru/Sql development by creating an account on GitHub.

github.com

Try UkrGuru.Sql with New Optimized `Results.Parse`

Oleksandr Viktor — Thu, 29 May 2025 05:55:41 +0000

Here’s a short article with the requested title:

Try UkrGuru.Sql with New Optimized `Results.Parse`

The latest release of UkrGuru.Sql introduces a powerful enhancement: an optimized Results.Parse method designed to streamline how developers handle SQL query results in .NET applications.

🚀 What’s New?

The new Results.Parse method significantly improves performance and usability by:

Faster parsing of SQL result sets into .NET objects
Reduced memory footprint for large datasets
Improved error handling and type safety
Simplified syntax for cleaner, more maintainable code

📊 Benchmark Results

Method	Mean	Error	StdDev	Gen0	Allocated
ResultsNew_ToStr	541.0 ns	66.87 ns	3.67 ns	0.0830	1096 B
ResultsOld_ToStr	2,195.4 ns	177.93 ns	9.75 ns	0.1411	1872 B
ResultsNew_FromStr	1,021.9 ns	85.43 ns	4.68 ns	0.0629	840 B
ResultsOld_FromStr	1,521.0 ns	166.13 ns	9.11 ns	0.0515	696 B

These results show a clear performance gain in both serialization and deserialization with the new implementation.

private static readonly object?[] _oInputs =
[
    null,
    DBNull.Value,
    false,
    true,
    byte.MaxValue,
    short.MaxValue,
    int.MaxValue,
    long.MaxValue,
    float.MaxValue,
    double.MaxValue,
    decimal.MaxValue,
    DateOnly.MaxValue,
    DateTime.MaxValue,
    DateTimeOffset.MaxValue,
    TimeOnly.MaxValue,
    TimeSpan.MaxValue,
    Guid.Empty,
    'A',
    "AV & ASD",
    Encoding.UTF8.GetBytes("AV & ASD"),
    new char[] { 'A', 'V', '&', 'A', 'S', 'D' },
    TestEnum.One,
    //new string[] { "A", "V", "&", "A", "S", "D" },
    //new NamedType { Id = 1, Name = "Test" }
];

[Benchmark]
public object?[] ResultsNew_ToStr()
{
    object?[] values = new object?[_oInputs.Length];

    for (var i = 0; i < values.Length; i++)
    {
        values[i] = ResultsNew.Parse<string?>(_oInputs[i]);
        //Console.WriteLine(values[i]);
    }

    return values;
}


[Benchmark]
public object?[] ResultsNew_FromStr()
{
    var index = 0;
    object?[] values = new object?[_sInputs.Length];

    values[index++] = ResultsNew.Parse<bool?>(_sInputs[0]); // null
    values[index++] = ResultsNew.Parse<bool>(_sInputs[1]); // false
    values[index++] = ResultsNew.Parse<bool>(_sInputs[2]); // true
    values[index++] = ResultsNew.Parse<byte>(_sInputs[3]); // byte
    values[index++] = ResultsNew.Parse<short>(_sInputs[4]); // short
    values[index++] = ResultsNew.Parse<int>(_sInputs[5]); // int
    values[index++] = ResultsNew.Parse<long>(_sInputs[6]); // long
    values[index++] = ResultsNew.Parse<float>(_sInputs[7]); // float
    index++; //values[index++] = ResultsNew.Parse<double>(_sInputs[8]); // double
    values[index++] = ResultsNew.Parse<decimal>(_sInputs[9]); // decimal
    values[index++] = ResultsNew.Parse<DateOnly>(_sInputs[10]); // DateOnly
    values[index++] = ResultsNew.Parse<DateTime>(_sInputs[11]); // DateTime
    values[index++] = ResultsNew.Parse<DateTimeOffset>(_sInputs[12]); // DateTime
    values[index++] = ResultsNew.Parse<TimeOnly>(_sInputs[13]); // TimeOnly
    values[index++] = ResultsNew.Parse<TimeSpan>(_sInputs[14]); // TimeOnly
    values[index++] = ResultsNew.Parse<Guid>(_sInputs[15]); // Guid
    values[index++] = ResultsNew.Parse<char>(_sInputs[16]); // char
    values[index++] = ResultsNew.Parse<string>(_sInputs[17]); // string
    values[index++] = ResultsNew.Parse<byte[]>(_sInputs[18]); // byte[]
    values[index++] = ResultsNew.Parse<char[]>(_sInputs[19]); // char[]
    values[index++] = ResultsNew.Parse<TestEnum>(_sInputs[20]); // enum
    //values[index++] = ResultsNew.Parse<string[]>(_sInputs[21]); // string[]
    //values[index++] = ResultsNew.Parse<NamedType>(_sInputs[22]);

    //for (var i = 0; i < values.Length; i++)
    //{
    //    Console.WriteLine(values[i]);
    //}

    return values;
}

🛠️ Why It Matters

Whether you're building APIs, background services, or data-driven applications, the optimized Results.Parse helps you:

Minimize boilerplate code
Improve application responsiveness
Focus more on business logic and less on data plumbing

📦 Ready to Explore?

Check out the package on NuGet and start building smarter, faster, and cleaner SQL-powered .NET apps today.

Would you like this article formatted for a blog post, social media, or a README file?

Insider Info About the New Results Class in Benchmark

Oleksandr Viktor — Sun, 23 Feb 2025 18:51:07 +0000

Insider Info About the New Results Class in Benchmark

The world of performance benchmarking is always evolving, and recent updates to the Sql repository by UkrGuru have introduced an exciting new Results class in the BenchResults namespace. This article dives into the details of this new implementation, comparing it to its predecessor, and showcasing the performance improvements it brings to the table. Let’s explore what’s under the hood, based on the latest insights from the Program.cs file in the benchmark suite.

Benchmark Setup

The benchmarks were run using BenchmarkDotNet v0.14.0 on the following system:

OS: Windows 11 (10.0.26100.3194)
CPU: 12th Gen Intel Core i7-12700K (1 CPU, 20 logical and 12 physical cores)
.NET SDK: 9.0.200
Runtime: .NET 9.0.2 (9.0.225.6610), X64 RyuJIT AVX2 [AttachedDebugger]
Job: ShortRun (IterationCount=3, LaunchCount=1, WarmupCount=3)

This setup ensures a modern, high-performance environment to test the new Results class against the older ParseOld implementation.

The Results: Old vs. New

The benchmark compares two methods: ParseOld_40_results (the legacy approach) and ResultsNew_40_results (the new implementation). Here’s how they stack up:

Method	Mean	Error	StdDev	Gen0	Allocated
ParseOld_40_results	2.056 μs	0.1926 μs	0.0106 μs	0.1450	1.86 KB
ResultsNew_40_results	1.056 μs	0.0520 μs	0.0028 μs	0.0973	1.25 KB

Key Takeaways

Performance Boost:

The new ResultsNew_40_results method clocks in at a mean execution time of 1.056 microseconds, a remarkable improvement over the older ParseOld_40_results method’s 2.056 microseconds. That’s nearly a 50% reduction in execution time!
Stability:

The new implementation shows significantly lower variability, with an error of 0.0520 μs and a standard deviation of 0.0028 μs, compared to 0.1926 μs and 0.0106 μs for the old method. This suggests the new class is not only faster but also more consistent.
Memory Efficiency:

Memory usage sees a notable improvement as well. The ResultsNew_40_results method allocates just 1.25 KB with a Gen0 collection rate of 0.0973, down from 1.86 KB and 0.1450 in the old method. This reduction in memory footprint could be a game-changer for large-scale applications.

What’s Driving the Improvement?

While the exact implementation details of the Results class aren’t fully exposed in the benchmark file, the numbers hint at some clever optimizations. Likely candidates include:

Optimized Parsing Logic: The new class may employ a more efficient algorithm for handling the 40 results, reducing computational overhead.
Reduced Object Overhead: The drop in memory allocation suggests fewer temporary objects or a more streamlined data structure.
Better Use of .NET 9 Features: Running on .NET 9.0.2 with RyuJIT AVX2, the new class might leverage modern runtime enhancements for better performance.

For a deeper dive into the code, check out the source file directly.

Why It Matters

For developers working with the Sql library, this upgrade could mean faster query result processing and lower resource consumption—crucial for high-performance applications. Whether you’re building a data-intensive service or optimizing an existing system, the new Results class offers a compelling reason to update.

Conclusion

The introduction of the Results class in UkrGuru’s Sql repository marks a significant leap forward in performance and efficiency. With a near 50% reduction in execution time, improved stability, and a lighter memory footprint, it’s clear that this isn’t just a minor tweak—it’s a reimagining of how results are handled. Keep an eye on this project as it continues to evolve, and consider integrating these improvements into your own workflows.

How Grok 3 and xUnit Tests Helped Craft an Ideal `Results` Class

Oleksandr Viktor — Thu, 20 Feb 2025 11:06:38 +0000

In the world of software development, creating robust, reliable code is both an art and a science. For Oleksandr Viktor (UkrGuru), a passionate developer whose life revolves around programming, this pursuit led to an impressive collaboration with Grok 3—an AI assistant from xAI—and the power of xUnit testing. Together, they transformed an initial open-source Results class into a near-perfect utility for parsing data, now battle-tested and ready for developers everywhere.

The Starting Point

The journey began with an open-source Results class, available at https://github.com/UkrGuru/Sql/blob/main/src/Results.cs. Designed as part of the UkrGuru.Sql project, this class aimed to parse various data types—primitives, enums, JSON elements, and more—into a target type T. While functional, it had room for improvement, particularly in handling edge cases like char[] conversions and enum parsing.

Enter Grok 3 and xUnit

Oleksandr enlisted Grok 3 to rigorously evaluate the Results class, leveraging its ability to analyze code and suggest improvements. Paired with xUnit—a popular .NET testing framework—the duo embarked on a marathon of test-driven refinement. Grok 3 generated dozens of tests targeting potential weaknesses: type safety, null handling, JSON parsing quirks, enum edge cases, and overflow scenarios. Each test aimed to expose flaws, but Oleksandr’s code proved resilient, passing challenge after challenge with strategic fixes.

Key Fixes That Made It Ideal

Two standout improvements emerged from this process:

char[] Handling:
- Initial Code: char[] chars => (T)(object)new string(chars)
- Problem: This threw InvalidCastException for non-string targets (e.g., double), limiting flexibility.
- Fix: char[] chars => (T)Convert.ChangeType(new string(chars), typeof(T))
- Result: Using Convert.ChangeType, the code now converts char[] to a wide range of types (e.g., "123" to 123.0 for double), throwing appropriate exceptions only when truly invalid—enhancing type safety and versatility.

Enum Parsing:

Initial Code: Type t when t.IsEnum => (T)Enum.Parse(t, value.ToString()!)
Problem: Threw generic ArgumentException for invalid values, lacking specificity.
Fix:

 Type t when t.IsEnum => (T?)(Enum.TryParse(t, Convert.ToString(value), out object? result) && Enum.IsDefined(t, result)
         ? result : throw new ArgumentException($"'{value}' is not a valid value for enum {t.Name}"))

Result: Now uses TryParse with IsDefined for robust parsing, throwing a custom, informative exception (e.g., "'3' is not a valid value for enum TestEnum")—improving error clarity and reliability.

The Power of Collaboration

Grok 3’s relentless test generation—spanning malformed JSON, negative TimeSpan values, overflow conditions, and more—pushed Oleksandr to refine his code iteratively. xUnit tests provided the proving ground, ensuring each fix held up under scrutiny. Oleksandr’s insight—that .NET 9’s default strict JSON parsing (throwing JsonException for invalid data like "not-a-number")—explained the class’s strict behavior without needing explicit options, sealing its perfection.

Why Developers Should Use It

The resulting Results class is a gem for .NET developers:

Versatility: Handles primitives, enums, JSON, and char[] with ease.
Robustness: Throws specific exceptions for invalid inputs, aligning with a fail-fast philosophy.
Simplicity: Clean, concise switch expressions make it maintainable.
Open Source: Freely available at GitHub—fork it, use it, improve it!

Whether you’re parsing database results, JSON payloads, or custom inputs, this class—forged through Grok 3’s AI-driven testing and Oleksandr’s expertise—offers a reliable, battle-tested solution. Developers seeking a parsing utility that balances flexibility with strictness should give it a spin—it’s as close to ideal as code gets!

UkrGuru.Sql: Additional Features Under the Hood

Oleksandr Viktor — Mon, 17 Feb 2025 14:19:55 +0000

UkrGuru.Sql: Additional Features Under the Hood

In this article, we will explore the powerful features of the UkrGuru.Sql library, focusing on its versatile Results class. This class provides robust parsing capabilities for various data types, making it an essential tool for developers. Let's dive into some practical examples to demonstrate its functionality.

Demonstrating Results class methods:

using System;
using System.Text.Json;
using UkrGuru.Sql;

Console.WriteLine("Demonstrating Results class methods:");

// Parsing null values
Console.WriteLine("Parse Null Values:");
Console.WriteLine($"Nullable bool: {Results.Parse<bool?>(null) == null}");
Console.WriteLine($"Non-nullable bool (default false): {Results.Parse<bool>(null)}");

Output:

Parse Null Values:
Nullable bool: True
Non-nullable bool (default false): False

This demonstrates how the Results class handles null values, providing default values for non-nullable types and correctly identifying nullable types as null.

// Parsing integers
object bigInt = 1234567890123456789L;
Console.WriteLine("\nParse BigInt:");
Console.WriteLine($"Parsed long: {Results.Parse<long>(bigInt)}");
Console.WriteLine($"Parsed long from string: {Results.Parse<long>(bigInt.ToString())}");

Output:

Parse BigInt:
Parsed long: 1234567890123456789
Parsed long from string: 1234567890123456789

This shows the Results class's ability to parse large integers both directly and from their string representations, ensuring accurate conversion.

// Parsing strings
object str = "Test";
Console.WriteLine("\nParse String:");
Console.WriteLine($"Parsed string: {Results.Parse<string>(str)}");

Output:

Parse String:
Parsed string: Test

Here, the Results class successfully parses a simple string, demonstrating its straightforward handling of string data types.

// Parsing DateTime
object dateTime = new DateTime(2000, 1, 1, 1, 1, 1);
Console.WriteLine("\nParse DateTime:");
Console.WriteLine($"Parsed DateTime: {Results.Parse<DateTime>(dateTime)}");
Console.WriteLine($"Parsed DateTime from string: {Results.Parse<DateTime>(dateTime.ToString())}");

Output:

Parse DateTime:
Parsed DateTime: 01/01/2000 01:01:01
Parsed DateTime from string: 01/01/2000 01:01:01

This example highlights the Results class's capability to parse DateTime objects both directly and from formatted strings, ensuring precise date and time handling.

// Parsing DateOnly
object dateOnly = DateOnly.FromDateTime(DateTime.Now);
Console.WriteLine("\nParse DateOnly:");
Console.WriteLine($"Parsed DateOnly: {Results.Parse<DateOnly>(dateOnly)}");
Console.WriteLine($"Parsed DateOnly from string: {Results.Parse<DateOnly>(dateOnly.ToString())}");

Output:

Parse DateOnly:
Parsed DateOnly: 17/02/2025
Parsed DateOnly from string: 17/02/2025

This demonstrates the Results class's ability to handle DateOnly types, parsing both directly and from string representations, which is useful for date-specific applications.

// Parsing TimeOnly
object timeOnly = TimeOnly.FromDateTime(DateTime.Now);
Console.WriteLine("\nParse TimeOnly:");
Console.WriteLine($"Parsed TimeOnly: {Results.Parse<TimeOnly>(timeOnly)}");
Console.WriteLine($"Parsed TimeOnly from string: {Results.Parse<TimeOnly>(timeOnly.ToString())}");

Output:

Parse TimeOnly:
Parsed TimeOnly: 14:28
Parsed TimeOnly from string: 14:28

This example shows how the Results class can parse TimeOnly types, both directly and from formatted strings, making it ideal for time-specific data.

// Parsing char[]
object charArray = new char[] { 'A', 'B' };
Console.WriteLine("\nParse char[]:");
Console.WriteLine($"Parsed char[]: {new string(Results.Parse<char[]>(charArray))}");
Console.WriteLine($"Parsed char[] from string: {new string(Results.Parse<char[]>(new string(charArray)))}");

Output:

Parse char[]:
Parsed char[]: AB
Parsed char[] from string: AB

This demonstrates the Results class's ability to parse character arrays, both directly and from their string representations, ensuring accurate character data handling.

// Parsing byte[]
object byteArray = new byte[] { 1, 2, 3 };
Console.WriteLine("\nParse byte[]:");
Console.WriteLine($"Parsed byte[]: {BitConverter.ToString(Results.Parse<byte[]>(byteArray)!)}");
Console.WriteLine($"Parsed byte[] from Base64 string: {BitConverter.ToString(Results.Parse<byte[]>(Convert.ToBase64String(byteArray))!)}");

Output:

Parse byte[]:
Parsed byte[]: 01-02-03
Parsed byte[] from Base64 string: 01-02-03

This example highlights the Results class's capability to parse byte arrays, both directly and from Base64-encoded strings, which is essential for binary data handling.

// Parsing Guid
object guid = Guid.NewGuid();
Console.WriteLine("\nParse Guid:");
Console.WriteLine($"Parsed Guid: {Results.Parse<Guid>(guid)}");
Console.WriteLine($"Parsed Guid from string: {Results.Parse<Guid>(guid.ToString())}");

Output:

Parse Guid:
Parsed Guid: 7ffaa01a-18c8-48e7-9d9b-7de755ebb370
Parsed Guid from string: 7ffaa01a-18c8-48e7-9d9b-7de755ebb370

This demonstrates the Results class's ability to handle Guid types, parsing both directly and from string representations, ensuring unique identifier management.

// Parsing JSON
object json = JsonSerializer.Serialize(new { Id = 1, Name = "Test" });
var parsedObject = Results.Parse<JsonElement>(json);
Console.WriteLine("\nParse JSON:");
Console.WriteLine($"Parsed JSON Id: {parsedObject.GetProperty("Id").GetInt32()}");
Console.WriteLine($"Parsed JSON Name: {parsedObject.GetProperty("Name").GetString()}");

Output:

Parse JSON:
Parsed JSON Id: 1
Parsed JSON Name: Test

This example shows the Results class's capability to parse JSON data, extracting properties from a JsonElement, which is crucial for handling structured data.

Conclusion

The Results class from the UkrGuru.Sql library offers a wide range of parsing capabilities, making it a valuable tool for developers working with diverse data types. Whether you need to parse null values, integers, strings, dates, times, character arrays, byte arrays, GUIDs, or JSON, the Results class has you covered. This demonstration highlights the versatility and power of the Results class, showcasing its ability to handle various parsing scenarios with ease.

UkrGuru.Sql: Minimal Effort, Maximum Results!

Oleksandr Viktor — Thu, 13 Feb 2025 10:31:27 +0000

Hey everyone, check out the new open-source UkrGuru.Sql package! It's a powerful library designed to simplify interactions between .NET applications and SQL Server databases.

Key Features

Ease of Use: Simplifies database operations with minimal code.
Flexibility: Supports various SQL operations and data types.
Performance: Optimized for efficient database interactions.

Example Usage

Here's a quick example to demonstrate how easy it is to use UkrGuru.Sql:

using UkrGuru.Sql;

// Set the connection string
DbHelper.ConnectionString = "Server=(localdb)\\mssqllocaldb";

// Execute a simple query
var result = DbHelper.Exec<int>("SELECT @A + @B", new { A = 2, B = 2 });
Console.WriteLine($"Result: {result}");

// Work with JSON data
var person = new { Id = 1, Name = "John" };
var json = DbHelper.Exec<string>("SELECT @Data", person.ToJson());
Console.WriteLine($"Result: {json}");

// Read multiple records
var persons = DbHelper.Read<Person>("SELECT 1 Id, 'John' Name UNION ALL SELECT 2 Id, 'Mike' Name").ToList();
Console.WriteLine($"Result: {persons.Count}");
Console.WriteLine($"1st person: {persons[0].ToJson()}");
Console.WriteLine($"2nd person: {persons[1].ToJson()}");

// Define the Person class
class Person
{
    public int? Id { get; set; }
    public string? Name { get; set; }
}

Why Choose UkrGuru.Sql?

Open Source: Free to use and modify.
Community Support: Join a growing community of developers.
Documentation: Comprehensive guides and examples.

Give UkrGuru.Sql a try and see how it can streamline your database interactions!

UkrGuru.Sql: Quiz

Oleksandr Viktor — Mon, 10 Feb 2025 23:35:11 +0000

Q1: Result: 22 or 4 or other?

Experiment with a universal CRUD API using UkrGuru.Sql

Oleksandr Viktor — Mon, 13 Jan 2025 21:09:53 +0000

In this article, we'll walk through the process of creating a universal CRUD API using ASP.NET Core and UkrGuru.Sql. This API will support various HTTP methods to execute stored procedures, making it a versatile tool for database interactions.

Setting Up the Project

First, let's set up our ASP.NET Core project. We'll start by creating a new Web Application project:

dotnet new webapi -n ApiProject
cd ApiProject

Adding Dependencies

Next, we'll add the necessary dependencies to our project. We'll use UkrGuru.Sql for database interactions and Microsoft.AspNetCore.Mvc for building our API.

using Microsoft.AspNetCore.Mvc;
using UkrGuru.Sql;

Defining Constants

We'll define constants for our API pattern and suffix:

const string ApiHolePattern = "ApiHole";
const string ApiProcSufix = "_Api";

Configuring Services

We'll configure the services in the Program.cs file. This includes registering the database service with dependency injection and adding controllers with a custom input formatter for plain text.

var builder = WebApplication.CreateBuilder(args);

builder.Services.AddScoped<IDbService, DbService>();
builder.Services.AddControllers();
builder.Services.AddOpenApi();

Adding Configuration Settings

We'll add the following configuration settings to the appsettings.json file to set up logging and the database connection:

{
  "Logging": {
    "LogLevel": {
      "Default": "Information",
      "Microsoft.AspNetCore": "Warning",
      "UkrGuru.SqlJson": "Information"
    }
  },
  "AllowedHosts": "*",
  "ConnectionStrings": {
    "DefaultConnection": "Server=(localdb)\\mssqllocaldb;Integrated Security=true;Database=Northwind;"
  }
}

Building the Application

Next, we'll build the application and configure the HTTP request pipeline for the development environment. We'll also enforce HTTPS redirection.

var app = builder.Build();

if (app.Environment.IsDevelopment())
{
    app.MapOpenApi();
}

app.UseHttpsRedirection();

Mapping Endpoints

We'll map the endpoints for executing stored procedures using various HTTP methods (POST, GET, PUT, DELETE).

app.MapPost($"{ApiHolePattern}/{{proc}}", async (IDbService db, string proc, [FromBody] object? data) =>
    await db.TryExecAsync<string?>($"{proc}{ApiProcSufix}", data?.ToJson()));

app.MapGet($"{ApiHolePattern}/{{proc}}", async (IDbService db, string proc, string? data) =>
    await db.TryExecAsync<string?>($"{proc}{ApiProcSufix}", data));

app.MapPut($"{ApiHolePattern}/{{proc}}", async (IDbService db, string proc, [FromBody] object? data) =>
    await db.TryExecAsync($"{proc}{ApiProcSufix}", data?.ToJson()));

app.MapDelete($"{ApiHolePattern}/{{proc}}", async (IDbService db, string proc, string? data) =>
    await db.TryExecAsync($"{proc}{ApiProcSufix}", data));

Running the Application

Finally, we'll run the application:

app.Run();

Setting Up the Database

To set up the database, use the following T-SQL script to create the stored procedures:

SET ANSI_NULLS ON
GO
SET QUOTED_IDENTIFIER ON
GO
CREATE PROCEDURE [dbo].[Shippers_Del_Api]
    @Data nvarchar(50)
AS
DELETE Shippers 
WHERE CompanyName = @Data
GO

CREATE PROCEDURE [dbo].[Shippers_Get_Api]
    @Data nvarchar(50)
AS
SELECT *
FROM Shippers 
WHERE CompanyName = @Data
FOR JSON PATH, WITHOUT_ARRAY_WRAPPER
GO

CREATE PROCEDURE [dbo].[Shippers_Ins_Api]
    @Data nvarchar(max)
AS
INSERT INTO Shippers (CompanyName, Phone)
OUTPUT inserted.ShipperID
SELECT CompanyName, Phone 
FROM OPENJSON(@Data) 
    WITH (CompanyName nvarchar(40), Phone nvarchar(24))
GO

CREATE PROCEDURE [dbo].[Shippers_Upd_Api]
    @Data nvarchar(max)
AS
UPDATE Shippers
SET Phone = D.Phone
FROM OPENJSON(@Data) 
    WITH (CompanyName nvarchar(40), Phone nvarchar(24)) D
WHERE Shippers.CompanyName = D.CompanyName
GO

MinSqlApi.http File

To test the API, you can use the following MinSqlApi.http file. This file contains HTTP requests for executing stored procedures using different HTTP methods.

@MinSqlApi_HostAddress = http://localhost:5133

### POST request to execute a stored procedure
POST {{MinSqlApi_HostAddress}}/ApiHole/Shippers_Ins
Content-Type: application/json

{ 
  "CompanyName":"Nova Poshta",  
  "Phone":"(800) 111-1111" 
}

### GET request to execute a stored procedure
GET {{MinSqlApi_HostAddress}}/ApiHole/Shippers_Get?data=Nova%20Poshta

### PUT request to execute a stored procedure
PUT {{MinSqlApi_HostAddress}}/ApiHole/Shippers_Upd
Content-Type: application/json

{ 
  "CompanyName":"Nova Poshta",  
  "Phone":"(800) 222-2222" 
}

### DELETE request to execute a stored procedure
DELETE {{MinSqlApi_HostAddress}}/ApiHole/Shippers_Del?data=Nova%20Poshta

Conclusion

By following these steps, you've created a versatile API that can handle various HTTP methods to execute stored procedures. This setup provides a solid foundation for building more complex and feature-rich APIs in the future.

For more details, you can check the source code here.
https://github.com/UkrGuru/Sql/blob/main/demos/MinSqlApi/MinSqlApi/Program.cs

UkrGuru.Sql package here
https://www.nuget.org/packages/UkrGuru.Sql/

DEV Community: Oleksandr Viktor

NPoco vs UkrGuru.Sql: When Streaming Beats Buffering

Test Scenario

Benchmark Code

Results (Execution Time)

Results (Memory & GC)

What’s Actually Being Measured?

NPoco_LoadList

UkrGuru_LoadList

UkrGuru_StreamRows

Why Streaming Wins

About Fairness

When Should You Use Each?

Final Thoughts

🚀 Simplify ADO.NET Stream Rows ...

SqlLoadListBenchmark – Simple ADO.NET vs UkrGuru.Sql Demo

🖼 1. LoadList Demo (ADO.NET vs UkrGuru)

ADO.NET_LoadList

UkrGuru_LoadList

🖼 2. StreamRows Demo (ADO.NET vs UkrGuru)

ADO.NET_StreamRows

UkrGuru_StreamRows

📊 Benchmark Results

📝 Summary

UkrGuru vs Microsoft Copilot: Benchmark Results That Speak for Themselves

UkrGuru vs Microsoft Copilot: Benchmark Results That Speak for Themselves

📊 Benchmark Summary

🔥 Key Observations

1. UkrGuru wins most primitive operations

2. Copilot sometimes wins — but only occasionally

3. Memory allocations reveal the biggest gap

🤖 Why Copilot Can’t Keep Up

🏁 Conclusion

📦 Want to reproduce the benchmark?

updated for WJb 0.25.0-beta

Basics (Getting Started) with WJb

Oleksandr Viktor ・ Dec 17 '25

https://github.com/UkrGuru/Sql - simple and the best

GitHub - UkrGuru/Sql

Try UkrGuru.Sql with New Optimized `Results.Parse`

Try UkrGuru.Sql with New Optimized Results.Parse

🚀 What’s New?

📊 Benchmark Results

🛠️ Why It Matters

📦 Ready to Explore?

Insider Info About the New Results Class in Benchmark

Insider Info About the New Results Class in Benchmark

Benchmark Setup

The Results: Old vs. New

Key Takeaways

What’s Driving the Improvement?

Why It Matters

Conclusion

How Grok 3 and xUnit Tests Helped Craft an Ideal `Results` Class

The Starting Point

Enter Grok 3 and xUnit

Key Fixes That Made It Ideal

The Power of Collaboration

Why Developers Should Use It

UkrGuru.Sql: Additional Features Under the Hood

UkrGuru.Sql: Additional Features Under the Hood

Demonstrating Results class methods:

Conclusion

UkrGuru.Sql: Minimal Effort, Maximum Results!

Key Features

Example Usage

Why Choose UkrGuru.Sql?

UkrGuru.Sql: Quiz

Experiment with a universal CRUD API using UkrGuru.Sql

Setting Up the Project

Adding Dependencies

Defining Constants

Configuring Services

Adding Configuration Settings

Building the Application

Mapping Endpoints

Running the Application

Setting Up the Database

MinSqlApi.http File

Conclusion

Try UkrGuru.Sql with New Optimized `Results.Parse`