Good work. I like this idea and it seems to be the most flexible solution for complex search at the moment. Anyone care to comment on performance and bottlenecks? What are the problems with this solution?
One that I can think of is that the database will become huge because of all word combinations being stored, but I'm not sure how problematic this will be. I'm quite sure that this method wouldn't be effective when searching in large text fields, because the list of keywords and word combinations would be way to large, but for shorter string-searching I feel it should work, though I'm not sure exactly how much larger the database will become. Are there any performance issues when retrieving entities by filtering on lists? Is it slow or CPU heavy? There's something in the docs about a maximum of 30 sub-queries when filtering on lists, but I never really understood it. On 23 Feb, 17:41, Steffen 'stefreak' Neubauer <[email protected]> wrote: > I hacked something together, with google-like syntax, but its not > really satisfying my needs because of index.yaml-problems. But here is > it, maybe its helpful to someone else. > Possible search terms are: > debian lenny > "debian lenny" > debian -lenny (this is not really working as expected at the moment) > > models.py:http://nopaste.biz/67482 > views.py:http://nopaste.biz/67481 > > Example:http://stefreakstest.appspot.com/ > > signature.asc > < 1KVisaHämta --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Google App Engine" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/google-appengine?hl=en -~----------~----~----~----~------~----~------~--~---
