Migrate data property of ContentNode and child classes to support Doctrine ORM 3.0 #3740
Assignees
Comments
BacLuc
added a commit
to BacLuc/ecamp3
that referenced
this issue
Sep 3, 2023
…ine/orm 3 And don't overwrite the doctrine definition for the same field again with the same values. Now we define the Constraints on the getter, because api-platform only allows to define constraints on a getter. Remove the example on ContentNode::data, because then this example was used for all children for the data property instead of the example on the getter. Issue: ecamp#3740
BacLuc
added a commit
to BacLuc/ecamp3
that referenced
this issue
Sep 3, 2023
…ine/orm 3 And don't overwrite the doctrine definition for the same field again with the same values. Now we define the Constraints on the getter, because api-platform only allows to define constraints on a getter. Move the example on ContentNode::data to the getter, because then this example was used for all children for the data property instead of the example on the getter. Now the comment for the property still overwrites the comments for the getters, but this is ok as the inheritance is an implementation detail, and must not be exposed in the api. Issue: ecamp#3740
BacLuc
added a commit
to BacLuc/ecamp3
that referenced
this issue
Sep 3, 2023
…ine/orm 3 And don't overwrite the doctrine definition for the same field again with the same values. Now we define the Constraints on the getter, because api-platform only allows to define constraints on a getter. Move the example on ContentNode::data to the getter, because then this example was used for all children for the data property instead of the example on the getter. Now the comment for the property still overwrites the comments for the getters, but this is ok as the inheritance is an implementation detail, and must not be exposed in the api. Issue: ecamp#3740
BacLuc
added a commit
to BacLuc/ecamp3
that referenced
this issue
Sep 19, 2023
…ine/orm 3 And don't overwrite the doctrine definition for the same field again with the same values. Now we define the Constraints on the getter, because api-platform only allows to define constraints on a getter. Move the example on ContentNode::data to the getter, because then this example was used for all children for the data property instead of the example on the getter. Now the comment for the property still overwrites the comments for the getters, but this is ok as the inheritance is an implementation detail, and must not be exposed in the api. Issue: ecamp#3740
BacLuc
added a commit
to BacLuc/ecamp3
that referenced
this issue
Sep 19, 2023
…ine/orm 3 And don't overwrite the doctrine definition for the same field again with the same values. Now we define the Constraints on the getter, because api-platform only allows to define constraints on a getter. Move the example on ContentNode::data to the getter, because then this example was used for all children for the data property instead of the example on the getter. Issue: ecamp#3740
github-project-automation
bot
moved this from In Progress
to Done
in Development Kanban
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
doctrine/orm#10455
If we activate this switch, the api service fails to start because the
public data property of ContentNode is overridden in the children.
See https://github.com/BacLuc/ecamp3/tree/report_fields_where_declared
Idea:
Use setters for the additional validation, and getters for the api_platform openapi documentation
but don't redeclare the doctrine orm column $data
The text was updated successfully, but these errors were encountered: