> The maximum query length is 4kb. This implies the maximum number of > conditions depends on the structure of the query. At most you could > probably have around 200 terms.
Thank you for the answer, I see how this can limit my design and I will code accordingly. Considering the fact that my users may subscribe for alerts up to potentially thousands of words, I'll have to add more subscriptions. > We are still working to figure out the pricing. The cost will likely be > proportional to the number of matches x registered subscriptions BUT as I > said we are still working through this is still very tentative. It sounds > like the first is likely a better option simply because of the limitation in > terms of the number of terms. As we have more information on how the > pricing will work, we'll announce it. I'm not sure to fully understand the "number of matches x registered subscriptions". Say, for example, that I have a million registered subscriptions, but only 0,1% of them concentrate most of the match calls. Wouldn't the formula you posted above make these almost-never- used 99,9% remaining subscriptions make my prospective-search billing quotas skyrocket ? In other words, "idle/never matched" subscriptions would greatly increase the cost of those of the most active subscriptions that are matched on a regular basis. I picked exaggerated numbers on purpose, though some applications may be designed that way (including mine, hehe...). I never realized before that pricing formulas could influence code/ application design that much. Regards, -jbmusso -- 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.
