Dapper.AOT Documentation

In dapperaot, operations involving a null literal do not always yield null. While most operations involving a null value (from a parameter or local variable) evaluate to null as expected, there are specific exceptions when using null literals directly in expressions.

Specifically, the following patterns involving null literals may yield results other than null:

• null >> 2 (Right shift with null literal)
• 2 >> null (Right shift with null literal)
• null & null (Bitwise AND with null literals, though this typically requires at least one operand to be something other than a 'hard' null to behave predictably).

Note: This behavior applies specifically to null literals. If a variable or parameter contains a null value, the expression will evaluate to null following standard expectations.

// Exceptions apply to literals:
var result1 = null >> 2;
var result2 = 2 >> null;
var result3 = null & null; // Note: behavior varies if operands are not 'hard' nulls

// Standard behavior applies to null values in variables:
int? myValue = null;
var result4 = myValue >> 2; // Evaluates to null

A RowFactory is responsible for converting a DbDataReader into your target object (e.g., a Product). It uses a two-step process to ensure high performance:

1. Tokenize: This runs once per result set. It inspects the columns returned by the database and identifies how to handle each. It generates a set of tokens that represent the mapping between database columns and object properties. For each column, it generates two paths: one for the ideal data type and one for type-flexible coercion.
2. Read: This runs once per row. It iterates through the columns using the tokens provided by Tokenize to efficiently populate the object's fields or properties using the DbDataReader.

// Example RowFactory structure
private sealed class RowFactory0 : global::Dapper.RowFactory<global::UsageLinker.Product>
{
    public override object? Tokenize(global::System.Data.Common.DbDataReader reader, global::System.Span<int> tokens, int columnOffset)
    {
        // Identifies column types and assigns tokens
    }

    public override global::UsageLinker.Product Read(global::System.Data.Common.DbDataReader reader, global::System.ReadOnlySpan<int> tokens, int columnOffset, object? state)
    {
        // Uses tokens to populate the Product object
    }
}

SQL variables have a scope that extends to "anywhere later in the code." This leads to two important behaviors:

1. No block-level re-declaration: You cannot re-declare a local variable inside a conditional branch (like an IF...ELSE block) if it would conflict with the outer scope or if you are attempting to create a scoped version of a variable.

2. Assignment vs. Declaration: While you cannot re-declare a variable inside a branch, you can assign a value to an existing variable declared earlier in the batch from within a branch.

Invalid: Re-declaring in branches

if -- some test
begin
    declare @id int
    -- more code
end
else
begin
    declare @id int
    -- more code
end

Valid: Assigning to a previously declared variable

declare @id int;

if -- some test
begin
    set @id = 1;
end
else
begin
    set @id = 2;
end

-- @id is accessible here as well
select @id;