You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This is unlikely to affect 99% of developers, but just throwing it out there as a similar issue caught me out before 🙃
The TarfinLabs\LaravelSpatial\Types\Point class treats latitude/longitude as a float. Most PHP installations will be able to handle up to 11 decimal places (but the precision can vary in php.ini).
However, the POINT type in MySQL supports up to 25 bytes of resolution. So if this package is used against any existing high-precision POINT values, it would lose data when saving the model back to the database.
I think the correct approach would be to use protected string $lat; in the Point class, and construct it with __construct(string|float $lat = 0 ...) etc... The getLat(): float method would still automatically cast as a float before returning, but the toPair() method should be changed to use the original string values of the properties. This would ensure the full precision is persisted back to the database by the LocationCast class.
Again, unlikely to affect most people — just worth mentioning for best practice 👍
The text was updated successfully, but these errors were encountered:
This is unlikely to affect 99% of developers, but just throwing it out there as a similar issue caught me out before 🙃
The
TarfinLabs\LaravelSpatial\Types\Point
class treats latitude/longitude as afloat
. Most PHP installations will be able to handle up to 11 decimal places (but the precision can vary inphp.ini
).However, the
POINT
type in MySQL supports up to 25 bytes of resolution. So if this package is used against any existing high-precisionPOINT
values, it would lose data when saving the model back to the database.I think the correct approach would be to use
protected string $lat;
in thePoint
class, and construct it with__construct(string|float $lat = 0 ...)
etc... ThegetLat(): float
method would still automatically cast as a float before returning, but thetoPair()
method should be changed to use the original string values of the properties. This would ensure the full precision is persisted back to the database by theLocationCast
class.Again, unlikely to affect most people — just worth mentioning for best practice 👍
The text was updated successfully, but these errors were encountered: