Strange POST behavior on nested lists about yang-express HOT 15 CLOSED

It will be also good to perform the same tests when the system starts with empty data seed.

from yang-express.

Thanks, this is highly informative. The issue is that an uninitialized list property node (yet to be seeded) has "prop.content" as being undefined and is expecting the [] array data when being "set" instead of {} object data (which is what you would expect on a POST call. I'll need to either allow list node to auto-convert object data to be contained by an array when being set for the first time OR have the POST handler in yang-express do that conversion beforehand. If you wrap your current POST payload in [ ... ] I think it should accept it....

from yang-express.

I had tried debugging it at the point you mentioned (restconf.coffee Line 46) and found even that fail.

bash-4.3$ curl -i -X POST localhost:5000/pet/2/childpet -H 'content-type: application/json' -d '[ { "id": 1, "name": "childpet-1", "tag": "test" } ]'
HTTP/1.1 400 Bad Request
X-Powered-By: Express
Date: Thu, 18 Aug 2016 00:20:20 GMT
Connection: keep-alive
Content-Length: 0

bash-4.3$

from yang-express.

Yeah... the match variable should've been an empty array - it means that the Model.in method is not returning the proper empty list when the list prop.content is undefined.

This is where the bug is:

match = switch
      when not match?.length then undefined
      when /list$/.test(expr.kind) and not li then match
      when match.length > 1 then match
      else match[0]

The first two 'when' statements need to be swapped. I'll fix this once back on my workstation. :-)

from yang-express.

Actually, there may be a change needed on yang-express POST handler as well. I don't think .add function would be available inside .content. Will check it out more tomorrow am.

from yang-express.

I can still see the same issue. Did you really intend to close this issue ?

from yang-express.

No, my commit wording auto-closed it... Re-opening now. I'm reconsidering exactly what the Model.in should actually return. The current match variable returns different object depending on the schema type and can be confusing for folks that use it. I'll come up with something better. :-)

from yang-express.

Ok, this issue should be fixed. I've had to do some key internal state optimizations and cleanup some prior XPATH logic that I didn't quite like. Now Model.in returns one or more Property instances and you can use the resulting prop(s) to perform get/set/merge/remove operations. The restjson module has been completely refactored based on this - it should be far more expressive, powerful and cleaner.

from yang-express.

Still does not work -

CASE-1 : Only one PET with one CHILDPET in the seed data

bash-4.3$ curl -i -X POST localhost:5000/pet/1/childpet -H 'content-type: application/json' -d '{ "id": 2, "name": "childpet-2" }'
HTTP/1.1 400 Bad Request
X-Powered-By: Express
Date: Fri, 19 Aug 2016 16:32:38 GMT
Connection: keep-alive
Content-Length: 0

bash-4.3$
bash-4.3$ curl -i -X POST localhost:5000/pet/1/childpet -H 'content-type: application/json' -d '[{ "id": 2, "name": "childpet-2" }]'
HTTP/1.1 400 Bad Request
X-Powered-By: Express
Date: Fri, 19 Aug 2016 16:34:03 GMT
Connection: keep-alive
Content-Length: 0

bash-4.3$

bash-4.3$ curl localhost:5000/pet/1/childpet
{
  "childpet": [
    {
      "id": 1,
      "name": "childpet-1"
    }
  ]
}bash-4.3$

CASE-2: Only one PET with two CHILDPET in seed data

bash-4.3$ curl localhost:5000/pet/1/childpet
{
  "childpet": [
    {
      "id": 1,
      "name": "childpet-1"
    },
    {
      "id": 2,
      "name": "childpet-2"
    }
  ]
}bash-4.3$curl -i -X POST localhost:5000/pet/1/childpet -H 'content-type: application/json' -d '{ "id": 3, "name": "childpet-3" }'
HTTP/1.1 400 Bad Request
X-Powered-By: Express
Date: Fri, 19 Aug 2016 16:35:54 GMT
Connection: keep-alive
Content-Length: 0

bash-4.3$

Add a new PET:

bash-4.3$ curl -i -X POST localhost:5000/pet -H 'content-type: application/json' -d '{ "id": 2, "name": "pet-2" }'
HTTP/1.1 201 Created
X-Powered-By: Express
Content-Type: application/json; charset=utf-8
Content-Length: 321
ETag: W/"141-x9WWsuVfK47mz1/cx8l1Mg"
Date: Fri, 19 Aug 2016 16:38:01 GMT
Connection: keep-alive

{
  "petstore:pet": [
    {
      "id": 1,
      "name": "pet-1",
      "tag": "friendly",
      "childpet": [
        {
          "id": 1,
          "name": "childpet-1"
        },
        {
          "id": 2,
          "name": "childpet-2"
        }
      ]
    },
    {
      "id": 2,
      "name": "pet-2"
    }
  ]
}bash-4.3$

CASE-3: Two PETs each with two CHILDPETs in seed data

bash-4.3$ curl localhost:5000/pet
{
  "petstore:pet": [
    {
      "id": 1,
      "name": "pet-1",
      "tag": "friendly",
      "childpet": [
        {
          "id": 1,
          "name": "pet-1-childpet-1"
        },
        {
          "id": 2,
          "name": "pet-1-childpet-2"
        }
      ]
    },
    {
      "id": 2,
      "name": "pet-2",
      "tag": "tiered",
      "childpet": [
        {
          "id": 1,
          "name": "pet-2-childpet-1"
        },
        {
          "id": 2,
          "name": "pet-2-childpet-2"
        }
      ]
    }
  ]
}bash-4.3$ curl-i -X POST localhost:5000/pet/1/childpet -H 'content-type: application/json' -d '[{ "id": 3, "name": "pet-1-childpet-3" }]'
HTTP/1.1 400 Bad Request
X-Powered-By: Express
Date: Fri, 19 Aug 2016 16:43:00 GMT
Connection: keep-alive
Content-Length: 0

bash-4.3$ curl -i -X POST localhost:5000/pet/1/childpet -H 'content-type: application/json' -d '{ "id": 3, "name": "pet-1-childpet-3" }'
HTTP/1.1 400 Bad Request
X-Powered-By: Express
Date: Fri, 19 Aug 2016 16:43:17 GMT
Connection: keep-alive
Content-Length: 0

bash-4.3$

from yang-express.

Changing https://github.com/corenova/yang-express/blob/master/src/restjson.coffee#L32 works:

#when kind is 'list' and req.prop.parent.__.schema.kind isnt 'list'
when kind is 'list'

Here is a pull request: #5

from yang-express.

Ah ok, while I was trying to ensure POST doesn't work directly on a list item, it also breaks a list child from the list item to accept POST. Let's just keep when kind is "list" for now and I'll try to figure out a better way to differentiate a list item vs a list.

from yang-express.

Ok. Could you please merge the pull request for now then ?

from yang-express.

Yes, merged now. We can close it for now but I still need to address the fact that without some form of filter on a list item property, you can actually POST /pet/1 with an array of additional pet entries and it will add them into the main /pet collection.

from yang-express.

Updated to restrict POST /pet/1 from taking place.

from yang-express.

Works with the latest. Many thanks.

from yang-express.