16

I am working with Code First EntityFramework (version="6.1.0") and EntityFramework.Extended (version="6.1.0.96, the latest build at the moment from here.
The DbContext exposes the DbSets which are accessed like:

var set = ctx.Set<MyEntity>();

Today I decided to try Future Queries of the EntityFramework.Extended library, and ended pretty much soon, without an idea of how to proceed.

Here is the sample code:

using (var ctx = new MyDbContext())
{              
    var u = ctx.Set<User>().Future();
    var c = ctx.Set<Country>().Future();
    var users = u.ToList();
}

Regarding the Future() documentation I should get only one query to the DB which is what the Future() method provides. The query should be launched at u.ToList(); but what happens is that I get an error like this:

JIT Compiler encountered an internal limitation.

A stack trace dive tells me this:

at EntityFramework.Future.FutureQueryBase 1.GetResult()

at EntityFramework.Future.FutureQuery 1.GetEnumerator()

at System.Collections.Generic.List 1..ctor(IEnumerable 1 collection)

at System.Linq.Enumerable.ToList[TSource](IEnumerable 1 source)

at App.Program.Main(String[] args) in c:\Users\...\App\Program.cs:line 25

I really don't know what I'm missing out. I've checked that my ConnectionString has MultipleResultSets set to TRUE.
I've tested this with earlier build releases of EF.Exteneded but the same error occured.

Any idea would greatly help.

Community
  • 1
  • 1
Vedran Mandić
  • 1,084
  • 11
  • 21
  • 1
    seems to be related to http://stackoverflow.com/a/25007352/979477 – draeron Aug 09 '14 at 18:56
  • @draeron checked that out, but no progress, I will do check now, maybe after some updates progress was made... Thank you for the feedback. – Vedran Mandić Oct 06 '14 at 11:27
  • 1
    @VedranMandić I'm sure that you don't have this problem anymore, but: This error usually happens when JIT is compiling IL that is faulty in some was (bad types on the stack etc.). I'm not very familiar with EntityFramework.Extended but I would expect that it is doing exactly that. – Daniel Balas Apr 02 '15 at 22:46
  • did you try removing and re-adding EF via nuget. ? – phil soady Apr 26 '15 at 00:06
  • @philsoady yup, first thing I tried. I even tried older versions. Well, honestly I did not find time to test this, I really believe Daniel Balas was right with the previous comment. – Vedran Mandić Apr 27 '15 at 08:29
  • Did you look at this https://lostechies.com/jimmybogard/2014/03/11/efficient-querying-with-linq-automapper-and-future-queries/ – eugenekgn Apr 27 '15 at 16:32
  • Can you post codes of the `User` and `Country` classes as well? – Taher Rahgooy Aug 09 '15 at 12:10
  • @T.Rahgooy that's irrelevant, they're POCOs, i.e. take for e.g. a spec with 2 props like: int ID and string Name in both. – Vedran Mandić Aug 10 '15 at 20:04
  • 1
    I did test your code with simple POCOs that have Id and Name props , and there wasn't any problem. Did you tried to make a new project and test it from scratch? – Taher Rahgooy Aug 10 '15 at 20:15
  • 2
    Try Installing Entity Framework 6.1.3 – Ashraf Sada Sep 07 '15 at 12:27

2 Answers2

0

Could be wrong, but I think

ctx.Set<User>()

returns a DBSet whereas .Future() is supposed to be used at the end of queries. Maybe if you append .AsQueryable to the end of ctx.Set()?

ctx.Set<User>().AsQueryable().Future()

Also I think you can just use ctx.users if you have your EF database built that way.

Lenny K
  • 128
  • 12
  • I won't give -1 to this, but note this: 'public interface IDbSet : IQueryable, IEnumerable, IQueryable, IEnumerable where TEntity : class', so no need for AsQueryable(). Also, I cleaned my .tt file from generating named variables such as users, so ctx in this case dose not contain that, i.e. all DbSets (as that what they are) can be accessed over .Set. Thank you for the effort. – Vedran Mandić Sep 11 '15 at 19:16
0

So to add up after one year later; updated the Entity Framework to the latest version 6.1.3, installed the latest EntityFramework.Extended library, and one thing to note is I've used the 'Database first' approach for the test and all went OK. Could've been other strange stuff out of my control then.

Thanks everyone for the support on this one.

Vedran Mandić
  • 1,084
  • 11
  • 21