Maurits van der Schee

Possible duplicate of #138 and #29

>Would this be a good approach? Yes, it seems good, I think I would represent them as a tree, not as a series of records. Anyway, this only covers inserts....

>However, we may have situations where a table could have more than one parent. IMHO, these situations are not very common. >to update, we PUT Yes, agree, but then.. when...

>this is one assumption for php-crud-api. Yes, representation as a tree is (which still allows cycles to exist) >So, you would prefer the generic option 1) which is a lot...

Maybe it would help you to understand this matter better with a real example. Say a post that has an author and an editor and multiple comments that have authors...

The problem with your approach is much more trivial than that. If I want to add a post with a user and there are two relationships between post and user...

I think that if we implement something like this, then it should act as a document store with nested entities. I understand how to insert that (that is trivial). Updating...

>Something like this for updates: Updates go with PUT >And something like this for updates and inserts together: Yes, you only insert or update on the highest level. You always...

Something like this: POST /records/posts?join=users { "authors_user_id": { "name": "my author name" }, "editors_user_id": { "name": "my editor name" }, "subject": "third post subject", "text": "third post text" } It...

Thank you for creating this issue. The answer is "No" as this is not (yet) implemented. You may implement such behavior in a 'beforeHandler' of the customization middleware. You could...