none
Error: A value cannot be specified for property 'id' RRS feed

  • Question

  • I am encountering a problem with inserting a new object into mobile services.
    I made a new table in my mobile service using the azure portal, and I am getting this error everytime I try to add this new object:

    Error: A value cannot be specified for property 'id'

    The id for the object is 0, and has not been set.
    Here is my object:

    public class paystub
        {
            [PrimaryKey, AutoIncrement]
            [JsonProperty("id")] 
            public int PaystubID{ get; set; }
            public int EmpID { get; set; }
            public int DocumentID { get; set; }
            public DateTime DateFrom { get; set; }
            public DateTime DateTo { get; set; }
            public DateTime DatePaid { get; set; }
        }

    Any ideas?
    • Edited by MJFara Tuesday, July 23, 2013 4:01 AM
    Tuesday, July 23, 2013 3:40 AM

Answers

  • We just released a change in the runtime so that this issue should not happen anymore. Here's the change, as described in the team blog:

    Changed a behavior in the runtime for tables with integer ids regarding “id” property in POST (insert) requests: before, any POST (insert) request for tables with integer ids would fail if there was an “id” property in the body of the request. Since the id of such tables could not be determined by the client, it was considered an invalid request (rejected before it would arrive in any user-defined scripts for the insert operation), and the client SDK would remove the “id” property in those requests. There were some scenarios, however, in which this was not happening (as described in this forum post), so the runtime now works as follows:

    • All POST (insert) requests, even those where the “id” is specified, will reach the user-defined script for the insert operation.
    • If there is an “id” property, the insert request request will be considered valid if the value of that property is “false-y”. That means that sending an insert request with "id":0, "id":"" or "id":null will now succeed. If the value of the property is not false, then the request will fail (as it would before).
    Sunday, March 30, 2014 11:11 PM
    Moderator

