search

laminas-api-tools / api-tools-doctrine

Laminas API Tools Doctrine module
https://api-tools.getlaminas.org/documentation
BSD 3-Clause "New" or "Revised" License
10 stars 21 forks source link

Allowing change embbeded entities #9

Open weierophinney opened 4 years ago

weierophinney commented 4 years ago

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

Originally posted by @fabioginzel at https://github.com/zfcampus/zf-apigility-doctrine/issues/166

weierophinney commented 4 years ago

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 https://github.com/zfcampus/zf-apigility-doctrine/issues/166#issuecomment-85635468

weierophinney commented 4 years ago

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

Originally posted by @fabioginzel at https://github.com/zfcampus/zf-apigility-doctrine/issues/166#issuecomment-85646577

weierophinney commented 4 years ago

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

Originally posted by @TomHAnderson at https://github.com/zfcampus/zf-apigility-doctrine/issues/166#issuecomment-85649429

weierophinney commented 4 years ago

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 https://github.com/zfcampus/zf-apigility-doctrine/issues/166#issuecomment-85650841

weierophinney commented 4 years ago

Database = MySQL? MongoDB?

Originally posted by @TomHAnderson at https://github.com/zfcampus/zf-apigility-doctrine/issues/166#issuecomment-85651269

weierophinney commented 4 years ago

I've tested on MS Sql Server and PostgreSql.

Originally posted by @fabioginzel at https://github.com/zfcampus/zf-apigility-doctrine/issues/166#issuecomment-85651899

weierophinney commented 4 years ago

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

Originally posted by @TomHAnderson at https://github.com/zfcampus/zf-apigility-doctrine/issues/166#issuecomment-85654992

weierophinney commented 4 years ago

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 https://github.com/zfcampus/zf-apigility-doctrine/issues/166#issuecomment-91175687

weierophinney commented 4 years ago

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

Originally posted by @TomHAnderson at https://github.com/zfcampus/zf-apigility-doctrine/issues/166#issuecomment-100323187

weierophinney commented 4 years ago

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 https://github.com/zfcampus/zf-apigility-doctrine/issues/166#issuecomment-100326068

weierophinney commented 4 years ago

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

Originally posted by @fabioginzel at https://github.com/zfcampus/zf-apigility-doctrine/issues/166#issuecomment-132332179

weierophinney commented 4 years ago

@fabioginzel @veewee ping

Originally posted by @jguittard at https://github.com/zfcampus/zf-apigility-doctrine/issues/166#issuecomment-253500376

weierophinney commented 4 years ago

hi

Originally posted by @fabioginzel at https://github.com/zfcampus/zf-apigility-doctrine/issues/166#issuecomment-253510345

weierophinney commented 4 years ago

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

Originally posted by @michalbundyra at https://github.com/zfcampus/zf-apigility-doctrine/issues/166#issuecomment-358347949

TomHAnderson commented 4 years ago

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.