Oops sorry I missed the bit where you said you only used the SDK. I use snippet (bolding) to present Google-like search results. Being able to see where documents match my search keywords makes a big difference.
Yes, 3+ seconds is on production. My search results are returned via AJAX too, and I personally find the delay long enough to be very annoying. I really want GAE FTS to be good, because I have 2 webapps that use it and I don't want to waste time migrating search to an external service, but to me FTS is sufficiently broken that I'll have to move away at some point. More importantly, I suspect that FTS gets very little attention from developers and Googlers alike. I mean, the 2 problems that I mentioned are glaringly obvious, and yet no one raises it (as far as I know). If it takes Googlers between 1-3 years to fix/introduce highly requested features, it will take even longer to fix lightly used stuff like FTS. Here's hoping that a Googler responds to this thread and restores my faith, but I'm not holding my breath :) On Saturday, September 7, 2013 8:01:27 PM UTC+10, Kaan Soral wrote: > > I've never tried the feature on production, as I stated I've been using it > on SDK, for a long while now > Didn't try the bolding feature, wonder how it does the actual bolding and > how it can be of any use, since searchable stuff is generally seperate from > actual stuff and a manual bolding seems easier, if necessary, off topic > > Is 3+ seconds on production? If so, it indeed sounds extreme, however 3 > seconds is better than nothing, since my search requests are from ajax, 3+ > seconds wouldn't be so irritating (in comparison, overhead of an external > search service might be closer to 3 seconds too, or at least ~500ms) > > *And the reason I think it's beyond-awesome* > > In theory it works, it fills an empty spot, there are no appengine > alternatives to it, the search is satisfactory > Properties are great, syntax is easy and satisfactory, Document logic is > simple and well-thought, imo > The query logic is similar to db/ndb, I'm using it the same way I'm using > ndb queries, the cursor system is similar, same handlers are responding to > ndb and search queries > > When I first started using search, deep inside I hoped that it isn't as > awesome as it seems, and it isn't, since it's obviously not scalable, as > it's limited, otherwise it might even beat datastore in terms of > indexing/querying > > + The ranking system is great, don't remember how I utilized it, however > my search results appear by their ndb importance metric > > Thinking about it right now, the beyond is an overkill, but it is awesome, > *hoping the limitations disappear really soon* > > On Saturday, September 7, 2013 12:31:49 PM UTC+3, jon wrote: >> >> >> however the search index size limitation will prevent any decent use-case >>> of this *beyond-awesome feature* >>> >> >> May I ask why you think this is an awesome feature? I've been using FTS >> for a while now and I find that: >> >> - It's slow. It easily takes 3+ seconds to return search results. >> - Result snippet (bolding matching text) is broken. Try searching >> with just one word, and you'll find no bolding occurs. If you use two >> words, only the second is bolded. >> >> -- You received this message because you are subscribed to the Google Groups "Google App Engine" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/google-appengine. For more options, visit https://groups.google.com/groups/opt_out.
