Closed mgom closed 12 years ago
That's a GeoDjango limitation (not supporting distance on MySQL). I've often thought about making GeoDjango completely optional because it doesn't make sense for all projects, especially if you just want basic city listings. We could implement our own crude distance function, but it would be slow compared to that of GeoDjango.
i think it can be relevant to have full support mysql even with a workaround which can affect performances because distance() is only used at the import stage in this case (so it should be acceptable)
On Tue, Dec 6, 2011 at 7:20 PM, Ben Dowling < reply@reply.github.com
wrote:
That's a GeoDjango limitation (not supporting distance on MySQL). I've often thought about making GeoDjango completely optional because it doesn't make sense for all projects, especially if you just want basic city listings. We could implement our own crude distance function, but it would be slow compared to that of GeoDjango.
Reply to this email directly or view it on GitHub: https://github.com/coderholic/django-cities/issues/21#issuecomment-3036313
Hi, I committed a workaround in my fork, please give it a try. I don't have mysql to test but the workaround gives the same results in postgres (all but 1 district find the same city).
Hi
it works fine for me thanks !
On Tue, Dec 6, 2011 at 10:18 PM, Kometes < reply@reply.github.com
wrote:
Hi, I committed a workaround in my fork, please give it a try. I don't have mysql to test but the workaround gives the same results in postgres (all but 1 district find the same city).
https://github.com/Kometes/django-cities/zipball/master
Reply to this email directly or view it on GitHub: https://github.com/coderholic/django-cities/issues/21#issuecomment-3038911
It appears that mysql backend doesn't have distance() function, which is called during import process in some cases
Could we have a workaround to handle it ?
because of that, we can't sanely use mysql....