this is the biggest patch in this series. I use it on around 10 installations (although with minor modifications), so it works.
The problem is this: If you have 10000 tt_address records, and you need to find the 50 that are within the 10-mile-radius, wecmap_pi3 currently fetches ALL records from the DB (which is OK so far), calls wecmap_shared::render() on all of them, and THEN filters out whether the item is in the radius or not. Thus, 10000 cObj are generated which makes everything bloatingly slow. The solution here is to fetch the record, get the lat/long coordinates and calculate if the items are in the radius. If so, THEN render the cObjSingle.
In my case, I use it with tt_address and then store the lat/long infos in the tt_address table as well, for speedup purposes. This is not necessary though, so this part could go away. In class.wecmap_map.php there is a check in the new function whether the record has these fields or not, so it should work with other tables as well.
Also, this patch allows to sort your sidebar results by distance, adds another field "distance" so you also print out the distance to the searched entry (I quickly added this option flag, untested).
Please check this patch carefully, as it might break something, so this might be something for version 2.4 or 2.5. Also, documentation is missing, and I don't know this feature applies to pi1 and pi2 as well.
Christoph,
this is the biggest patch in this series. I use it on around 10 installations (although with minor modifications), so it works.
The problem is this: If you have 10000 tt_address records, and you need to find the 50 that are within the 10-mile-radius, wecmap_pi3 currently fetches ALL records from the DB (which is OK so far), calls wecmap_shared::render() on all of them, and THEN filters out whether the item is in the radius or not. Thus, 10000 cObj are generated which makes everything bloatingly slow. The solution here is to fetch the record, get the lat/long coordinates and calculate if the items are in the radius. If so, THEN render the cObjSingle.
In my case, I use it with tt_address and then store the lat/long infos in the tt_address table as well, for speedup purposes. This is not necessary though, so this part could go away. In class.wecmap_map.php there is a check in the new function whether the record has these fields or not, so it should work with other tables as well.
Also, this patch allows to sort your sidebar results by distance, adds another field "distance" so you also print out the distance to the searched entry (I quickly added this option flag, untested).
Please check this patch carefully, as it might break something, so this might be something for version 2.4 or 2.5. Also, documentation is missing, and I don't know this feature applies to pi1 and pi2 as well.
Thanks for the consideration! Benni.
http://svn.webempoweredchurch.org/attachments/184/wec_map_performance_on_radiussearch.patch