InMemoryDataContext should honor the Unit of Work and Commit design
DevlinLiles opened this issue · comments
Is this valuable? Most of the time, I would think you would be using the same data context when doing a unit of work, which means if you query twice, the entities have the same reference. Having the same reference means it is pointless to return what is truly in the data storage.
The only thing I can think of is for verification purposes for unit testing to see what the actual values are in the data storage.
Am I missing something here?
The wording is a bit odd, but what we want is to provide the same commit/rollback behavior of a RDBMS backed repository.
- If I make a bunch of object changes without a commit when I query again those changes are not there.
- If I add/remove an object, those changes do not change the asqueryable result until a commit is called.
Something like that.
Let me try again.
I don't think your first point can happen. I was uncertain so I tested it. The test I did was...query for an object, modify without committing, do that same query. The object from the 2nd query is the same object (same reference) so it has my modifications that I did from the first query.
My previous pull request covered your 2nd point. I can send you another pull request with some updates if you want this still. I haven't pushed it from my local yet.
I was thinking serialize the storage, and on query return the deserialized objects. Then on commit update the serialized version. Thoughts?
Sent from my Windows Phone
From: Long Maimailto:notifications@github.com
Sent: 4/6/2014 8:35 PM
To: HighwayFramework/Highway.Datamailto:Highway.Data@noreply.github.com
Cc: Devlin Lilesmailto:devlin@devlinliles.com
Subject: Re: [Highway.Data] InMemoryDataContext should honor the Unit of Work and Commit design (#57)
Let me try again.
I don't think your first point can happen. I was uncertain so I tested it. The test I did was...query for an object, modify without committing, do that same query. The object from the 2nd query is the same object (same reference) so it has my modifications that I did from the first query.
My previous pull request covered your 2nd point.
Reply to this email directly or view it on GitHub:
#57 (comment)
I think I know where the miscommunication is.
When I said "I don't think your first point can happen", I was talking about EF usage, not my implementation of InMemoryDataContext to get your first point to work. So what I was testing was how EF works, or at least EF w/ Highway.Data. If the scenario doesn't exist in actual EF w/ Highway.Data, then there isn't a point to do that. Can you reread last few comments with this thought in mind. I assume I cleared up the miscommunication.
Thanks!
Close as this is implemented through InMemoryActiveDataContext?
Implemented via the InMemoryActiveDataContext