Allowing change embbeded entities

[weierophinney]

He should not allow change embbeded entities, like this:
{"id":"3",
"descricao":"name",
"tppdvi":{"id":"1", "descricao":"update name"}
}

---

Originally posted by @fabioginzel at zfcampus/zf-apigility-doctrine#166

[weierophinney]

I don't understand what you're reporting. Are you talking about embedded data in ODM? Is this PUT or PATCH? What does tppdvi represent?

---

Originally posted by @TomHAnderson at zfcampus/zf-apigility-doctrine#166 (comment)

[weierophinney]

Tppdvi is a embedded doctrine entity and apigility allows to change the descricao field.

---

Originally posted by @fabioginzel at zfcampus/zf-apigility-doctrine#166 (comment)

[weierophinney]

That's interesting. Are you using ODM or ORM? Is there more about this you can add?

---

Originally posted by @TomHAnderson at zfcampus/zf-apigility-doctrine#166 (comment)

[weierophinney]

I called a translator.

I'm using apigility with doctrine. When I send a patch to the main entity I'm trying to update, it's also updating an embedded entity.

For example, let's say we have a students table and a courses table.
The student entity has it's course embedded.

When I patch the student entity, if somehow the course entity name is changed, it updates the course name on the courses table.

---

Originally posted by @fabioginzel at zfcampus/zf-apigility-doctrine#166 (comment)

[weierophinney]

Database = MySQL? MongoDB?

---

Originally posted by @TomHAnderson at zfcampus/zf-apigility-doctrine#166 (comment)

[weierophinney]

I've tested on MS Sql Server and PostgreSql.

---

Originally posted by @fabioginzel at zfcampus/zf-apigility-doctrine#166 (comment)

[weierophinney]

@veewee what do you think of this? Are your hydrators too good?

---

Originally posted by @TomHAnderson at zfcampus/zf-apigility-doctrine#166 (comment)

[weierophinney]

any news on this? I like the Idea of Posting directly to the subentities but i think there is a need to call the input validators of the nested entity, otherwise you'll run into errors.

---

Originally posted by @takethefake at zfcampus/zf-apigility-doctrine#166 (comment)

[weierophinney]

@veewee bumping this. I'd sure appreciate your insight on this.

---

Originally posted by @TomHAnderson at zfcampus/zf-apigility-doctrine#166 (comment)

[weierophinney]

Hi @TomHAnderson
Sadly, I haven't found the time to follow this repo up to the latest version.
It's exactly the same as with forms: if you submit the field:
tppdvi[descricao]=test, the field will be updated in the database.
I am perfectly fine with this feature and am using this on some projects.

If you don't want this feature, you can filter / validate the input yourself on pre-update ?

---

Originally posted by @veewee at zfcampus/zf-apigility-doctrine#166 (comment)

[weierophinney]

But if my user dont have permission to change embbeded entity?

---

Originally posted by @fabioginzel at zfcampus/zf-apigility-doctrine#166 (comment)

[weierophinney]

@fabioginzel @veewee ping

---

Originally posted by @jguittard at zfcampus/zf-apigility-doctrine#166 (comment)

[weierophinney]

hi

---

Originally posted by @fabioginzel at zfcampus/zf-apigility-doctrine#166 (comment)

[weierophinney]

@fabioginzel do you still need any help with it or you have found the solution?

---

Originally posted by @michalbundyra at zfcampus/zf-apigility-doctrine#166 (comment)

[TomHAnderson]

This is an issue I've seen raised before and it's a featured bug. The feature is the hydrators work exactly like they should when hydrating. The bug is they hydrate sub-entities, if included in the request body, which is also the feature.

This issue scares me and I've wondered if this is an Achilles heel. I have not written an article on the problem. The closest article I've written (which I include here because each article represents deep thought on the subject) is https://blog.tomhanderson.com/2015/02/hypertext-application-language.html which asks the question, "Is the product of the full extension of an API a new database language?"

Given a brand-new project with this repository you really have full access to do what you will with the database assuming api endpoints created from the ui tool (with no fields) and unedited. And that I think answers my question with a "Yes".

But such open database access is a problem in a real-world application where anything but a GET is provided. Should a developer be required to clean all association from a request? I think "No". Testing on https://api.etreedb.org an attempt to patch a user on a PATCH to an artist results in an API Problem: 400 "detail": "Unrecognized field "user"" so properly listing the fields [in the ui] prevents PATCH access to related entities.

I think properly listing fields is important to a proper API Tools implementation with Doctrine.