Some related collections are expensive to compute, in the sense that they require additional database queries. Examples include Period#getContentNodes() and Day#getScheduleEntries().
With our current implementation, we try to support not only the HAL JSON format, but also JSON+LD and GraphQL. For HAL, we sometimes add an annotation #[RelatedCollectionLink], and the API response therefore only contains a filtered link like /content_nodes?period=/periods/1a2b3c4d, so all the contentNode data which is fetched from the database is completely ignored afterwards. So if we were only supporting HAL JSON, there would be no need to perform these additional database queries. But omitting the queries would break the JSON+LD format and possibly also GraphQL (not sure about that one).
This affects all API calls where a period or day entity is normalized (e.g. when loading or patching a single period, when loading all periods, when loading a camp with embedded periods, etc.)
This issue was originally raised by @usu in #2700 (comment) and the decision might influence how to proceed in a past discussion in #2683 (comment).
We should decide how we want to proceed with such getters on our entities. Probably we should assess the performance impact of these first.
Some related collections are expensive to compute, in the sense that they require additional database queries. Examples include
Period#getContentNodes()andDay#getScheduleEntries().With our current implementation, we try to support not only the HAL JSON format, but also JSON+LD and GraphQL. For HAL, we sometimes add an annotation
#[RelatedCollectionLink], and the API response therefore only contains a filtered link like/content_nodes?period=/periods/1a2b3c4d, so all the contentNode data which is fetched from the database is completely ignored afterwards. So if we were only supporting HAL JSON, there would be no need to perform these additional database queries. But omitting the queries would break the JSON+LD format and possibly also GraphQL (not sure about that one).This affects all API calls where a period or day entity is normalized (e.g. when loading or patching a single period, when loading all periods, when loading a camp with embedded periods, etc.)
This issue was originally raised by @usu in #2700 (comment) and the decision might influence how to proceed in a past discussion in #2683 (comment).
We should decide how we want to proceed with such getters on our entities. Probably we should assess the performance impact of these first.