Hi, In 3.3.2, the following queries yield the same results: (1) session.Query<Foo>.Take(5).Where(...).OrderBy(...); (2) session.Query<Foo>.Where(...).OrderBy(...).Take(5);
Both queries will return the result that is natural for query 2. In the current 3.3.x branch the queries return different results. Due to PagingRewriter the semantics are more .Net-like instead of SQL, i.e. the position of Take() in relation to Where() now matters. Linq2Objects and Linq2EF already do this, so NHibernate is now closer to what seems to be the indented semantics. However, this could be a breaking change. The changes were introduced to resolve a number of issues related to WCF Data Services and other components that automatically generate LINQ queries, so it seems a shame to remove them completely. Related issues: https://nhibernate.jira.com/browse/NH-3108 https://nhibernate.jira.com/browse/NH-2588 https://nhibernate.jira.com/browse/NH-3320 https://nhibernate.jira.com/browse/NH-3326 Any suggestions? 1) Introduce temporary config variable so the new behavior must be explicitly activated (would be removed again in 4.0). It seems like it might be easy to just avoid using the PagingRewriter unless activated by configuration. Not sure how many other fixes might rely on this behavior. 2) Release as 3.4 and document as breaking change? We have made an effort to maintain compatibility, so it would be a bit sad. If we do got for this option, I still think we should do an immediate release, and explicitly not try to add other changes informally queued for a tentative 3.x release. Other options? /Oskar -- --- You received this message because you are subscribed to the Google Groups "nhibernate-development" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/groups/opt_out.
