Class SQLiteSqlExpressionConvertVisitor
- Namespace
- LinqToDB.Internal.DataProvider.SQLite
- Assembly
- linq2db.dll
public class SQLiteSqlExpressionConvertVisitor : SqlExpressionConvertVisitor
- Inheritance
-
objectSQLiteSqlExpressionConvertVisitor
- Inherited Members
- Extension Methods
Constructors
SQLiteSqlExpressionConvertVisitor(bool)
public SQLiteSqlExpressionConvertVisitor(bool allowModify)
Parameters
allowModifybool
Properties
CanLowerIntervalDifference
Whether an elapsed date difference can be lowered to a value here.
public override bool CanLowerIntervalDifference { get; }
Property Value
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
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
Methods
ConvertConversion(SqlCastExpression)
Implements SqlCastExpression conversion.
protected override ISqlExpression ConvertConversion(SqlCastExpression cast)
Parameters
castSqlCastExpression
Returns
ConvertExprExprPredicate(ExprExpr)
public override IQueryElement ConvertExprExprPredicate(SqlPredicate.ExprExpr predicate)
Parameters
predicateSqlPredicate.ExprExpr
Returns
ConvertSearchStringPredicate(SearchString)
public override ISqlPredicate ConvertSearchStringPredicate(SqlPredicate.SearchString predicate)
Parameters
predicateSqlPredicate.SearchString
Returns
ConvertSqlBinaryExpression(SqlBinaryExpression)
public override IQueryElement ConvertSqlBinaryExpression(SqlBinaryExpression element)
Parameters
elementSqlBinaryExpression
Returns
ElapsedTicks(SqlIntervalDifferenceExpression)
Elapsed ticks from the Julian day difference, resolved to the millisecond.
protected override ISqlExpression? ElapsedTicks(SqlIntervalDifferenceExpression element)
Parameters
elementSqlIntervalDifferenceExpression
Returns
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.