Add "input" option to NumberType #30893
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
Can you add a note in the Bridge CHANGELOG? |
c289645 to
85baf46
Compare
|
@chalasr Thanks for the heads up, done. |
fc12044 to
735252b
Compare
|
documentation PR added in symfony/symfony-docs#11314 |
fabpot
requested changes
Apr 6, 2019
xabbuh
requested changes
Apr 6, 2019
src/Symfony/Component/Form/Extension/Core/DataTransformer/StringToFloatTransformer.php
Outdated
Show resolved
Hide resolved
src/Symfony/Component/Form/Extension/Core/DataTransformer/StringToFloatTransformer.php
Outdated
Show resolved
Hide resolved
src/Symfony/Component/Form/Extension/Core/DataTransformer/StringToFloatTransformer.php
Outdated
Show resolved
Hide resolved
yceruto
approved these changes
Apr 6, 2019
src/Symfony/Component/Form/Extension/Core/DataTransformer/StringToFloatTransformer.php
Outdated
Show resolved
Hide resolved
src/Symfony/Component/Form/Extension/Core/DataTransformer/StringToFloatTransformer.php
Outdated
Show resolved
Hide resolved
|
Well, I guess that duplicated reviews will happen all the time, I'm sorry :) |
735252b to
a99ad37
Compare
a99ad37 to
3f25734
Compare
chalasr
approved these changes
Apr 6, 2019
fabpot
approved these changes
Apr 6, 2019
|
Thank you @webmozart. |
fabpot
added a commit
that referenced
this pull request
Apr 6, 2019
…chussek) This PR was merged into the 4.3-dev branch. Discussion ---------- Add "input" option to NumberType | Q | A | ------------- | --- | Branch? | master | Bug fix? | no | New feature? | yes | BC breaks? | no | Deprecations? | no | Tests pass? | yes | Fixed tickets | #24793 | License | MIT | Doc PR | TODO This PR replaces #24793 in (partially) fixing how Doctrine's DECIMAL type is handled by the Form component. Previously, DECIMAL was mapped to the regular NumberType. That confuses Doctrine's change detection, depending on the DB platform. Examples: | DB | DB value | Doctrine entity before submit | Form input | Doctrine entity after submit | --- | --- | --- | --- | --- | SQLite | 8.000 | '8' | 8 | 8 | SQLite | 8.123 | '8.123' | 8.123 | 8.123 | PostgreSQL | 8.000 | '8.000' | 8 | 8 | PostgreSQL | 8.123 | '8.123' | 8.123 | 8.123 The value in the Doctrine entity changes before and after submit. Hence Doctrine believes an update is necessary. This PR introduces an `input` option to NumberType (similar to DateType), that can be set to `'number'` (default) or `'string'`. If set to `'string'`, the conversion is as follows: | DB | DB value | Doctrine entity before submit | Form input | Doctrine entity after submit | --- | --- | --- | --- | --- | SQLite | 8.000 | **'8'** | 8 | **'8.000'** | SQLite | 8.123 | '8.123' | 8.123 | '8.123' | PostgreSQL | 8.000 | '8.000' | 8 | '8.000' | PostgreSQL | 8.123 | '8.123' | 8.123 | '8.123' You see that this does not completely solve this issue for SQLite. However, @Ocramius and I agree that this is something to be fixed by Doctrine, since Doctrine is providing the database abstraction. That fix should be done in the SqlitePlatform object in Doctrine as part of another PR and should be backwards compatible with the current Doctrine version (i.e. opt in via configuration). Compared to #24793, this PR does not introduce a new type but instead makes the NumberType more flexible. Also, this PR does not introduce the `force_full_scale` option since that should be solved by Doctrine as described above. Commits ------- 3f25734 Added new option "input" to NumberType fb2b37a add force_full_scale option to handle all cases 40f2512 [DoctrineBridge] Add decimal form type
wouterj
added a commit
to symfony/symfony-docs
that referenced
this pull request
Apr 7, 2019
This PR was merged into the master branch. Discussion ---------- document the input option of the NumberType see symfony/symfony#30893 #FOSSHackathons #EUFOSSA Commits ------- c004dc5 document the input option of the NumberType
Merged
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR replaces #24793 in (partially) fixing how Doctrine's DECIMAL type is handled by the Form component.
Previously, DECIMAL was mapped to the regular NumberType. That confuses Doctrine's change detection, depending on the DB platform.
Examples:
The value in the Doctrine entity changes before and after submit. Hence Doctrine believes an update is necessary.
This PR introduces an
inputoption to NumberType (similar to DateType), that can be set to'number'(default) or'string'. If set to'string', the conversion is as follows:You see that this does not completely solve this issue for SQLite. However, @Ocramius and I agree that this is something to be fixed by Doctrine, since Doctrine is providing the database abstraction.
That fix should be done in the SqlitePlatform object in Doctrine as part of another PR and should be backwards compatible with the current Doctrine version (i.e. opt in via configuration).
Compared to #24793, this PR does not introduce a new type but instead makes the NumberType more flexible. Also, this PR does not introduce the
force_full_scaleoption since that should be solved by Doctrine as described above.