-
-
Notifications
You must be signed in to change notification settings - Fork 9.6k
[Serializer] Deprecate CsvEncoder as_collection false default value #27715
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
[Serializer] Deprecate CsvEncoder as_collection false default value #27715
Conversation
(rebase needed) |
Rebased |
UPGRADE-4.2.md
Outdated
-------------- | ||
|
||
* The `lazy` attribute on `doctrine.event_listener` tags was removed. | ||
Listeners are now lazy by default. So any `lazy` attributes can safely be removed from those tags. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Does not seem related to this PR.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, indeed. It's just to respect the alpha order we use on UPGRADE files.
I can do another PR if you want, but IIRC we already accepted such changes inside unrelated PRs in the past.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
See #27781
Thank you @ogizanagi. |
…default value (ogizanagi) This PR was merged into the 4.2-dev branch. Discussion ---------- [Serializer] Deprecate CsvEncoder as_collection false default value | Q | A | ------------- | --- | Branch? | master <!-- see below --> | Bug fix? | no | New feature? | no <!-- don't forget to update src/**/CHANGELOG.md files --> | BC breaks? | no <!-- see https://symfony.com/bc --> | Deprecations? | yes <!-- don't forget to update UPGRADE-*.md and src/**/CHANGELOG.md files --> | Tests pass? | yes <!-- please add some, will be required by reviewers --> | Fixed tickets | N/A <!-- #-prefixed issue number(s), if any --> | License | MIT | Doc PR | N/A As already expressed in #25369 and related issues, this behavior is quite counter-intuitive. It may be fine for write-API with a single document in the body but I think such CSV APIs are way less common than file-based ones, expecting collections. So I think this behavior should be opt-in explicitly in required cases, always dealing with collections by default. This is still an arbitrary decision, but trying to make it based on use-cases and user's experience with CSV. Note: perhaps we could find a better name for this as the semantic of setting `as_collection` to `false` to get the single row directly would not be really obvious. Also, it could throw an exception when getting multiple rows where only one was expected. Commits ------- bce59c8 [Serializer] Deprecate CsvEncoder as_collection false default value
…on & change default value (ogizanagi) This PR was merged into the 5.0-dev branch. Discussion ---------- [Serializer] Remove CsvEncoder "as_collection" deprecation & change default value | Q | A | ------------- | --- | Branch? | master <!-- see below --> | Bug fix? | no | New feature? | no <!-- please update src/**/CHANGELOG.md files --> | BC breaks? | no <!-- see https://symfony.com/bc --> | Deprecations? | no <!-- please update UPGRADE-*.md and src/**/CHANGELOG.md files --> | Tests pass? | yes (AppVeyor failure unrelated. See https://github.com/symfony/symfony/pull/31685/files) <!-- please add some, will be required by reviewers --> | Fixed tickets | #27715 <!-- #-prefixed issue number(s), if any --> | License | MIT | Doc PR | N/A <!-- required for new features --> As planned in #27715 Commits ------- 22dd071 [Serializer] Remove CsvEncoder "as_collection" deprecation & change default value
As already expressed in #25369 and related issues, this behavior is quite counter-intuitive. It may be fine for write-API with a single document in the body but I think such CSV APIs are way less common than file-based ones, expecting collections. So I think this behavior should be opt-in explicitly in required cases, always dealing with collections by default.
This is still an arbitrary decision, but trying to make it based on use-cases and user's experience with CSV.
Note: perhaps we could find a better name for this as the semantic of setting
as_collection
tofalse
to get the single row directly would not be really obvious.Also, it could throw an exception when getting multiple rows where only one was expected.