I think keeping Keyword in seprate entity will be slower.... At time of writing you will be writing lots of entity instead of just one You will be worrying about how keyword will be mapped to each entity... iether by having a list of Keys in Keyword entity or specifying one to on emapping where keyword will be repeated.... If you want to get all entities which have some keywoprd and then sort by some field will cause you lots of in memory opeartion..first fetch keyword entity then get actual cnityt then sort it...
On the otherhand List,Set property will be indexed too,and searching with in entity ort in anotehr entity its same..... and this indexing is similar to a normal string indexing.. If you want to get all entities which have some keywoprd and then sort by some field , then you just need a composite index and it works.... its just read nad write for seprate entity will be more then a single entity. I would love to hear your thought as how you thought that single entity solution will be slower On Mon, Aug 29, 2011 at 7:40 PM, Nichole <[email protected]> wrote: > In addition to the above, I'd say you might want to make new "keyword" > entities for each > keyword and store the reference/key to the original entities instead > of storing your keywords > as a list of properties in your original entity. A list of strings is > stored implicitly as > an embedded table so will be slower to search for than searching for a > keyword property > in a separate entity - this later is indexed by the framework. > > > On Aug 29, 4:01 am, Ravi Sharma <[email protected]> wrote: > > Lets say you have book "Harry potter" > > If you want to search this withH or Ha Har Harr then this facility > provided > > by google app engine, instead of Like use startWith . > > > > Else if you really want to search it with "arry" or "rry" basically any > word > > in it, then you may saev every book name as Set<String> (Not List avod > > duplicates) > > save following strings in Set and you will be bale to search it... > > H > > A > > R > > Y > > HA > > AR > > RR > > RY > > HAR > > ARR > > RRY > > HARR > > ARRY > > HARRY > > > > Ravi. > > > > On Mon, Aug 29, 2011 at 11:56 AM, J.Ganesan <[email protected] > >wrote: > > > > > > > > > > > > > > > > > Why don't you consider splitting the keywords and maintaining a > > > memcache-resident HashMap<String,id> ? > > > > > J.Ganesan > > >www.DataStoreGwt.com > > > > > On Aug 26, 9:25 pm, realdope <[email protected]> wrote: > > > > Hi, > > > > > > I know that you cannot do a "LIKE" clause in BigTable. How do you get > > > around > > > > this issue? > > > > > > Suppose I'm making a book database, and I want to implement a search > > > > function that compares titles against a random string. What is a > > > plausible > > > > mechanism with which to do so? > > > > > > Any help would be appreciated! > > > > > -- > > > You received this message because you are subscribed to the Google > Groups > > > "Google App Engine for Java" 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-java?hl=en. > > -- > You received this message because you are subscribed to the Google Groups > "Google App Engine for Java" 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-java?hl=en. > > -- You received this message because you are subscribed to the Google Groups "Google App Engine for Java" 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-java?hl=en.
