Release notes for re-motion version 1.13.13

List of Issues

Bugfixes

Improvements

Refactoring

New Features

Details

[COMMONS-1233] ResultModifications get lost when they are followed by additional method calls

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


(from s in ... select s).Take (1).Where (s != null)

This is because QueryParser.CreateClauseChain removes select clauses that are followed by other clauses without keeping their ResultModifications.

The solution would be to put all result modifications of the removed clauses into the ClauseGenerationContext and add their clones in ResultModificationExpressionNodeBase.GetSelectClauseForResultModification to the new select clause. The same must be done in QueryParser.GetOrCreateSelectClause.

Alternatively, change ResultModificationExpressionNodeBase.CreateClause to not create any Select clauses or ResultModifications, but instead add the nodes to the context. Then, after everything is done, the nodes could provide a CreateResultModification method to create all result modifications.

[COMMONS-1203] Change all expression tree visitors to ignore unknown nodes instead of throwing exceptions

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


This will make it much easier to deal with user-defined expression types.

[COMMONS-1178] Remove IClause.PreviousClause, JoinClause.FromClause, Ordering.OrderByClause, ResultModification.SelectClause; manage everything via collections only

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


This will make manipulation of the clause chain easier because clauses and QueryModel don't need to be kept in sync.

  • Remove PreviousClause properties and constructor arguments
  • Add public setters for MainFromClause and SelectOrGroupClause
  • Make BodyClauses a mutable list.
  • Clean up properties on QueryModel

[COMMONS-1176] Remove QueryModel.GetExpressionTree, the QueryModel should be decoupled from LINQ Expressions

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


GetExpressionTree is only used in error messages, and it causes lots of problems because it would have to be invalidated and recalculated every time the query model changes.

[COMMONS-1084] Consider reimplementing "previous clause" system so that the QueryModel sets previous clauses when a clause is added

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


This removes the "readonly" aspect of previous clauses, but it seems much more natural than having to always specify a previous clause when generating a new object.

[COMMONS-587] Find a way to cache tables per FromClauseBase so that the cache doesn't grow infinitely

Component/s: Data.Linq
Issue Type: Improvement
Resolution: Won't Fix yet
Status: Closed


(no description)

[COMMONS-1254] Refactor IExpressionNode.CreateClaus and CreateSelectClause: Replace by an Apply(QueryModel) mechanism

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


After COMMONS-1178, the CreateClause and CreateSelectClause, which were used to produce clause chains, don't fit very well. It would be better to unify the Apply concept already used for ResultModificationExpressionNodeBase to all nodes.

[COMMONS-1092] Refactor IQueryVisitor

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


  • Add VisitResultModification method
  • Rename IQueryVisitor to IQueryModelVisitor
  • Add a default implementation of IQueryModelVisitor (QueryModelVisitorBase) which automatically visits the ResultModifications/Orderings/JoinClauses collections