odata changes between v2 and v3

MolallaComm

We took v3 live in production yesterday and one thing our testing unfortunately did not reveal before going live was that odata api seems to behave differently in v3. We have some places in code code that make calls like:

https://server:5489/odata/templates('WREPnPpjt5FaVlAu')

This worked fine with v2 - and I'm pretty sure that value between the ticks used to be the shortid - but now in v3 it is _id and the shortid is something different. Worse than that, the above call returns an invalid odata payload (in addition to "@odata.context" and "value" which are set correctly, it has an array that duplicates what is under "value" at the start which messes things up).

Oddly, if i change the query to be:

https://server:5489/odata/templates?$filter=shortid eq 'newshortid'

I get the expected valid odata response. But if i change it to be:

https://server:5489/odata/templates?$filter=_id eq 'WREPnPpjt5FaVlAu'

It returns the same malformed odata response with the array at the front you get when using the "by key" syntax.

Advice? Seems like it is a bug that could probably easily be fixed?

MolallaComm

Actually i jumped the gun here in blaming it on jsreport. I turned the old server on and compared the results of:

https://oldserver:5489/odata/templates('WREPnPpjt5FaVlAu')

vs

https://newserver:5489/odata/templates('WREPnPpjt5FaVlAu')

and the old one is also malformed. Both return something like:

{
  "0": {
    "shortid": "Ssh0qJ_M1t",
    "name": "Multiple Data Sources to XLSX",
    "recipe": "html-to-xlsx",
    "engine": "handlebars",
    "chrome": { "printBackground": true },
    "htmlToXlsx": { "htmlEngine": "chrome" },
    "creationDate": "2021-02-12T22:16:32.865Z",
    "modificationDate": "2022-03-21T21:02:06.922Z",
    "_id": "WREPnPpjt5FaVlAu",
    "data": { "shortid": "alzfT9oXW" },
    "scripts": [ { "shortid": "YV1W9PMikJ" } ],
    "content": "...",
    "helpers": "...",
    "folder": { "shortid": "sYpZKHs" }
  },
  "@odata.context": "https://192.168.7.198:5489/odata/$metadata#templates/$entity",
  "value": [
    {
      "shortid": "Ssh0qJ_M1t",
      "name": "Multiple Data Sources to XLSX",
      "recipe": "html-to-xlsx",
      "engine": "handlebars",
      "chrome": { "printBackground": true },
      "htmlToXlsx": { "htmlEngine": "chrome" },
      "creationDate": "2021-02-12T22:16:32.865Z",
      "modificationDate": "2022-03-21T21:02:06.922Z",
      "_id": "WREPnPpjt5FaVlAu",
      "data": { "shortid": "alzfT9oXW" },
      "scripts": [ { "shortid": "YV1W9PMikJ" } ],
      "content": "...",
      "helpers": "...",
      "folder": { "shortid": "sYpZKHs" }
    }
  ]
}

I believe the corrrect odata response for a "by key" URL would be just:

{
  "@odata.context": "https://192.168.7.198:5489/odata/$metadata#templates/$entity",
  "shortid": "Ssh0qJ_M1t",
  "name": "Multiple Data Sources to XLSX",
  "recipe": "html-to-xlsx",
  "engine": "handlebars",
  "chrome": { "printBackground": true },
  "htmlToXlsx": { "htmlEngine": "chrome" },
  "creationDate": "2021-02-12T22:16:32.865Z",
  "modificationDate": "2022-03-21T21:02:06.922Z",
  "_id": "WREPnPpjt5FaVlAu",
  "data": { "shortid": "alzfT9oXW" },
  "scripts": [ { "shortid": "YV1W9PMikJ" } ],
  "content": "...",
  "helpers": "...",
  "folder": { "shortid": "sYpZKHs" }
}

Turns out we also upgraded our server code from .net 3.1 to .net 6 and switched from newtonsoft the the microsoft json stuff, and something with that is causing the problem which i will track down. Sorry for the false alarm in my first post.

At some point it would be nice if jsreport returned valid odata responses for "by key" type queries but we can work around it for now.