Skip to content

Problem with custom object changing while overriding UpdateAsync #575

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

Closed
N1ghtStorm opened this issue Oct 15, 2019 · 2 comments
Closed

Problem with custom object changing while overriding UpdateAsync #575

N1ghtStorm opened this issue Oct 15, 2019 · 2 comments

Comments

@N1ghtStorm
Copy link

N1ghtStorm commented Oct 15, 2019

Description

I have a model, that has it's DbSet in DbContext

   public class Human : Identifiable
   {
       [Attr("name")]
       [StringLength(128)]
       public string Name { get; set; }

       [Attr("second-name")]
       [StringLength(128)]
       public string  SecondName{ get; set; }
   }

I have a JsonApiController, where PatchAsync method is overriden:

public class PeopleController : JsonApiController<Human>
{
             public PeopleController(
             IJsonApiContext json_api_context,
             IResourceService<Human> resource_service,
             ILoggerFactory logger_factory,
               : base(json_api_context, resource_service) {}

// Patch method:
    [HttpPatch("{id}")]
    public async override Task<IActionResult> PatchAsync(int id, [FromBody]Human human)
    {
        human.SecondName = "Some Second Name";
        return base.PatchAsync(id, human);
    }
}

The problem is:
This operation

"human.SecondName = "Some Second Name"

doesnt affect state of "human" object, we even can return base method like this:

"return base.PatchAsync(id, new Human());"

or

"return base.PatchAsync(id, null);"

the final changes in database will be taken from initial state of entity(that was taken exactly from request)

}

Environment

  • JsonApiDotNetCore Version: 3.1
  • .Net Core 2.2
  • Other Relevant Package Versions:
@maurei
Copy link
Member

maurei commented Oct 15, 2019

This problem is described in #536 and also describes a work around.

This issue will be tackled in v4 in a more elegant way.

Let me know if the other issue has enough instructions for you to work around the issue.

@N1ghtStorm
Copy link
Author

This problem is described in #536 and also describes a work around.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

No branches or pull requests

2 participants