Release notes for re-motion version 1.13.56

List of Issues

Bugfixes

Breaking Changes

Improvements

New Features

Details

[COMMONS-2582] Support for empty collections

Component/s: Data.Linq
Issue Type: Bug
Resolution: Fixed
Status: Closed


(no description)

[COMMONS-2610] Old SQL backend has been replaced by a new one

Component/s: Data.Linq
Issue Type: Breaking Change
Resolution: Fixed
Status: Closed


The old backend has been completely rewritten. It is now in the namespace Remotion.Data.Linq.SqlBackend in Remotion.Data.Linq.SqlBackend.dll.

Use it as follows:

  • Parse the QueryModel into a SqlStatement using DefaultSqlPreparationStage.PrepareSqlStatement.
  • Resolve the SqlStatement using DefaultMappingResolutionStage.ResolveSqlStatement. Implement the IMappingResolver interface for your O/R mapper. See https://svn.re-motion.org/svn/Remotion/trunk/Remotion/Data/DomainObjects/Linq/MappingResolver.cs for an example of how to implement IMappingResolver.
  • Generate text for the resolved SqlStatement using DefaultSqlGenerationStage.GenerateTextForStatement.

All three stages are completely replaceable and extensible.

[COMMONS-2619] For Single queries, emit TOP (2) instead of TOP (1)

Component/s: Data.Linq
Issue Type: Improvement
Resolution: Fixed
Status: Closed


Single should throw an exception when more than one result is returned. We currently emit TOP (1) for Single queries, which will swallow this exception.

[COMMONS-2445] re-store integration for new re-linq SQL backend

Component/s: Data.Linq
Issue Type: Improvement
Resolution: Fixed
Status: Closed


With the new SQL backend, re-store's LINQ provider gets a more extensible and more complete LINQ provider.

[COMMONS-2617] Support subqueries that return a single entity to be used for comparisons and similar contexts

Component/s: Data.Linq
Issue Type: New Feature
Resolution: Fixed
Status: Closed


Support for queries similar to the following:

from c in Cooks where c == (from k in Kitchens select k.Cook).First () select c.ID

In the generated SQL, the ID of the inner cook is compared to the ID of the outer cook.

[COMMONS-2592] Support for the simple form of explicit joins without "into"

Component/s: Data.Linq
Issue Type: New Feature
Resolution: Fixed
Status: Closed


Support queries of the following form: from c in Cooks join k in Kitchens on k.ID = c.KitchenID select c

This produces an old-style SQL join similar to the following: SELECT ... FROM [CookTable] [c] CROSS JOIN [KitchenTable] [k] WHERE [c].[KitchenID] = [k].[ID]. Note that this has inner join semantics, i.e., it will not produce any results if there are no kitchens matching the cook.

[COMMONS-2587] Support for conditional operator in non-entity scenarios

Component/s: Data.Linq
Issue Type: New Feature
Resolution: Fixed
Status: Closed


Support conditions of the following forms: c != null ? c.FirstName : c.LastName, c.FirstName != null ? c.FirstName : c.LastName.

A SQL CASE WHEN expression is emitted to implement the conditional operator.

[COMMONS-2556] Support for OfType result operator and "is" comparisons

Component/s: Data.Linq
Issue Type: New Feature
Resolution: Fixed
Status: Closed


Support for expressions of the forms: (from fsi in FileSystemItem select fsi).OfType<File>(), from folder in Folder from file in folder.Items.OfType<File>() select file, where fsi is File.

The SQL generated for such expressions contains a WHERE condition that restricts the set of items to those of the desired type. The concrete condition depends on the O/R mapper.

[COMMONS-2313] New Sql Backend

Component/s: Data.Linq
Issue Type: New Feature
Resolution: Fixed
Status: Closed


The new SQL backend should both be a good example of how to approach SQL generation using the new re-linq front-end (QueryModel, usw.) and provide a sound, extensible architecture backing re-store's LINQ provider.

It will sport SQL generation in three phases:

  • The first phase will take a query model and translate it into a SqlStatement model. SqlStatement is modeled to express the syntactical possibilities and constraints of actual SQL statements.
  • The second phase will allow an O/R mapper to resolve all elements of the SqlStatement into SQL-specific items such as tables or columns with names and aliases.
  • The third phase will then take the resolved SqlStatement and produce actual SQL text (and parameters).

LINQ providers will be able to hook into each of the three steps for customization, optimization, and advanced query transformations.

[COMMONS-2446] Extensibility hooks

Component/s: Data.Linq
Issue Type: Sub-task
Resolution: Fixed
Status: Closed


  • SQL statement preparation, resolution, and text generation occurs in three stages, each of which is completely replaceable by the provider.
  • The default stage implementations use virtual methods, allowing providers to override parts of each single stage.
  • The overall SQL structure can be modified by overriding the Build... (BuildSelectPart, BuilderWherePart, etc.) methods of SqlStatementTextGenerator.
  • The provider can insert SqlCustomTextExpressions into the LINQ expression tree to emit simple, custom SQL text.
  • The provider can derive from SqlCustomTextGeneratorExpressionBase and insert instances of the derived class into the LINQ expression tree in order to emit complex, custom SQL text.
  • The provider can use SqlCompositeExpression to build complex structures of custom SQL text mixed with standard expression types.
  • The instance of ISqlCommandBuilder used for constructing the SQL text (Append, AppendFormat, AppendEscapedIdentifier, etc.) can be replaced by the provider.

[COMMONS-2370] Support for incompatible result operators using subqueries

Component/s: Data.Linq
Issue Type: Sub-task
Resolution: Fixed
Status: Closed


Result operator combinations such as (...).Take(5).Distinct(), cannot be solved using a single SQL statement (because SELECT DISTINCT TOP (5) has different semantics). Instead, a subquery needs to be generated to perform the TOP operator, then the outer query can apply the DISTINCT logic.