Thanks Adam. While the dataset in this case is pretty small (I can't imagine a user adding *that* many different things to this field), I don't want to have an arbitrary and potentially confounding cutoff when matching. Further, if it's all done in JS, I'll have to (a) load and dump out a bunch of data from the datastore with every request and (b) maintain that list client-side as it changes across ajax requests by either (1) getting a new copy of the list with every request or (2) manually updating it with new items, spilling my logic for maintaining the list into two places.
My main concern is the large number of writes to enable in-word matches and the potentially large index that would result. Matching speed, as far as I can tell, should not be a problem because it's a single read over a sequential block of entities. I think I'm going to compromise a bit here and only enable beginning- of-word matches: "sa" would match "Sam" and "Sally" but not "Alyssa." That will dramatically reduce the number of writes, the size of the index and the number of matches. Thanks, Taylor On Dec 10, 12:32 pm, Adam <[EMAIL PROTECTED]> wrote: > I'd use javascript. > > Scriptaculous Autocompleter.Local > > Push the entire list of previously typed strings to the client on page > refresh. (Or keep the last N if the list gets too big). > > With appropriate flags the javascript will take care of mid-word > matching etc. > > If you try to do this kind of matching on the server it probably won't > be fast enough, and you'll have to deal with lots of edge cases where > you get the autocomplete response after the user has submitted the > form. > > A > > On Dec 9, 8:16 pm, Taylor Hughes <[EMAIL PROTECTED]> wrote: > > > Hi, > > > So I'm building an input field in my app that will give suggestions as > > a user types with things the user has previously entered. The strings > > will be relatively short (<25 characters probably), and I'd like to > > match any substring, e.g. typing "sa" might bring up "John Sanderson" > > as well as "Sam Smith." > > > I've implemented it a certain way, and I'm looking for thoughts/ > > suggestions/potential failings of the implementation if you have some > > time to take a look. > > > Right now, I have two db.Models: > > > class NameIndex(db.Model): > > index = db.StringProperty() > > names = db.StringListProperty() > > > class Name(db.Model): > > name = db.StringProperty() > > last_used_at = db.DateTimeProperty(auto_now_add=True) > > > When a name is entered, I check to see if an existing Name entity > > exists and simply update the last_used_at field if so. If not, I add > > the Name and also add NameIndex entries, one entry for the substring > > starting at every character position in the string to the end of the > > string: > > > "John Smith" becomes: > > > johnsmith > > ohnsmith > > hnsmith > > nsmith > > ... > > etc., each with a property pointing back to "John Smith" (and other > > matching entries if two full names have the same indexed substring). > > > Then, as a user types, I take the substring and look for NameIndex > > entries where index >= :substring and index < :substring + 'zzzz ...', > > which accurately returns the entries with a matching substring. > > > I have a couple of questions about this approach: > > > - Will this create too many entities? Is this something to worry > > about? > > - Is writing len(str) entries to the datastore with every new name > > going to be a problem? > > - Is there a better way? > > > Thanks for reading, > > > Taylor Hughes --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
