search

TurnerSoftware / MongoFramework

An "Entity Framework"-like interface for MongoDB
MIT License
388 stars 35 forks source link

Feature Request(s) #121

Open dthk-cogmatix opened 4 years ago

dthk-cogmatix commented 4 years ago

1) Is there any way to get a "single" change tracking entity rather than individual ones for each DBset?

2) Any issue having an implicit Update of entities when calling SaveChanges()?

2) What's the possibility of having even "simpler" API calls. Example would be like RavenDB where you have Typeless interactions. Deleting or Saving an entity would just be MyContext.Save(object) or MyContext.Delete(Object)

3) Any possibility moving away from MongoDBCollection interaction and focus more on the Entity? (Which is #2 ++ ).

Turnerj commented 4 years ago
  1. I can't remember which issue I noted it in but that is likely a potential outcome from other changes I want to do. This would both make it more like EntityFramework as well as simplify the responsibilities of MongoDbSet. One of the issues when I looked at this previously is how I have EntityCollection working - I would need an implementation working without generics. Its doable but would require twisting various other bits of code.
  2. Not entirely sure what you mean. Are you referring to entities updating the DB or the DB refreshing entities on save? Could you expand on this?
  3. My primary goal with MongoFramework is to make MongoDB feel like it was through EntityFramework while also specialising for use with MongoDB (queries, indexing and mapping - these would be hard to build well into the EntityFramework system). I'm not against other methods of interacting to MongoDB through MongoFramework core code though. If I was going to implement something like that, I'd probably split it into its own class outside of MongoDbContext or MongoDbSet as I see it as entirely its own thing.
  4. There are two main reasons I use EntityCollection as a core part of MongoFramework are to queue writes together allowing use of BulkWrite as well as tracking entity changes. Combined, these can save a large amount of overhead when communicating to MongoDB - these are two important aspects for me. My understanding of this question though might be flawed, especially if you are referring back to your 2nd point where I'm not entirely sure what you're referring to.

With each of these different points though - I couldn't commit to a time frame of when they would be worked on, if at all. However I am happy to keep discussing and planning different features, functionality and APIs.