Add Find method on DbSet

[kirthik]

In the old world, we have Find method on Dbset that is missing in the new world. It would be nice to have this in new EF world too.

[bricelam]

Note for triage: I'm marking this for re-triage since I'm seeing more and more people asking about this and we haven't done any work on the mitigation we once talked about in the early days of EF7.

[jasoncavett]

Is FindAsync also in the consideration here as well or is that a separate issue?

[divega]

@jasoncavett You can consider FindAsync() part of this issue.

[rowanmiller]

I've seen some good discussion and feedback on this on the ASP.NET Insiders mailing list. We should re-discuss and maybe pull it into RTM.

[tidusjar]

I would also like to add that I would like to see FindAsync() and Find() in EF7

[juniordevdenver]

I am also going to add that it would be nice to have Find() in EF7

[bricelam]

BTW, I have an answer on StackOverflow showing how you could write it yourself.

[juniordevdenver]

That is awesome. I am having a hard time trying to find where IAccessor is located. Any ideas?

[bricelam]

@sirpadington In namespace Microsoft.Data.Entity.Infrastructure.

[joeleesh]

@bricelam and @sirpadington do you find reference for IAccessor? I can not find on Microsoft.Data.Entity.Infrastructure?

[bricelam]

It was renamed to IInfrastructure<>.

[komengem]

What is the progress on this "Add Find method on DbSet #797"?

[vsg24]

God we need this so much.

[komengem]

Man, i was hoping we would get this in Update 2 👎

[ErikEJ]

@komengem did you have a look at: http://stackoverflow.com/questions/29030472/dbset-doesnt-have-a-find-method-in-ef7/29082410#29082410 ?

[sjb-sjb]

My question about implementing Find in EF7 is the efficiency. It's easy enough to take linear time to loop through the elements and find what you are looking for. But what I expect from Find is that it use the database indices to access the correct element (but without hitting the disk) in some reasonably fast manner like log n or better. If that is not what it does then I want a huge "use at your own risk" or disclaimer about the lack of efficiency in the documentation. Because, the reason I would look to Find in the first place is in the expectation that an in-memory search would be faster than a search to disk.

So, while I obviously appreciate @bricelam's code suggestions on StackOverflow, I wouldn't want the final StackOverflow solution to be the basis of the EF7 implementation (unless that solution does something that I don't know about :-).

[martinRocks]

If this is done, how do I use it. I have 1.0.0 of EF7 and I don't see the find method.

{
  "version": "1.0.0-*",

  "dependencies": {
    "Domain": "1.0.0-*",
    "Microsoft.EntityFrameworkCore": "1.0.0",
    "Microsoft.EntityFrameworkCore.SqlServer": "1.0.0",
    "Microsoft.EntityFrameworkCore.SqlServer.Design": {
      "version": "1.0.0",
      "type": "build"
    },
    "Microsoft.EntityFrameworkCore.Tools.Core": "1.0.0-rc2-final",
    "NETStandard.Library": "1.6.0"
  },

  "frameworks": {
    "netstandard1.6": {
      "imports": ["dotnet5.6","dnxcore50", "portable-net45+win8"]
    }
  }
}

[gdoron]

@martinRocks the milestone is 1.1.0

[rowanmiller]

You can try our nightly feeds, but they are unsupported and only really intended for trying out new features (not building production applications) https://www.myget.org/Gallery/aspnetcidev

[deepxg]

Quick question about the intended implementation, because a couple of people have posted the link to 'workarounds' on StackOverflow: will the final version maintain an identity map? Right now if you're in a loop, say, and do SingleOrDefault for the ID, adding the entity if it's not found, you will get duplicate key violations when you submit the changes to the database. Ideally, Find will be smart enough to return the new, unpersisted entity reference, instead of always hitting the database.

[ajcvickers]

Yes, Find uses an identity map. Yes, find will return the new, unpersisted entity.

[sjb-sjb]

I would like to reopen this discussion to ask for a version of Find that only looks in memory, and does not go to the database. The point is to use the EF indices to find the entry quickly, if it is in memory.

My use case is this: I have a variety of views with viewmodels that can reference overlapping data i.e. the same entity loaded through several contexts. I want to be able to switch back and forth between the views and have them all up to date. I have no desire to implement my own identity resolution so that the different views/viewmodels share entities (that they each have loaded using different DbContexts). Neither do I want to reload everything in a given view/viewmodel just because a user edit in some other view/viewmodel has changed one entity. So it seems unavoidable that I will have several copies of a given entity in memory, coming from different DbSets. What I would like to do is, when one of the in-memory entities is changed in one DbSet then I would like to Find the other in-memory copies in the other DbSets (associated with other views / viewmodels) and update them appropriately. Obviously in this situation, having Find hit the database would be counterproductive.

I realize that the philosophy is to dispose the context (and dbSets) after the unit of work is done -- perhaps right after the queries have finished. That doesn't make this problem go away, though. If you drop the context and the dbSets then it just entails that the duplicate entities are no longer associated with dbSets (which makes them even harder to Find :-)

[ajcvickers]

@sjb-sjb Covered by #7391

[sjb-sjb]

@ajcvickers thanks for this reference.

Do you have any general / high level comment on the overall goal of synchronizing multiple copies of an entity, which arises due to loading the entity multiple times through different contexts? I think this problem is inevitable when you have multiple views of the data, but is it really? I would like to know if I've just gotten lost in the rabbit hole. What is the usual way to deal with this?

All the best
sjb

P.s. If this is in fact a standard problem (inter-context identity resolution would be one way to describe it) then it would be nice to have a standard way of dealing with it.

[ajcvickers]

@sjb-sjb Keep it constrained. That is, for an arbitrary number of instances, each of which can have any changes to both scalar properties or relationships, and for which there can be new entities, deleted entities, modified entities, and unchanged entities, it is very hard to define what the "correct" behavior is, and hard to come up with rules that will cover all cases. On the other hand, if there are two instances, one is known not to change, and the other only has scalar changes, then the task is pretty easy. So, as much as possible, constraint where and how changes can be made so as to keep your rules for how to merge changes as simple as possible,

[sjb-sjb]

Thanks for the good advice. I think scalar properties and add / remove are enough. I plan to only change relationships by setting the reference Id, so that's a scalar property. Let's say I add a new child entity and set the parent id. I don't need to also explicitly create the relationship in the traversal collection, do I?

Since the changes are being made on the ui thread and will be immediately propagated to the other entities, there is no way to have conflicting changes in two copies of an entity.

What I realized is that one doesn't want to automatically replicate the changes made in one context in all the other contexts. Creating a relationship between two collections so that one of them picks up changes made in the other, should not be automatic but is an application decision. It should be part of the view model layer.

Obviously MS doesn't have this kind of thing today, for example this goes beyond the intended design of the Template 10 validation / view model system. (ref @JerryNixon) Is there any plan to do something like this in the future? A comprehensive view model system including cross-context synchronization primitives (and validation) would be great.

[boubaker-chieb]

Microsoft.Data.Entity.Infrastructure namespace is not found !

[sjb-sjb]

@ajcvickers, a followup on the use of Find in replicating changes from one context to another. My current thinking is to constrain the problem (as you suggest) by only replicating changes when a SaveChanges occurs. That is a lot simpler than the general problem. One can just use Find and/or GetDatabaseValues directly.