Hi Andrea

Is the page about the Custom profile field types current with version 4.2 of the plugin? http://dontdream.it/bp-profile-search/custom-profile-field-types/

One of my extended profile fields is a zip code and I need to make the search return results within a distance from a given zip code.

I have an external table with the lat and lng of each zip code of my users, so this part is not the problem at all.

I manage to insert a “distance” select in the search form next to my zip, but I am afraid I am on the wrong track.

The correct approach is to define the zip field as a custom field, and apply a specific sql query to that custom field type?

SELECT user_id FROM {$bp->profile->table_name_data} WHERE value IN (…)

Thank you!

Hi Andrea

Sorry I didn’t get to thank you earlier. I got pretty intimate with BP Profile Search 4.2 this weekend, and the zip search was indeed rather easy with the ‘trick’ you suggested.

I modified some search fields in a similar fashion, like the search based on age that returns search results based on date of birth.

I do have a concern about performance and scalability. I will try to explain it. I have a database of 1000000 users. Let’s say that in most searches that will be performed, the first criteria is going to be gender: M/F.
Each search will thus compare first an array of 500000 user ids to the next criteria.

I think your bps_search function is doing the search criteria by criteria, in the order of the search form. I am afraid that this won’t scale too well.

Do you have thoughts about this?

Some thoughts/suggestions…

1) There is no hook at the end of the bps_search function. I thought that perhaps I could remove artificially from the search some criteria that I anticipate would be the most problematic with regards to size of the array returned, and apply them to the final $result (which could by then be very limited i.e. think depending on the search, after the location criteria, limited to 1-10% of my global population)

2) I could also perhaps combine a couple of criteria in MySQL, like the gender and location, and thus make MySQL work a tiny bit harder, but spare PHP from having to deal with large arrays, as gender/location combined will effectively return arrays much smaller than gender only

3) Would it make sense/be possible to reorder the criteria before combining them, so the arrays compared start with the smallest ones…? (whether I would have to make a judgement call and choose arbitrarily which criteria are more likely to be more divisive, or if there was a way to order them based on the size of each array… or… I am not sure how PHP handles large array intersects… could it make sense to trust PHP to do this effectively and do a multiple array intersect on all the arrays of user ids at the end…?)

What do you think?

Thank you!