Not all applications' data can be modeled such that that each piece of data belongs to one and only one user.
On Oct 7, 10:24 pm, "Ian Lewis" <[EMAIL PROTECTED]> wrote: > 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 google-appengine@googlegroups.com 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 -~----------~----~----~----~------~----~------~--~---
