> One suggests it > should be impossible for the same piece of code to access separate > datastore instances, the other suggests that this is a desirable > feature. I don't see how you consider them the same - are you saying > that you can't see how the cited bug is caused by multiple customers > sharing the same data space?
Right now, separate applications have separate code and separate datastores. If management issues are the only obstacle to using separate applications for different users, that tells us that separate datastores do not share the same data space for these purposes. Yes, there is the issue that application code has to manage the customer-specific datastores, but if multiple customers are hosted on the same hardware, someone's code has to do that work and it's unclear why application code can't be part of that process. If the response is that application code isn't trusted by customers to maintain separation, I'm going to ask how you do maintenance and fixes on their behalf. Note that customers don't write application code in this model, whether they use separate applications or one that uses customer- specific datastores. Here's how it would work. Customer accesses system, system figures out which datastore to use, system acts upon datastore on customer's behalf using application code. Note that this is exactly the same way that any scheme with shared hardware would accomplish the same separation. The only difference is whether the "figure out" is done by Google or by you. On Dec 20, 7:30 pm, hawkett <hawk...@gmail.com> wrote: > Andy - they are essentially mutually exclusive. One suggests it > should be impossible for the same piece of code to access separate > datastore instances, the other suggests that this is a desirable > feature. I don't see how you consider them the same - are you saying > that you can't see how the cited bug is caused by multiple customers > sharing the same data space? I don't understand your perspective - > the difference seems utterly obvious to me. > > I *can* see that depending on the use case, one or the other would be > good. In most cases I would say access between different customer > data spaces is better modelled through an API accessible by HTTP. > > Perhaps you have a different use case where you have the same app > deployed multiple times and do not have the customer data segregation > issue, but that is not what the original poster is talking about. The > original poster is *clearly* and *unambiguously* talking about > avoiding bugs like the one cited, and doing so through a low level > data partition. > > On Dec 21, 12:30 am, Andy Freeman <ana...@earthlink.net> wrote: > > > > > Neither of the cited discussions nor your comments explain why it's > > different that Bill's "access to separate datastore" request. In > > fact, his request is essentially "at least allows mapping a single > > datastore partition to the authenticated entity". > > > There are some issues with accounting, but if your app can do its > > accounting in the user's datastore, you get that too. > > > On Dec 20, 5:09 am, hawkett <hawk...@gmail.com> wrote: > > > > This is a required feature for a commercial SaaS/PaaS offering, and is > > > not the same as Bill's issue in previous thread entry (Issue 06). > > > This discussion can help you understand why - > > > >http://blogs.zdnet.com/service-oriented/?p=1236 > > > > as can bugs like this > > > >http://forum.assembla.com/forums/3/topics/256 > > > > We need it to be as close to impossible for one customer's data to be > > > made available to another customer, without having to deploy a new > > > instance of the application. > > > > Let's call it data segregation. A concept of 'virtual instances' > > > would be a possible approach - so we can aggregate billing & quota > > > stats across multiple instances, and also identify individual instance > > > billing and quota. > > > > Use Case: > > > 1. Customer comes to my site > > > 2. Clicks the 'Sign up now' button > > > 3. Enters their details > > > 4. Starts using the system > > > > You can't get a more 'core' use-case than that for a SaaS/PaaS > > > platform. Notice there is no requirement to deploy a new version of > > > the app for this customer. The system spawns a virtual instance of > > > the app - or at least allows mapping a single datastore partition to > > > the authenticated entity. You coudl extend it by allowing multiple > > > datastores per authenticated entity and choosing the appropriate one > > > at authentication time. > > > > The key requirement is that we can on-board a customer without manual > > > intervention, and accurately understand a single customer's usage > > > profile. Data corruption for one customer does not equal data > > > corruption for another customer. > > > > This feature is in some ways the *opposite* of the feature request > > > identified by the previous poster - we *do not* want to be able to > > > access data in another partition - even if we tried to, and especially > > > via a bug in our code. > > > > Here it is, please star it :) > > > >http://code.google.com/p/googleappengine/issues/detail?id=945 > > > > Any chance someone at Google has something to say about it? > > > > Thanks, > > > > Colin > > > > On Dec 20, 5:17 am, Ben Bishop <leo...@gmail.com> wrote: > > > > > Not sure what you mean by "in case something happens" - your app and > > > > its datastore is served by the same network of servers that serve > > > > other apps, so separate accounts won't help, (unless you're going > > > > against the Terms of Service, running the risk of having an account > > > > banned). > > > > > One App Engine account can have 10 apps, each with its own datastore > > > > and quota. You could deploy a single app's codebase to multiple app > > > > slots, simply by changing the app name in the app.yaml for each > > > > instance. That way you could test on a production "test" app or one of > > > > your client apps before rolling out updates to your other client apps. > > > > > You still maintain a single codebase, each client app has its own > > > > datastore, and you can control updates. > > > > > On Dec 20, 2:05 am, GTako <tako.ko...@gmail.com> wrote: > > > > > > Hi, is it possible to maintain under 1 application, multiple > > > > > datastores that each datastore will be as if it is different app > > > > > engine account? > > > > > for example: i have a web application that should serve 2 companies, A > > > > > and B. I would want to open a google app engine account for the web > > > > > application files. the datastores for A and B could be 2 different > > > > > deployments under the same app engine account or under seperate > > > > > accounts. now assume i have N companies. what should i do? > > > > > the reason for seperation is that i dont want the datastores will be > > > > > dependent and under same account in case soemthing happens. please > > > > > advise.- Hide quoted text - > > > > - Show quoted text -- Hide quoted text - > > - Show quoted text - --~--~---------~--~----~------------~-------~--~----~ 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 google-appengine+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/google-appengine?hl=en -~----------~----~----~----~------~----~------~--~---
