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

Create a new layer fails with Numeric Overflow exception #247

Open
StefanVanDyck opened this issue Sep 5, 2024 · 2 comments
Open

Create a new layer fails with Numeric Overflow exception #247

StefanVanDyck opened this issue Sep 5, 2024 · 2 comments

Comments

@StefanVanDyck
Copy link

StefanVanDyck commented Sep 5, 2024

Creating a new layer sometimes fails with the following error:

java.lang.Exception: exception just for purpose of providing stack trace
org.springframework.dao.DataIntegrityViolationException: could not execute statement; SQL [n/a]; nested exception is org.hibernate.exception.DataException: could not execute statement
Caused by: org.postgresql.util.PSQLException: ERROR: numeric field overflow

This is caused by incorrect parsing of the floating point numbers of the bounding box returned by geoserver.
It only happens when setting the language to in our case nl_BE.
This causes the grails i18n to change the number format locale to use a different decimal separator.
A value of 5.911109415203301 therefor becomes 5.068749233044934E15, causing an overflow.

Looking at a way to properly parse the bounding box values without being affected by the users locale.
Will create a PR to fix, current workaround is just to make sure we switch to English.

@StefanVanDyck
Copy link
Author

Seem to have pinpointed where the number conversion fails.

The values in that map are strings, calling the setter on the Grails Entity converts them to number that are considering the locale, set in the front-end. Causing 5.911109415203301 to become 5.911109415203301E15.

StefanVanDyck added a commit to StefanVanDyck/spatial-service that referenced this issue Oct 24, 2024
@StefanVanDyck
Copy link
Author

Created a proposal for a simple workaround:
#251

It was getting very frustrating, making sure we always had the correct language selected when administering the layers.

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

No branches or pull requests

1 participant