All replies

  • Hi,

    The error is showing up as insert on server side is checking if 'id' is one of the fields (value doesn't matter) it returns error. I had to use different name to overcome this as I'm using insert call also to update in some situations and don't want two API calls.

    I'm not using C# but it looks from the documentation that you shouldn't use JsonProperty("id"). In todo example the structure is:

    public class TodoItem
    {
    public int Id { get; set; }
    
    [JsonProperty(PropertyName = "text")]
    public string Text { get; set; }
    
    [JsonProperty(PropertyName = "complete")]
    public bool Complete { get; set; }
    }

    Rafal

    Tuesday, July 23, 2013 6:45 AM
  • I tried without JsonProperty and the issue is the same.
    Tuesday, July 23, 2013 1:32 PM
  • It's not making any sense, every one of my 40 other tables can be inserted into fine.
    Except this one.
    Nothing is different about it.
    Tuesday, July 23, 2013 1:43 PM
  • bool tryupdate = false;
                    try
                    {
                        await App.MobileService.GetTable<paystub>().InsertAsync(this);
                    }
                    catch
                    {
                        tryupdate = true;
                    }
                    if(tryupdate)
                        await App.MobileService.GetTable<paystub>().UpdateAsync(this);

    On the Insert, it will throw an exception that says the id is already specified, yet if I try to update, it throws another exception that says:

    Cannot update if the id member is set to a default value.

    I've wasted my entire day trying to figure this out, it makes no sense at all....

    Tuesday, July 23, 2013 6:15 PM
  • So I have figured out a temporary work around, which also makes no sense at all.

    If I add an empty object right before I add the object that keeps throwing an exception, both will be added without issues.
    If I do not add this empty object first, the object I'm trying to add will throw the exception.

    paystub ps = new paystub(); await ps.Add(); await ps.Delete(); paystub pt = await emp.EmpTag.GeneratePaystub(emp, vm.PP); await pt.Add();

    If I add pt on it's own, it will not work, no matter what I do.
    But if I add ps first, it does work.

    Even if I assign the property values of pt to ps, it won't work unless I first add a blank object.
    This makes absolutely no sense to me, none of my other tables do this. How can I debug this weird problem? I'm getting desperate, as this section needs to be finished by this Friday (2 days).

    Wednesday, July 24, 2013 1:37 PM
  • Another of my tables now has this same issue, nothing was changed.

    Anyone?

    Tuesday, July 30, 2013 12:36 AM
  • You cannot have a value for the id field.  It should be null.

    Post your code where you are creating your object and how  you fill in the values for that object for more targeted assistance please.

    Jeff


    Jeff Sanders (MSFT)

    @jsandersrocks - Windows Store Developer Solutions @WSDevSol
    Getting Started With Windows Azure Mobile Services development? Click here
    Getting Started With Windows Phone or Store app development? Click here
    My Team Blog: Windows Store & Phone Developer Solutions
    My Blog: Http Client Protocol Issues (and other fun stuff I support)

    Tuesday, July 30, 2013 2:59 PM
  • I can not set an int to null.

    I'm at about 50 tables, 1+ year in development, there is definitely something out of the norm here.

    All my other tables are fine, and if I add a blank object first, the next object will go in just fine.

    Here is the latest object giving me issues (this code has been working fine for months):

    public emphours NewPayrollEnrty(DateTime? pdate = null)
            {
                if(pdate == null)
                    pdate = DateTime.Now;
                emphours eh = new emphours();
                eh.EmpID = EmpID_;
                eh.Rate = Wage;
                eh.In = pdate;
                eh.Out = null;
    
                return eh;
            }

    Tuesday, July 30, 2013 3:04 PM
  • The ONLY thing I can remember changing in the last little while, is adding another property.

    public int PaystubID { get; set; }

    Other than this, absolutely nothing has changed anywhere else in this section of my app.

    It's been working for months. Here is the class:

    public class emphours
        {
            [PrimaryKey, AutoIncrement]
            [JsonProperty("id")] 
            public int EmpHoursID { get; set; }
            public int JobID { get; set; }
            public int EmpID { get; set; }
            public DateTime? In { get; set; }
            public DateTime? Out { get; set; }
            public decimal Rate { get; set; }
            public int BreakMins { get; set; }
            public int FlagIn { get; set; }
            public int FlagOut { get; set; }        
            public int PaystubID { get; set; }
        }

    Tuesday, July 30, 2013 3:07 PM
  • Interestingly enough, it now seems to be working.

    Again, I've changed absolutely nothing in regards to this. I am 100% sure.
    It stopped working for a week, I tried again this morning and it still wasn't working.

    I attempted again right now, and it is....

    I assure you I am not crazy! This was a very weird problem.
    I am glad it's gone, for now... Any idea as to what it might have been?
    Do you think there could be an issue server side?

    The id was indeed set to the default value every time (0).


    • Edited by MJFara Tuesday, July 30, 2013 3:22 PM edit
    Tuesday, July 30, 2013 3:21 PM
  • This weird problem has returned, I can not add items to my table.

    Nothing was changed in that area of the code for many months now, now idea why it's doing this again.

    Tuesday, November 19, 2013 5:45 AM
  • Hi MJ,

    We are going to need more information to help.

    What is the backing SQL DB definition and column names?

    Do you have any CRUD scripts defined?

    What is the sequence of the code you are using (the code path).

    Jeff


    Jeff Sanders (MSFT)

    @jsandersrocks - Windows Store Developer Solutions @WSDevSol
    Getting Started With Windows Azure Mobile Services development? Click here
    Getting Started With Windows Phone or Store app development? Click here
    My Team Blog: Windows Store & Phone Developer Solutions
    My Blog: Http Client Protocol Issues (and other fun stuff I support)

    Tuesday, November 19, 2013 1:14 PM
  • I ran into this as well and found a work-around, which I posted about in your other thread: http://social.msdn.microsoft.com/Forums/windowsazure/en-US/1e0c2e74-636c-40a1-8196-c16fa9c83cb3/breaking-changes-no-id-member-found-on-type?forum=azuremobile#4d6791c3-8f6d-4463-ae3b-aa30ea2a1d87

    Just like you, I found that it worked when I performed another action (like reading the data) first before doing the insert. Upon inspecting the code, it looks like the Azure Mobile Services managed client is caching the "IdProperty" value causing this issue: social.msdn.microsoft.com/Forums/windowsazure/en-US/cacb2a22-ec54-4cdf-9f3c-fe8cf83cde41/bug-report-no-id-member-found-on-type?forum=azuremobile

    As to why it only affects some table some of the time, I have not been able to figure that part out, but the work-around seems to solve it so I have just left it in place.

    Tuesday, November 19, 2013 7:51 PM
  • Oddly enough, even the workaround was not working for me yesterday.
    I tried deleting, inserting an empty object, and reading. Same error every time.

    To make matters even more inconsistent, when I woke up this morning all was working fine...

    Hope I don't see this again, but it is definitely something on the backend.

    Tuesday, November 19, 2013 10:22 PM
  • This is really strange and I would love to get to the bottom of this.  If it happens again can you contact us via Twitter?  twitter @AzureMobile.

    Jeff Sanders (MSFT)

    @jsandersrocks - Windows Store Developer Solutions @WSDevSol
    Getting Started With Windows Azure Mobile Services development? Click here
    Getting Started With Windows Phone or Store app development? Click here
    My Team Blog: Windows Store & Phone Developer Solutions
    My Blog: Http Client Protocol Issues (and other fun stuff I support)

    Wednesday, November 20, 2013 1:33 PM
  • I have encountered the problem again, unfortunately I do not have twitter, hoping someone sees this!
    Monday, December 23, 2013 4:00 PM
  • I can confirm that the entry is successfully being put into the database.
    The insert script completes without issue, yet the client throws an exception with that error.

    Sunday, December 29, 2013 9:47 PM
  • I went as far as creating a temporary table, copying all data and scripts over to it, deleting the table that's giving me problems, re-creating it using the windows azure command-line interface, recopying my data back, and I STILL have the same issue.

    This is a huge roadblock for me and I can not continue until this is resolved.

    Monday, December 30, 2013 7:13 PM
  • What version of the SDK are you using?  We did fix one potential cause of this issue in version 1.1.1 due to inserting derived data types.  (see: https://github.com/WindowsAzure/azure-mobile-services/pull/189)


    Monday, December 30, 2013 7:59 PM
    Moderator
  • I just updated now and I still have the same problem.

    The entry is being added into the db, yet it returns that error message.

    • Edited by MJFara Monday, December 30, 2013 8:24 PM
    Monday, December 30, 2013 8:23 PM
  • There is currently an issue when calling insert and specifying the Id as an empty string against an Integer Id table that could be what you are running into.

    Can you let me know what the json looks like you are sending on the insert call and if the table you are having this issue against has a string or integer based Id?

    Friday, January 10, 2014 10:51 PM
    Moderator
  • I am having the same issue too. It started after I upgraded to version 1.1.4 from one of the 1.0.x versions. I am using a table with Integers with the newer client.

    I first attempted to call delete item.id; as the first line of my script, but that does not work either. I attempted to downgrade the client to 1.0.3, but that did not solve the problem either.

    Are you guys "preflighting" the data in some way before it hits our code? Something you added with the 0.1.6.3004 runtime? Because that would be the only explanation as to why this is suddenly not working... if you guys for some reason took more control over validating POST requests than you previously had.

    Sunday, March 2, 2014 11:55 PM
  • I am having the same or similar issue. As Robert tried, I expected simply deleting the item.id field in the insert script would take care of it, even though that itself would be a bit of a pain doing it on every insert script for every table. I even put a console.log in the insert script to see if it was running, but the error seems to happen before I have the chance to correct it in a server script.

    I wish the client side libraries / AMS server side would be able to do what seems obvious and not try to POST containing the id. After all doesn't it require "id" to be the primary key? It seems it could act more intelligently and have some sanity checks involved to not trip over itself like this.

    Friday, March 7, 2014 1:35 AM
  • This has been going on for some time now, and I'd like to update this thread to give full details where we are in this investigation.

    The issue:

    For tables with integer ids, a POST (insert) request cannot be sent with an "id" property. Since those tables use an auto-incremented field, the id cannot be sent by the client. This error should not occur for tables with string ids.

    For example, this is a valid request body for inserting into a table:

        {"text":"Buy bread","complete":false}

    While those are invalid (again, for tables with integer ids):

        {"text":"Buy bread","complete":false,"id":null}
        {"text":"Buy bread","complete":false,"id":""}

    This validation for this case happens before the request reaches the script, which is why trying to remove the id at the insert script doesn't work. We may relax this restriction in the future (i.e., move the validation from the request handler to the storage handler, where the request would fail), but as of now removing the id in the script is not an option.

    Why it should not be happening:

    When an object is passed in a call to IMobileServiceTable<T>.InsertAsync, the object is serialized to be sent over the wire. When creating the serializer (JSON.NET), the mobile service client uses a custom resolver which defines how the "id" property is serialized: it makes sure that the id is always sent as "id" (even if the property is called "Id" or "ID"), and it also sets the DefaultValueHandling and NullValueHandling properties so that, if the value of that property is null or the default value (for value types) then that property is not serialized. That means that if an app creates an object, doesn't set the id property to anything (i.e., it's set to 0 for int/long properties, or null for string properties), then the property shouldn't be sent, and the object should be inserted successfully.

    Why this is happening:

    At this point, we do not know. I've managed to have it reproduce in many different ways, but what customers are seeing is not one of those. Here are some ways which I know will happen:

    • Using the InsertAsync(JObject) overload: there's no serialization in this overload, and the data is sent "as is" to the server.
    • Using a HttpMessageHandler instance when creating the client which changes the payload and adds an "id" property.
    • Changing the contract resolver in the SerializerSettings on the client so that the logic to "fix" the id is not executed.

    Unfortunately, what people are seeing are not those cases, and at this point I have not managed to find a scenario where I can reproduce the issue outside those mentioned above.

    A request for help:

    So if you have a certain type which exhibits this behavior, I'd really appreciate if you could send it to me (please remove any specific logic / data that cannot be publicly shared) so we could reproduce it locally and follow the code to understand why the id is not being removed from insert calls. Once we have that repro we will certainly fix this issue fairly quickly.

    A workaround:

    If you're blocked by this issue and need a way to unblock yourself, there's an alternative. The class below is a custom HttpMessageHandler which will read the outgoing requests, strip any "id" properties from outgoing POST requests and send it to the server.

    public class IdRemovingHandler : DelegatingHandler
    {
        protected override async Task<HttpResponseMessage> SendAsync(HttpRequestMessage request, CancellationToken cancellationToken)
        {
            if (request.Method.Method.Equals("POST", StringComparison.OrdinalIgnoreCase))
            {
                if (request.Content != null && request.Content.Headers.ContentType != null)
                {
                    if (request.Content.Headers.ContentType.MediaType.Equals("application/json", StringComparison.OrdinalIgnoreCase))
                    {
                        var json = await request.Content.ReadAsStringAsync();
                        var body = JObject.Parse(json);
                        if (body.Remove("id"))
                        {
                            request.Content = new StringContent(body.ToString(), Encoding.UTF8, "application/json");
                        }
                    }
                }
            }
            return await base.SendAsync(request, cancellationToken);
        }
    }

    This handler can be added to the client when you create it, by using the constructor overload which takes the (params HttpMessageHandler[]) parameter.

    Thank you for using the mobile services client, and hopefully we'll get to the bottom of this issue soon.


    Carlos Figueira

    Saturday, March 8, 2014 12:29 AM
    Moderator
  • We just released a change in the runtime so that this issue should not happen anymore. Here's the change, as described in the team blog:

    Changed a behavior in the runtime for tables with integer ids regarding “id” property in POST (insert) requests: before, any POST (insert) request for tables with integer ids would fail if there was an “id” property in the body of the request. Since the id of such tables could not be determined by the client, it was considered an invalid request (rejected before it would arrive in any user-defined scripts for the insert operation), and the client SDK would remove the “id” property in those requests. There were some scenarios, however, in which this was not happening (as described in this forum post), so the runtime now works as follows:

    • All POST (insert) requests, even those where the “id” is specified, will reach the user-defined script for the insert operation.
    • If there is an “id” property, the insert request request will be considered valid if the value of that property is “false-y”. That means that sending an insert request with "id":0, "id":"" or "id":null will now succeed. If the value of the property is not false, then the request will fail (as it would before).
    Sunday, March 30, 2014 11:11 PM
    Moderator