Who are you quoting? The Google admin console should not be capable of querying across multiple customer data stores. I repeat - application code can not execute a query across multiple customer data stores - did I offer a distinction somewhere? Admin console *would* allow you to run queries against each of your customer data stores in isolation. I expect it would use a common, non-public, platform API (i.e. making data security part of the platform) to access the logical partitions.
What is your use-case? You use the example of maintenance and fixes on behalf of customers - when would that require querying across two customer's data stores? It's a recipe for disaster. On Dec 21, 11:53 pm, Andy Freeman <ana...@earthlink.net> wrote: > 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 > > ... > > read more » --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
