computing entity changeset fails if property is typed decimal -> float #7441

New Issue

admin · 2026-01-22T15:51:43+01:00

admin commented

2026-01-22 15:51:43 +01:00

Originally created by @forgie1 on GitHub (Nov 22, 2024).

Bug Report

Version | 2.19.8

Summary

	/**
	 * @var float
	 * @ORM\Column(type="decimal", precision=16, scale=8, options={"default"=0.0})
	 */
	private float $price = 0.0;

While EM::flush() this entity will be always considered changed, see generated changeset:

'price' => array
    0 => '0.00000000'
    1 => 0.0

Current behavior

Unchanged decimal property of entity with float type is always considered changed.
If there is not float type, everything works just fine:

	/**
	 * @var float
	 * @ORM\Column(type="decimal", precision=16, scale=8, options={"default"=0.0})
	 */
	private $price = 0.0;

Expected behavior

If property was not changed, do not consider it changed.

How to reproduce

Calling EM::persist($entity) and than EM::flush($enitty) see a description above.

Originally created by @forgie1 on GitHub (Nov 22, 2024). ### Bug Report Version | 2.19.8 #### Summary ``` /** * @var float * @ORM\Column(type="decimal", precision=16, scale=8, options={"default"=0.0}) */ private float $price = 0.0; ``` While EM::flush() this entity will be always considered changed, see generated changeset: ``` 'price' => array 0 => '0.00000000' 1 => 0.0 ``` #### Current behavior Unchanged decimal property of entity with float type is always considered changed. If there is not float type, everything works just fine: ``` /** * @var float * @ORM\Column(type="decimal", precision=16, scale=8, options={"default"=0.0}) */ private $price = 0.0; ``` #### Expected behavior If property was not changed, do not consider it changed. #### How to reproduce Calling `EM::persist($entity)` and than `EM::flush($enitty)` see a description above.

admin closed this issue

2026-01-22 15:51:43 +01:00

admin commented

2026-01-22 15:51:43 +01:00

@derrabus commented on GitHub (Nov 22, 2024):

Decimals are mapped to strings. The "change" happens because you use a native type float. Change it to string and you're good.

@derrabus commented on GitHub (Nov 22, 2024): Decimals are mapped to strings. The "change" happens because you use a native type `float`. Change it to `string` and you're good.

admin commented

2026-01-22 15:51:44 +01:00

@fnagel commented on GitHub (Dec 10, 2024):

Similar issue here (started with 2.17.x).

Dump question: its a float value so why use a string for it? Feels wrong to me to use a string when its actually a float.

@fnagel commented on GitHub (Dec 10, 2024): Similar issue here (started with 2.17.x). Dump question: its a float value so why use a string for it? Feels wrong to me to use a string when its actually a float.

admin commented

2026-01-22 15:51:45 +01:00

@michaljusiega commented on GitHub (Dec 10, 2024):

Using FLOAT type instead of DECIMAL keeps value as float. Try it ;)

@michaljusiega commented on GitHub (Dec 10, 2024): Using `FLOAT` type instead of `DECIMAL` keeps value as float. Try it ;)

admin commented

2026-01-22 15:51:45 +01:00

@fnagel commented on GitHub (Dec 10, 2024):

Thanks for the hint!

This will change my DB field from NUMERIC(9, 6) to DOUBLE PRECISION. I'm using this for lat/lng values which are normally defined as decimal. Seems using FLOAT (which results in DOUBLE PRECISION) is a little too much precision for what I need. Maybe smallfloat would work (but its not available in v3.9)?

https://stackoverflow.com/questions/159255/what-is-the-ideal-data-type-to-use-when-storing-latitude-longitude-in-a-mysql/25120203#25120203
https://stackoverflow.com/questions/1196415/what-datatype-to-use-when-storing-latitude-and-longitude-data-in-sql-databases

@fnagel commented on GitHub (Dec 10, 2024): Thanks for the hint! This will change my DB field from `NUMERIC(9, 6)` to `DOUBLE PRECISION`. I'm using this for lat/lng values which are normally defined as decimal. Seems using `FLOAT` (which results in `DOUBLE PRECISION`) is a little too much precision for what I need. Maybe `smallfloat` would work (but its not available in v3.9)? https://stackoverflow.com/questions/159255/what-is-the-ideal-data-type-to-use-when-storing-latitude-longitude-in-a-mysql/25120203#25120203 https://stackoverflow.com/questions/1196415/what-datatype-to-use-when-storing-latitude-and-longitude-data-in-sql-databases

admin commented

2026-01-22 15:51:45 +01:00

@derrabus commented on GitHub (Dec 10, 2024):

Dump question: its a float value so why use a string for it? Feels wrong to me to use a string when its actually a float.

A decimal is not a float. https://3v4l.org/M5MuY

@derrabus commented on GitHub (Dec 10, 2024): > Dump question: its a float value so why use a string for it? Feels wrong to me to use a string when its actually a float. A decimal is not a float. https://3v4l.org/M5MuY

admin commented

2026-01-22 15:51:45 +01:00

@fnagel commented on GitHub (Dec 11, 2024):

@derrabus That makes sense, thanks for pointing out! I found this beautiful website could help understand better whats the issue here: https://floating-point-gui.de/

@fnagel commented on GitHub (Dec 11, 2024): @derrabus That makes sense, thanks for pointing out! I found this beautiful website could help understand better whats the issue here: https://floating-point-gui.de/

admin referenced this issue

2026-01-22 16:07:44 +01:00

[PR #7441] $hydrationMode throughout can be a string as well as int (for custom modes) #10495

Sign in to join this conversation.

Branches Tags

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: doctrine/archived-orm#7441