5

According to https://developers.google.com/fusiontables/docs/developers_reference OR operations are not allowed as part of filter conditions. So I'm trying to come up with a creative way to solve the following:

I have a fusion table backed google map with hundreds of places and want to filter it to only places that have 'tags' or a 'title' containing a search parameter.

Ideally I could just use the following as my filter condition:

tags CONTAINS IGNORING CASE 'searchterm' OR title CONTAINS IGNORING CASE 'searchterm'

But the fusion table API simply doesn't allow it. So what to do? Make 2 separate queries, then filter out the duplicates? That means I can't use the nice FusionTablesLayer pre-rendered tile functionality.

What would you do?

Tron
  • 693
  • 1
  • 6
  • 17

2 Answers2

3

A possible answer is to pre-render the data within the table. Essentially add another column which is an aggregate of tags and title. Then I only need to query the one 'tags_or_titles' column. Of course this means more data munging beforehand when I export the data into the fusion table and doesn't feel so nice and clean...

Tron
  • 693
  • 1
  • 6
  • 17
  • This is what I ended up implementing and really didn't take much work to pre-concatenate all the text into one column before sending it into the fusion table. It still bothers me that Fusion tables don't allow OR queries nor do they allow string concatenation. – Tron May 07 '12 at 15:09
2

How about adding a column to your table called "Show_In_Results",

then running two separate queries to update that column for each row of data based on whether the search term is found in the specific column or not.

UPDATE 'table_id'
SET Show_In_Results = 1

UPDATE 'table_id'
SET Show_In_Results = 1
WHERE tags CONTAINS IGNORING CASE 'searchterm' 

UPDATE 'table_id'
SET Show_In_Results = 1
WHERE title CONTAINS IGNORING CASE 'searchterm' and Show_In_Results <> 1

Then when you render your map layer:

SELECT 'columns' FROM 'table_id' WHERE Show_In_Results = 1
javram
  • 2,635
  • 1
  • 13
  • 18
  • Sorry, left out a key part of the second where query. Updated now. – javram May 04 '12 at 15:46
  • This would work and is a pretty creative way to work around the problem. The only reason I didn't go for it is that it puts extra latency on the (mobile intended) client although that's probably negligible. Also, I'm a little worried that if multiple requests happen in tandem from different clients you might get out-of-sync results. – Tron May 07 '12 at 15:07