I'm paraphrasing you. You've written repeatedly that a feature that allows an application to choose the datastore on which it operates can not be used for your purposes. The argument appears to be that an application that uses such a feature can theoretically access multiple datastores and is therefore unacceptable, even if that application is written so it validates the user and then chooses which datastore to access and only accesses one datastore after doing so.
However, you're happy if a user's data can be accessed through a google admin console or via an admin user. The reason that I find that distinction strained is that GAE applications and the google admin console can be driven programmatically. As a result, one can easily write code using those facilities that simultaneously accesses multiple datastores, which is your reason for rejecting the "choose which datastore to access" feature. > You use the example of maintenance and fixes > on behalf of customers - when would that require querying across two > customer's data stores? I never said or implied that it did. On Dec 21, 4:13 pm, hawkett <hawk...@gmail.com> wrote: > 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, > > ... > > read more »- 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 -~----------~----~----~----~------~----~------~--~---
