The distinction between "application code that can access multiple datastores" and "code that can access multiple datastores" seems strained at best.
If there's code that can get to a user's data (and both the admin console and an admin user are code that can get to the user's data), does it really matter what you call it? On Dec 21, 3:15 pm, hawkett <hawk...@gmail.com> wrote: > Via the admin console. Google provides this application code, and it > is common - part of the platform offering. This is one possibility. > Another is that an admin user for that customer is made available to > you for administration purposes. You could initialise the customer > data space with this user profile. It may depend how you map the > authenticated entity to logical identities in your application. > Whichever, you do not have application code capable of querying across > customer data stores, because the platform does not allow it. > > On Dec 21, 10:49 pm, Andy Freeman <ana...@earthlink.net> wrote:> As I > promised, now I'm going to ask how you plan to do maintenance and > > fixes on behalf of your customers if you can't get to their data. > > > If you have access to the customer's data, they're trusting your code > > and Google is not protecting their data. > > > On Dec 21, 2:13 pm, hawkett <hawk...@gmail.com> wrote: > > > > > 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. > > > > If data segregation is a fundamental feature of the platform, then it > > > is inherently more trustable that N pieces of application code all > > > attempting the same thing. Me saying 'My code will keep your data > > > private' carries nothing like the weight that Google saying 'It is not > > > possible to run a query across two data stores' does. I would only > > > need to say 'Your data will be stored in a separate partition', and > > > that has tangible meaning to the customer from a data security > > > perspective. They are then placing their trust more in Google for > > > this feature than in my application. > > > > From a maintenance, reliability, trustability, transparency etc. > > > perspective, moving a common feature (especially a security feature) > > > from the application layer to platform layer is a major advantage, and > > > something a good architecture should always try to achieve. > > > > I want as little application code as possible to express my > > > application. This is already one of the key wins of the GAE platform, > > > and moving something as fundamental as data partitioning out of the > > > application platform will enhance this capability. > > > > On Dec 21, 5:55 pm, Andy Freeman <ana...@earthlink.net> wrote: > > > > > > 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 -- 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 -~----------~----~----~----~------~----~------~--~---
