Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

feat(doctrine): allow property aliasing on doctrine filters #6584

Open
wants to merge 3 commits into
base: main
Choose a base branch
from

Conversation

Zzareb
Copy link

@Zzareb Zzareb commented Sep 5, 2024

Q A
Branch? main, new feature
License MIT
Doc PR api-platform/docs

Add a way to alias properties used to query the api filters.

via a simple configuration on the filter declaration, we can replace the parameters such as

my.relation.nested.superField by a simple superField that will be automatically resolved under the hood.

the documentation generated in the response is up to date with the aliased fields.

@Zzareb Zzareb marked this pull request as draft September 5, 2024 14:30
@Zzareb Zzareb marked this pull request as ready for review September 5, 2024 15:22
@soyuka
Copy link
Member

soyuka commented Sep 6, 2024

Interesting, although aliases are made possible using the new QueryParameter functionality since API Platform 3.2. I'm wondering how the documentation (hydra) outputs the view template for such a feature? What about OpenAPI does the parameter gets documented?

@Zzareb
Copy link
Author

Zzareb commented Sep 6, 2024

Interesting, although aliases are made possible using the new QueryParameter functionality since API Platform 3.2. I'm wondering how the documentation (hydra) outputs the view template for such a feature? What about OpenAPI does the parameter gets documented?

@soyuka
Thanks for the reply. I’ll search the docs for the QueryParameter you mention !
the hydra output returns the aliased property only, might be worthwhile returning both.

I did not tackle open api documentation for this feature, because it is more a flavour for a dedicated field in an entity than a replacement api-wide for the parameter… might be interesting to have it as well for the given routes, although I’m not sure about the implications in the swagger client etc

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants