search

mysociety / fixmystreet

This is mySociety's popular map-based reporting platform: easy to install in new countries and regions
http://fixmystreet.org/
Other
515 stars 237 forks source link

Error with double precison in PostgreSQL #582

Closed vvergnolle closed 11 years ago

vvergnolle commented 11 years ago

Hi,

I have installed the plateform in a test version (local) and now I want to install it on a production server but I have an issue which I don't have in the test version of the install.

My test install is on debian wheezy and the production one is on debian squeeze.

Each time I want to load the page located at : /around?latitude=?;longitude=? I have a SQL issue with the latitude and longitude columns. It say's that the input is not ok : input synthax invalid for the double precision type.

Does someone has an idea ?

Versions:

Postgresql 8.4 Perl 5.10.1

I have tried to change the double precision type to a string but I have an error with the problem_find_nearby stored procedure and I prefer to not touch it.

I also notice that the output method Utils::truncate_coordinate return a virgule as separator but in my test installation this is not the case, the methode return a dot as a separator.

Even if I change it to return a number which have a virgule separator, the method doesn't use the number in the SQL query (it still showing the virgule separator).

Thanks by advance

dracos commented 11 years ago

Hi, sorry to hear you've had this problem. The output from Utils::truncate_coordinate should always be a string that uses a dot for its decimal point, not a comma.

Do you have the en_GB.UTF-8 locale installed in your production environment? Not having it installed (but having it in your test install) could perhaps lead to the problem you outline (this is mentioned on http://code.fixmystreet.com/install/ in passing). You can run locale -a to see what locales you have installed.

Hopefully that's all that's the problem. The code definitely works in other locales, so please don't try and change the database schema or anything like that - it will make it harder for you to update to get improvements we make to the code in future.

vvergnolle commented 11 years ago

Hi, thanks a lot, it was a locale issue.

With the en_GB locale it's working, it was not generated on my server.

For people who has the same issue. Just uncomment this line en_GB.UTF-8 UTF-8 in the file etc/locale.gen and just execute the locale-gen command.