Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

InMemory provider queries on tracked entities (unlike SQLServer provider) #12945

Closed
wizofaus opened this issue Aug 9, 2018 · 7 comments
Closed
Assignees
Labels
area-in-memory area-query closed-fixed The issue has been fixed and is/will be included in the release indicated by the issue milestone. customer-reported punted-for-3.0 type-bug
Milestone

Comments

@wizofaus
Copy link

wizofaus commented Aug 9, 2018

With the InMemory provider, if you modify the value of an entity returned by EF, then immediately query on it, the query successfully finds the entity.
However when using SQLServer it doesn't, as the change hasn't been committed to the database yet.

E.g.

 class MyContext : DbContext
 {
       internal DbSet<MyObject> Objects { get; set; }

       void Foo()
       {
              Objects.FirstOrDefault().Value = 42;
              Console.WriteLine($"Found: {Objects.FirstOrDefault(o => o.Value == 42) != null}");
       }
 }

Assuming your database contains at least one Object with a value field not equal to 42, then using InMemory, this prints out "Found: true", but using SQLServer, prints out "Found: false".

Adding "SaveChanges();" before performing the query causes the behaviour to be the same, but as it is this discrepancy hid a rather nasty bug in my server that didn't show up in any of the automated testing.

@ghost
Copy link

ghost commented Aug 9, 2018

I've noticed the same thing with DB generated fields (i.e. Id's generated by a sequence). With In Memory they get set right away, with Sql Server the only get set on SaveChanges. I also had a nasty bug where I left a SaveChanges out and it passed tests and failed when switching to the real backend

@wizofaus
Copy link
Author

wizofaus commented Aug 9, 2018

There's at least 3 different ways in which In-Memory provider works differently to the SQL-server provider. I'm happy to contribute a fix if there's nobody else working on it.

@ErikEJ
Copy link
Contributor

ErikEJ commented Aug 9, 2018

@ajcvickers
Copy link
Member

Note for triage: I was able to reproduce the case above. It looks like the in-memory query provider is doing identity resolution to the tracked entity before evaluating the predicate.

@david-waterworth @wizofaus The in-memory database will never behave exactly like SQL Server, or indeed any other relational database. However, we are tracking some issues to add additional functionality--for example, #6872

@wizofaus
Copy link
Author

wizofaus commented Aug 9, 2018

Sure, I'd never expect it to behave exactly the same, and indeed previous In-Memory DbSet libraries for EF 6 (.net Framework) had the same problem (or even worse - no distinction at all between tracked entity data and persisted data). But the fact that "real" databases query against the underlying data rather than current tracked entities would seem to be a useful behaviour to emulate.

@wizofaus wizofaus changed the title InMemory provider doesn't work the same way SQLServer InMemory provider doesn't work the same as SQLServer Aug 9, 2018
@wizofaus wizofaus changed the title InMemory provider doesn't work the same as SQLServer InMemory provider queries on tracked entities (unlike SQLServer provider) Aug 9, 2018
@ajcvickers
Copy link
Member

@wizofaus The case you reported above is a bug. In-memory queries are made against the in-memory database, not the tracked entity instances.

@smitpatel
Copy link
Contributor

InMemory is working same as SqlServer in 3.1 release. We don't track against tracked entities anymore.

@smitpatel smitpatel removed this from the Backlog milestone Dec 7, 2019
@smitpatel smitpatel added this to the 3.1.0 milestone Dec 7, 2019
@smitpatel smitpatel added closed-fixed The issue has been fixed and is/will be included in the release indicated by the issue milestone. and removed try-on-latest labels Dec 7, 2019
@smitpatel smitpatel self-assigned this Dec 7, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area-in-memory area-query closed-fixed The issue has been fixed and is/will be included in the release indicated by the issue milestone. customer-reported punted-for-3.0 type-bug
Projects
None yet
Development

No branches or pull requests

5 participants