The documentation says that an entity group could be as large as a single user's data. It seems to me that to avoid the problem you are describing that it would be a good idea to do so. I have a feeling that the number of cases where you would need to update more than one user's data in a single transaction would be limited.
2008/10/8 Josh Heitzman <[EMAIL PROTECTED]> > > Assuming you can actually work around all of the limitation > simultaneously, considering the more things you work around the close > you come to the CPU time quota. > > It also is not completely accurate to state that the limitations are > there to make apps safe and scalable. For example transactions being > limited to a single entity group makes it very complicated (i.e. not > safe) to write code that needs to reliably update entities from > different groups (it isn't always possible to structure entity groups > such that everything that is needs to be updated for a request can be > all be in one entity group). > > Also given the roundness of the quotas, I find it very unlikely that > the quota numbers were choosen based on an in depth analysis or a > broad sampling of data, rather the being choosen fairly arbitrarily > (possibly based to some extent on what works for google's own apps). > > On Oct 7, 4:16 pm, Greg <[EMAIL PROTECTED]> wrote: > > Davew said it way back at the top - appengine's killer feature is > > scalability. That is what sets it apart from the other cloud systems > > out there, and it is also the root cause of most complaints (except > > the quotas, which will disappear when you get to pay for the service). > > > > For the application I'm working on, I'm happy to trade off lack of a > > relational database for the future gain of scalability. My guess is > > that most of you haven't had the nightmare of an application that > > suddenly became popular, and you had to become an expert at database > > replication, load balancing and multi-system maintenance overnight. > > It's a very stressful situation. > > > > So my advice is that if you don't need scalability, get a normal > > hosting account or EC3. Then you can have PHP, Ruby, MySQL, cron jobs, > > anything you want - problem solved. Oh, yes you are going to have to > > shell out a few buck a month. > > > > But if you do need scalability, then appengine is a godsend. The > > limitations are there to make it safe and scalable, not because Google > > wants to annoy you. You spend a little more time now working around > > the limitations, and save endless time later managing systems and > > capacity. > > > > And lastly, I believe that many of the complaints come from people > > just wanting a free hosting service, and not finding what they are > > used to. It would be a crying shame if Google listened to these people > > and turned appengine into a vanilla PHP/MySQL hosting service. > > Appengine is so much more... > > > > On Oct 7, 3:54 pm, Ross Ridge <[EMAIL PROTECTED]> wrote: > > > > > [EMAIL PROTECTED] wrote: > > > > One thing you have to remember it is not what Guido or the engineers > > > > want. If Google App Engine is to succeed it is what the customers > > > > want. If it is designed as you have stated it will never recoup what > > > > Google has spent so far let alone down the road. Google App Engine > has > > > > so many many limitations. Regardless if the limitations are by > design > > > > or not it is virtually unusable by 99% of all developers. Can Google > > > > make a business off the remaining 1%? > > > > > The question of whether Google can turn Google App Engine into a > > > profitable business doesn't depend on what percentage of developers > > > find it useful, but whether Google exploit a competive advantage. > > > Google could've started up a tradtional web hosting service using > > > popular SQL databases and other techonologies and created something > > > that would have had a much broader appeal. Any one could. That's the > > > problem. Google might be able to grab market share, but without > > > anything to distiguish themselves from their competitors, a best they > > > only get a marginal return on their investment. > > > > > We can only speculate on what Google business plan for GAE is, but it > > > seems pretty obvious to me that leveraging Google's own internal > > > technologies is at the heart of it. A number of limitations and > > > problems with GAE stem from technologies like Big Table, Google > > > Frontend and Google Apps. Another part of their plan appears to be > > > keeping support costs low, so you're not given much rope to hang > > > yourself (or others). If, in the long term, Google can't make a > > > business following this plan, if it doesn't give them enough a > > > competive advanage, then there's probably no way they can make the > > > kind profits from a hosting service that Google's investors expect. > > > > > (While it's not terribly relevent to this discussion, I suspect Google > > > has some other goals for GAE that don't deal directly with its > > > viability as a business. One is to educate programmers in the Google > > > way of doing things. I'm sure Google has been fustrated with tons of > > > amazing job applicants with advanced degrees, 10+ years of WWW > > > experience, and the inability work with anything but PHP and SQL. > > > Another is that they want to make even easier for people to create WWW > > > sites, the sort of small little sites that through AdWords/AdSense, > > > Google has made billions.) > > > > > Ultimately, what matters is what you want and what Google is willing > > > give you. It doesn't matter what 99% developers want. The are number > > > of problems and limitations with GAE that will be fixed. You can look > > > at the issue database to get and idea of what these are. However, > > > there are no timelines, so don't plan anything being fixed tommorow or > > > even a year from now. Many limitations will always be there. You're > > > never going to get all the functionality of an SQL database, nor will > > > GAE be suitable for computationally intensive tasks. > > > > > Look at a GAE, and see if it offers it what you want as it is now. If > > > it's close but not quite there maybe play around with it, maybe go so > > > far as making a proof of concept of something. On the other hand, if > > > GAE is far away from what you want, then walk away. GAE isn't for > > > you, and probably won't ever be. Maybe check back in a year or so, > > > but now you should be looking for another hosting solution. > > > > > Ross Ridge > > > --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
