locked
Content-ID in batch request error result doesn't match RRS feed

  • Question

  • I'm sending a batch request, and one of the requests is failing due to a primary key constraint violation. Each changeset is being sent with a Content-ID. However, the Content-ID referenced in the response, always seems to be of the last changeset, not of the one that has the error.
    Sunday, October 30, 2011 7:25 AM

All replies

  • Hi,

    Each batch can have multiple changeset withit each there are multiple operations. The Content-ID is sent on the operations (not on the changeset itself). Are you sending a single changeset with multiple operations, or multiple changesets? A sample of the batch payload possible with pointer to the operation which you think should be failing would help.

    Thanks,


    Vitek Karas [MSFT]
    Sunday, October 30, 2011 11:25 AM
    Moderator
  • Ok here is my request, with the changset in question highlighted, and the response.

     

    POST /$batch HTTP/1.1
    Host: ............
    Connection: close
    Accept-encoding: gzip, deflate
    Accept: application/json
    Content-Type: multipart/mixed; boundary=batch_1e98749e-1cde-0c48-6ed3-c9c56e5e259c
    Content-Length: ....
    
    --batch_1e98749e-1cde-0c48-6ed3-c9c56e5e259c
    Content-Type: multipart/mixed; boundary=changeset_0ec1b5b7-f8b4-844b-656e-49dbd248d4c8
    
    --changeset_0ec1b5b7-f8b4-844b-656e-49dbd248d4c8
    Content-Type: application/http
    Content-Transfer-Encoding: binary
    
    MERGE /people(37678) HTTP/1.1
    Content-ID: 1
    Accept: application/json
    Content-Type: application/json;type=entry
    Content-Length: 210
    
    <JSON person entity>
    --changeset_0ec1b5b7-f8b4-844b-656e-49dbd248d4c8
    Content-Type: application/http
    Content-Transfer-Encoding: binary
    
    MERGE /addresses(283) HTTP/1.1
    Content-ID: 2
    Accept: application/json
    Content-Type: application/json;type=entry
    Content-Length: 140
    
    <JSON Address Entity>
    --changeset_0ec1b5b7-f8b4-844b-656e-49dbd248d4c8
    Content-Type: application/http
    Content-Transfer-Encoding: binary
    
    MERGE /phones(261) HTTP/1.1
    Content-ID: 3
    Accept: application/json
    Content-Type: application/json;type=entry
    Content-Length: 114
    
    <JSON Phone Entity>
    --changeset_0ec1b5b7-f8b4-844b-656e-49dbd248d4c8
    Content-Type: application/http
    Content-Transfer-Encoding: binary
    
    MERGE /emailAddresses(3545) HTTP/1.1
    Content-ID: 4
    Accept: application/json
    Content-Type: application/json;type=entry
    Content-Length: 125
    
    <JSON EmailAddress Entity>
    --changeset_0ec1b5b7-f8b4-844b-656e-49dbd248d4c8
    Content-Type: application/http
    Content-Transfer-Encoding: binary
    
    MERGE /emailAddresses(28354) HTTP/1.1
    Content-ID: 5
    Accept: application/json
    Content-Type: application/json;type=entry
    Content-Length: 117
    
    <JSON Email Address Entity>
    --changeset_0ec1b5b7-f8b4-844b-656e-49dbd248d4c8
    Content-Type: application/http
    Content-Transfer-Encoding: binary
    
    POST /emailAddresses HTTP/1.1
    Content-ID: 6
    Accept: application/json
    Content-Type: application/json;type=entry
    Content-Length: 94
    
    <JSON Email Address Entity>
    --changeset_0ec1b5b7-f8b4-844b-656e-49dbd248d4c8
    Content-Type: application/http
    Content-Transfer-Encoding: binary
    
    MERGE /teens(37678) HTTP/1.1
    Content-ID: 7
    Accept: application/json
    Content-Type: application/json;type=entry
    Content-Length: 269
    
    <JSON Teen Entity>
    --changeset_0ec1b5b7-f8b4-844b-656e-49dbd248d4c8
    Content-Type: application/http
    Content-Transfer-Encoding: binary
    
    MERGE /regions(13) HTTP/1.1
    Content-ID: 8
    Accept: application/json
    Content-Type: application/json;type=entry
    Content-Length: 216
    
    <JSON Region Entity>
    --changeset_0ec1b5b7-f8b4-844b-656e-49dbd248d4c8
    Content-Type: application/http
    Content-Transfer-Encoding: binary
    
    MERGE /schools(114) HTTP/1.1
    Content-ID: 9
    Accept: application/json
    Content-Type: application/json;type=entry
    Content-Length: 103
    
    <JSON School Entity>
    --changeset_0ec1b5b7-f8b4-844b-656e-49dbd248d4c8--
    --batch_1e98749e-1cde-0c48-6ed3-c9c56e5e259c--
    

    HTTP/1.1 400 Bad Request
    Content-ID: 9
    Cache-Control: no-cache
    DataServiceVersion: 1.0;
    Content-Type: application/json
    
    {
    "error": {
    "code": "", "message": {
    "lang": "en-US", "value": "An error occurred while updating the entries. See the inner exception for details. : Cannot insert duplicate key row in object 'dbo.emailAddress' with unique index 'emailAddress_email_ndx'.\r\nThe statement has been terminated."
    }
    }
    }


     

    Sunday, October 30, 2011 12:00 PM
  • Anything?
    Sunday, October 30, 2011 8:48 PM
  • Hi,

    (You can confirm the following by looking at the call stack of the error you're getting, for example by setting config.UseVerboseErrors, but I'm pretty sure anyway :-)).

    With a changeset in a batch (and assuming you're using an EF provider) all the operations in the changset are applied to the same instance of ObjectContext, through the normal EF public APIs. So the updates are not actually performed yet at all, the context just remembers them. Then when the end of the changeset is reached the service calls SaveChanges on the context. This will do some EF magic, build the update/insert SQL statements and execute them. WCF DS has no logic how to track a possible exception back to the entity which might have caused that. I'm not sure it's even possible with EF. It just uses the last operation Content-ID (this is really just a guess in WCF DS, and I do agree that it should not send any in this case, but well... it's doing it).

    In short, I don't know of a way to detect which entity caused the error (as noted, not even sure EF can do that), and WCF DS doesn't have any logic to expose this anyway. The only case where you would get the right Content-ID is if the update operation on the context failed (not the SaveChanges), but since the SQL is executed inside SaveChanges, the context doesn't know that the primary key is violating a unique index rule.

    Thanks,


    Vitek Karas [MSFT]
    Sunday, October 30, 2011 10:03 PM
    Moderator