40

Closed

Support Read-Only Context or DbSet

description

It would be great to have a broader way to define no tracking contexts or no tracking DbSets so that we can design read-only models or DbSets. Yes we can control that in a repository but controlling it at the context or DbSet level would be simpler for devs to implement read-only data. It could also alleviate the problem of accidentally tracking data because you've set a navigation property. My pref would be to see this for a context. It would let you query but nothing else. Not sure how this will effect relationships via eager, lazy or explicit loading.
Closed Dec 5, 2016 at 11:31 PM by RoMiller
EF Team Triage: We are transitioning this project to GitHub (https://github.com/aspnet/EntityFramework6). As part of this transition we are bulk closing a large number of issues in order that our new issue tracker will accurately reflect the work that our team is planning to complete on the EF6.x code base.

Moving forwards, our team will be fixing bugs, implementing small improvements, and accepting community contributions to the EF6.x code base. Larger feature work and innovation will happen in the EF Core code base (https://github.com/aspnet/EntityFramework). Closing a feature request in the EF6.x project does not exclude us implementing the feature in EF Core. In fact, a number of popular feature requests for EF have already been implemented in EF Core (alternate keys, batching in SaveChanges, etc.).

This is a bulk message to indicate that this issue was closed and not ported to the new issue tracker. The reasons for not porting this particular issue to GitHub may include:
• It was a bug report that does not contain sufficient information for us to be able to reproduce it 
• It was a question, but sufficient time has passed that it's not clear that taking the time to answer it would provide value to the person who asked it 
• It is a feature request that we are realistically not going to implement on the EF6.x code base
Although this issue was not ported, you may still re-open it in the new issue tracker for our team to reconsider (https://github.com/aspnet/EntityFramework6/issues). We will no longer be monitoring this issue tracker for comments, so please do not reply here.

comments

AlirezaMaddah wrote Oct 19, 2012 at 6:44 PM

Two main data types could be added to the Entity Framework API; ReadOnlyDbSet<T> and ReadOnlyDbContext; We could already create a read-only repository to achieve this goal; But this would make it much more strict to define the read-only DbSets within the DbContext.

wardprogrammer wrote Oct 19, 2012 at 7:18 PM

Sounds Great! It would be really great to have such feature at DbSet level. I am excited to see what can be done for that. Thanks Julie.

RoMiller wrote Oct 23, 2012 at 11:17 PM

Hey,
Would it be fair to rename this issue to supporting read-only data at the context and DbSet level? This would include removing the overhead of tracking changes but still giving you things such as identity resolution that you don't get with NoTracking queries.
~Rowan

jlerman wrote Oct 24, 2012 at 1:03 AM

Rename sounds good to me. As long as you get the point and it sounds like you do. Thanks Rowan.

RoMiller wrote Oct 24, 2012 at 6:12 PM

Thanks Julie - I've renamed the bug. At this stage it's not something we're going to tackle in EF6, but we'll definitely consider it for a future release (and of course someone could always contribute it).

jlerman wrote Oct 24, 2012 at 7:46 PM

Just for clarification...even if we've removed "no tracking", one of the goals is to reduce the effort of creating the stateentry objects upon materialization. for the sake of identity management, I can imagine a class that is a stripped down version of state entry. But if we started dealing with identity, then relationships and then all of the relationship management would be involved as well. Just some thoughts for anyone who's interested in working on this.