Table of Contents

Class SQLiteSqlExpressionConvertVisitor

Namespace
LinqToDB.Internal.DataProvider.SQLite
Assembly
linq2db.dll
public class SQLiteSqlExpressionConvertVisitor : SqlExpressionConvertVisitor
Inheritance
object
SQLiteSqlExpressionConvertVisitor
Inherited Members
Extension Methods

Constructors

SQLiteSqlExpressionConvertVisitor(bool)

public SQLiteSqlExpressionConvertVisitor(bool allowModify)

Parameters

allowModify bool

Properties

CanLowerIntervalDifference

Whether an elapsed date difference can be lowered to a value here.

public override bool CanLowerIntervalDifference { get; }

Property Value

bool

Remarks

Declared beside the lowering it describes, and read by the member translator through ITranslationContext.ProviderFlags. The translator has to ask before it builds anything, because a difference it does not build stays an ordinary .NET subtraction and is computed on materialisation - and by the time this visitor runs, the read expression is already bound to its columns, so there is no going back.

ConcatRequiresExplicitStringCast

When true (default), ConvertConcat(SqlConcatExpression) wraps every non-string operand in an explicit CAST(... AS VARCHAR(N)) before adding it to the concat chain. Required for providers whose concat operator is + (SQL Server pre-2025, SqlCe, Access) — SQL-standard data-type precedence would otherwise try to coerce string operands to the non-string side's type. Most providers whose final concat operator is || (PostgreSQL / Oracle / SQLite / SAP HANA / DuckDB / Firebird / DB2 / Informix / SQL Server 2025+) or CONCAT(...) function (MySQL / ClickHouse) auto-coerce non-string operands and override this to false for cleaner SQL. Sybase ASE is the exception: it emits || but keeps this true, since ASE requires an explicit convert() for non-character operands under both + and ||.

protected override bool ConcatRequiresExplicitStringCast { get; }

Property Value

bool

IntervalResolution

julianday returns a double, and a Julian day number today is around 2460000 - so one unit in the last place is about 47 microseconds. The millisecond is the finest quantum that survives that, whatever the column holds.

public override SqlIntervalUnit IntervalResolution { get; }

Property Value

SqlIntervalUnit

Methods

ConvertConversion(SqlCastExpression)

Implements SqlCastExpression conversion.

protected override ISqlExpression ConvertConversion(SqlCastExpression cast)

Parameters

cast SqlCastExpression

Returns

ISqlExpression

ConvertExprExprPredicate(ExprExpr)

public override IQueryElement ConvertExprExprPredicate(SqlPredicate.ExprExpr predicate)

Parameters

predicate SqlPredicate.ExprExpr

Returns

IQueryElement

ConvertSearchStringPredicate(SearchString)

public override ISqlPredicate ConvertSearchStringPredicate(SqlPredicate.SearchString predicate)

Parameters

predicate SqlPredicate.SearchString

Returns

ISqlPredicate

ConvertSqlBinaryExpression(SqlBinaryExpression)

public override IQueryElement ConvertSqlBinaryExpression(SqlBinaryExpression element)

Parameters

element SqlBinaryExpression

Returns

IQueryElement

ElapsedTicks(SqlIntervalDifferenceExpression)

Elapsed ticks from the Julian day difference, resolved to the millisecond.

protected override ISqlExpression? ElapsedTicks(SqlIntervalDifferenceExpression element)

Parameters

element SqlIntervalDifferenceExpression

Returns

ISqlExpression

Remarks

SQLite has no date type: values are text, and julianday is the only way to do arithmetic on them. It returns a double whose spacing at present-day dates is around fifty microseconds, so the millisecond it is rounded to is the finest unit that comes back exact - and it is also the resolution SQLite date arithmetic already works at, since strftime's %f emits three fractional digits and AddTicks has always lost anything below that.

Rounding rather than truncating for the same reason: the true value is a whole number of milliseconds, and the error is far below half of one, so the nearest is the exact one.