You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Restructured eager loading tests and fixed two bugs (#882)
* Restructured eager loading tests and fixed two bugs:
1] During update, eager loads without parse fieldsets were not loaded at all places, which would make the resource change tracker incorrectly detect changes and return 200 instead of 204.
2] Creating a resource with a required EagerLoad (not exposed as relationship) was not possible, as there was no place for user code to create the related entity. Fixed this by making the create logic more similar to update logic. The change tracker scans through the initally created resource, invoking all property getters, enabling them to create related entities on the fly. See usage in Building.cs.
* Updated test to set calculated property that depends on required relationship
* Improved handling for non-loaded related entities.
Yesterday I was trying to solve the wrong problem. The problem is not how to prevent a crash when creating a new resource that has a required EagerLoad relationship. Instead, the problem is that api developers need a way to assign relationships (EagerLoads or not) on resource creation. Whether such a relationship is required or not is irrelevant, it depends on business logic which relationships must be assigned. And that may be an already-existing entity or a new one. If the goal is to assign an already-existing entity, the api developer needs an async method to load that entity and assign it to the resource being created.
This commit adds `IResourceWriteRepository.GetForCreateAsync`, which is analog to `GetForUpdateAsync`. This makes the resource creation logic in resource service very similar to update.
This also fixes the tests, where [NotMapped] was missing on calculated properties. Except for request body deserialization, there is no more need to handle nulls in calculated properties that access a required related EagerLoad entity. And by treating the deserialized resource object just as an input source (which is never saved), we get by with just storing the deserialized data for later use, knowing it will be read and copied into the resource instance we're going to save.
Also reordered repository members in a more logical order (used to be verb-based).
0 commit comments