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

Tracking does not work when using context.Update() #4

Closed
thoraj opened this issue May 7, 2018 · 5 comments
Closed

Tracking does not work when using context.Update() #4

thoraj opened this issue May 7, 2018 · 5 comments
Assignees
Labels

Comments

@thoraj
Copy link

thoraj commented May 7, 2018

EF Core contexts support an Update method which will update an entity if it exist.
When using context.Update(), the columns for tracking CreatorUserId and CreatedUTC are reset.

Is this a known problem?
If so, is this something that is on the roadmap to fix?

@gnaeus
Copy link
Owner

gnaeus commented May 8, 2018

@thoraj, can you give an example of your scenario? I don't understand what do you mean.

Suppose we have an entity Post with CreatorUserId and CreatedUtc properties.
If we call context.Update(post), the following SQL will be generated during SaveChanges:

UPDATE Posts
SET CreatorUserId = @p0,
    CreatedUtc = @p1
    ...
WHERE Id = @p2;

But we get same SQL if we manually owerwrite post.CreatedUtc = new DateTime(2018, 1, 1);

If we load Post from database, the CreatedUtc property already contains a date. Then context.Update marks all properties as changed. And UPDATE statement doesn't really change it's value.

CreatedUtc and CreatorUserId will be erased in DB only if we have detached entity with empty CreatedUtc and CreatorUserId fields. And then we call context.Update() on it. Is this your scenario?

@thoraj
Copy link
Author

thoraj commented May 8, 2018

Yes, that is my scenario.

I have a modified (detached) entity, and I wish to either create a new if it does not exist, or update if it exists. I'm trying to use EF Core tracking instead of doing manual diffs myself.

The code in question looks like this:

            // check if entity exist
            var existingObservation = await _observationCtx.Observations.SingleOrDefaultAsync(o => o.Id == observation.Observation.ObservationId);
            if (existingObservation is null)
            {
                await _observationCtx.AddAsync(obs);
            }
            else
            {
                // Remove the entity from tracking 
                _observationCtx.Entry(existingObservation).State = EntityState.Detached;

                // Update the entity (note that by default, this will update all columns). 
                _observationCtx.Observations.Update(obs);
            }

	    await _observationCtx.SaveChangesAsync();

Before I Update() using the detached entity (obs) I first have to stop tracking the existing (and attached entity).

Of course the alternative to Update() is to do a manual merge, but I would rather not do that and have EFCore tracking machinery do this instead.

Obviously I am open for suggestions, since the current approach is not working very well.

Perhaps the simplest way/compromise is to manually copy the tracking/audit fields from the existing entity?

@thoraj
Copy link
Author

thoraj commented May 8, 2018

I changed the Update() to this:

                var et =_observationCtx.Observations.Update(obs);
                et.Property(p => p.CreatedUtc).IsModified = false;
                et.Property(p => p.CreatorUserId).IsModified = false;

This will tell EF to not update the properties tracking Creation.

@thoraj thoraj closed this as completed May 8, 2018
@gnaeus gnaeus self-assigned this May 10, 2018
@gnaeus
Copy link
Owner

gnaeus commented May 10, 2018

You are right. Assigning DateTime.Zero to CreatedUtc and default(TUserId) to CreatorUserId is meaningless. But if we explicitely change CreatedUtc to non-default value, I think we should change it in DB too.

I can add this behaviour in the next release.

@gnaeus gnaeus reopened this May 10, 2018
gnaeus pushed a commit that referenced this issue May 10, 2018
@gnaeus gnaeus added the bug label May 10, 2018
@gnaeus
Copy link
Owner

gnaeus commented May 10, 2018

Fixed in 2.0.2

@gnaeus gnaeus closed this as completed May 10, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants