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
Eliminate code duplication between Upsert and Insert operations (#3287)
## Why make this change?
Closes#3209
## What is this change?
Allow Upserts coming from REST requests to fall through to the Insert
logic when auto-generated primary keys are missing. This eliminates code
duplication between these two ops in the `SqlMutationEngine`
Add a test to cover the case when we have a PUT/PATCH with keys provided
in the request body.
## How was this tested?
New test was added to ensure complete coverage over the scenarios
introduced with the keyless PUT/PATCH change.
## Sample Request(s)
PUT that updates existing row (expects 200 OK):
```
PUT https://localhost:5001/api/magazine
Content-Type: application/json
{
"id": 1,
"title": "Updated Vogue",
"issue_number": 9999
}
```
PUT that inserts new row (expects 201 Created):
```
PUT https://localhost:5001/api/magazine
Content-Type: application/json
{
"id": 5001,
"title": "Brand New Magazine",
"issue_number": 42
}
```
PATCH that updates existing row (expects 200 OK):
```
PATCH https://localhost:5001/api/magazine
Content-Type: application/json
{
"id": 1,
"title": "Updated Vogue"
}
```
PATCH that inserts new row (expects 201 Created):
```
PATCH https://localhost:5001/api/magazine
Content-Type: application/json
{
"id": 5001,
"title": "Brand New Magazine"
}
```
---------
Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com>
Co-authored-by: Aniruddh Munde <anmunde@microsoft.com>
// For PUT and PATCH API requests, the users are aware of the Pks as it is required to be passed in the request URL.
373
-
// In case of tables with auto-gen PKs, PUT or PATCH will not result in an insert but error out. Seeing that Location Header does not provide users with
374
-
// any additional information, it is set as an empty string always.
375
-
// For POST API requests, the primary key route calculated will be an empty string in the following scenarions.
372
+
// For PUT/PATCH requests where PKs are in the URL, the caller passes operationType as Upsert
373
+
// and primaryKeyRoute as empty, so the Location header is not populated (the client already knows the URL).
374
+
// For keyless PUT/PATCH requests that result in an insert, the caller passes operationType as Insert
375
+
// with a non-empty primaryKeyRoute so the client can discover the newly created resource's location.
376
+
// For POST requests, the primary key route will be empty in the following scenarios:
376
377
// 1. When read action is not configured for the role.
377
378
// 2. When the read action for the role does not have access to one or more PKs.
378
-
// When the computed primaryKeyRoute is non-empty, the location header is calculated.
379
-
// Location is made up of three parts, the first being constructed from the Host property found in the HttpContext.Request.
380
-
// The second part being the base route configured in the config file.
381
-
// The third part is the computed primary key route.
379
+
// When the computed primaryKeyRoute is non-empty and operationType is Insert, the Location header is populated.
380
+
// Location is made up of three parts: the scheme/host from the request, the base route from config,
0 commit comments