Efcore: Query: InMemory: Incorrect QueryModel coming from ReLinq for groupjoin scenarios

[anpete]

Started failing after 94a2d12b

[anpete]

This looks to be related to a re-linq issue. Following up with those folks.

[anpete]

Related re-linq issue: https://www.re-motion.org/jira/browse/RMLNQ-105

[azabluda]

It also fails if I replace Take with OfType
c# public virtual void GroupJoin_DefaultIfEmpty3() { AssertQuery<Customer, Order>((cs, os) => from c in cs.OfType<Customer>() // .Take(1) join o in os on c.CustomerID equals o.CustomerID into orders from o in orders.DefaultIfEmpty() select o); }
Do you think it makes sense to report my case separately or is it basically covered by #4311 / https://www.re-motion.org/jira/browse/RMLNQ-105 ?

[ajcvickers]

Based on comment on #7770 it looks like there is a new version of re-linq that we can use.

[ajcvickers]

@anpete Can you try the new version?

[smitpatel]

Another skipped test - GroupJoin_customers_orders_count_preserves_ordering

[smitpatel]

@MichaelKetting - I tested Remotion.Linq version 2.2.0-alpha-002 with current codebase of EF. Everything looks fine on our end. All existing test including the above failing tests pass successfully with pre-release version.

[MichaelKetting]

@smitpatel Thanks for testing this! I've got one or two more things I was hoping to get done before releasing v2.2 (https://www.re-motion.org/jira/browse/RMLNQ-25 and https://www.re-motion.org/jira/browse/RMLNQ-111). Am not sure yet regarding my available time but I'd like to wait one or two weekends before making that descision and see how it goes.

[anpete]

@MichaelKetting Thanks, btw we are hitting RMLNQ-111 and so it would great to get that in.

[MichaelKetting]

@anpete Thanks for letting me know re RMLNQ-111. Then that's defintiely going into the upcoming release.

[smitpatel]

@MichaelKetting - Hey any update/estimate on when version Re-Linq 2.2 will come out?

[MichaelKetting]

@smitpatel Yeah, sorry about that but I was (and am) completely swamped. I just checked my calender and there's a long weekend coming up in mid-June. I'll aim for that one :)

[smitpatel]

@ajcvickers - At present ReLinq 2.2 is still in alpha mode. And the 2 issues mentioned above by @MichaelKetting are not fixed yet. So it does not seem that 2.2 will be released before we ship 2.0.
Punt this one for 2.0?

[MichaelKetting]

@smitpatel When do you plan the v2.0 release? I'd really like to fix them but my available open source time this year has has taken a turn for the worse (as you might have noticed :/ ) thanks to a perfect storm of work-projects and getting settled after moving to a new place.

The alpha is just there until I release it. Should I not manage to get the fixes done, then v2.2 will be released as is, just need to know when.

Edit (this should come after @smitpatel's next comment regarding the code freeze but got lost in an accidental-post clean- up):
Torromow? Okay, sure. I can trigger a release build and just go with what's done right now. Just to make sure there's enough buffer and to keep following some semblance of a protocol: I can also move it up to just a release candidate and wait until you guys are ready with the release on your end, too, in case there's any last minute issues after this goes out to more users before the actual release happens? Not there's any real difference between a pre- and a post-release bugfix besides personal pride in one's work :)

[smitpatel]

@MichaelKetting - We plan to code freeze for v2.0 tomorrow. I understand there is not much time left for anymore fixes to be done on your end. I have tested version 2.2.0-alpha-002 which seems to fix all the tests disabled by this issue so releasing as-is would also work. If you are willing to release v2.2 for us, then we would be more than happy and update our dependency accordingly.

[smitpatel]

@ajcvickers @divega - to comment on timeline.

[smitpatel]

@michael-dlots @MichaelKetting - After discussion in team, we decided to hold back on this one for now. It is too late in release cycle to take newer version of dependency. Ideally, we would like to take newer version and release it with preview to be certain if nothing has regressed.

This would give you guys more time to work on fixes (or release rc version) before final release of 2.2.0. We would be looking at taking this in during our next preview release, which we will be working on after 2.0 RTM is released.

Thanks for all the help.

[MichaelKetting]

@smitpatel Ah, okay, you're still on re-linq v2.1.1 in the preview so it's not just a re-compile upgrade. Sure, I can see that that's too late in the game now.

Okay, I'll hold off on that one for now, then, just in case that I happen to find some spare time tucked away in a corner somewhere. Just let me know a couple of days in advance when you need the RTM drop and I'll cut a release. From re-linq perspective, it would certainly be okay for me when EF takes an alpha dependency during the preview.

Also, I'm very committed to semantic versioning in re-linq, so barring any bugs introduced by an alpha to be fixed in the next alpha, there should be no issues between different alpha-releases on a minor version and no breaking changes between minor versions.

[smitpatel]

@divega @ajcvickers - Pulling this out from backlog and upgrading to 2.2.0-alpha-002 version of ReLinq for our next preview so that we can verify reliability.