> I'm okay with that constraint. My point is that if the application > has an admin console or an admin user, one can write a query that runs > across multiple datastores by writing code that accesses said > datastores through their admin consoles and/or users.
For the admin console, I'm saying you can only use this feature to run against each datastore in isolation. Pick the datastore, run the query. It's fair to say the admin console security model is another problem that GAE needs to sort out (e.g. http://code.google.com/p/googleappengine/issues/detail?id=91), but I would hope that when it is sorted out, I can assign admin rights on different data stores to different users in my organisation. For the admin user option, I am expecting that the admin user is unique to each data store, not one admin user for all customers. The picture I am painting is that you administer your customer data instances individually, not as an aggregate. I want to be able to make a statement like this about my application running on GAE (note especially the data security section at the bottom) http://www.rallydev.com/products/deployment_solutions/security/ And I can't do that if administrators can run ad-hoc unsecured queries across customer data stores. (well, maybe they are secured, but only by your application code) And finally - I am looking for features that allow me to give my customers confidence, not erode it. Saying that their data is partitioned from other customer's achieves that goal. That doesn't mean their data is perfectly safe - there would be any number of other means by which their data could be exposed to their competitors, but I can guarantee them that they their business plan is not going to suddenly appear on the welcome screen of a competitor due to a bug in my application code. The cited bug is a perfect example of this sort of thing actually happening, and of a situation that would be closed off with effective data partitioning. Do you agree that the cited bug would not occur with strict data partitioning, and could occur if issue 106 was actioned? If you are looking for a distinction, then this is it. To be perfectly clear, I see this bug as an example of multiple customers having their data exposed to multiple other customers - this is not a bug that would occur by someone making a mistake in admin console (when you can only query customer datastores in isolation). It seems to me you are saying that if there is *any* mechanism that could compromise customer data, then why bother worrying about it? There is a *lot* of work for GAE to do to get to the point where an app on their infrastructure can make a claim like that - e.g. I can't believe only 6 people have starred this issue for example - http://code.google.com/p/googleappengine/issues/detail?id=501 I suspect it is because people only look at the first page of issues - which completely debunks the idea that Google should be using stars in its issues list to prioritise its work schedule. On Dec 22, 4:47 pm, Andy Freeman <[email protected]> wrote: > > > Are you ok with the constraint that a query can not be run across > > multiple data stores? If we can agree on that, then I'd say we are > > doing pretty well. > > I'm okay with that constraint. My point is that if the application > has an admin console or an admin user, one can write a query that runs > across multiple datastores by writing code that accesses said > datastores through their admin consoles and/or users. > > No, such a query doesn't run in the application itself. However, a > query in an application that validates the user, determines which > datastore to use, and then runs all queries within that datastore also > doesn't access multiple datastores even if it does use an API feature > that could be used to access multiple datastores if said application > were written differently. > > I still have no interest in running a query across multiple datastores > and have never suggested otherwise. > > I'm trying understand why a feature that lets the application > programmer determine which datastore to use is an unacceptable way to > support "one code base, customer-specific datastores" if it's okay to > have an admin console and/or applications that have an admin user. > > Yes, it's convenient to have google manage all login stuff, but that > means that you don't have any control. If they're your customers.... > > On Dec 22, 4:25 am, hawkett <[email protected]> wrote: > > > > > 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. > > > Issue 106 proposes '...cross app queries using the db APIs only' - > > which to me means you can easily introduce a bug like the one > > originally posted - i.e. querying across two customer's data stores. > > Apologies if I understood your responses to be in support of this > > approach when they were not. Perhaps you could elaborate your use > > case in a little more detail. > > > Are you ok with the constraint that a query can not be run across > > multiple data stores? If we can agree on that, then I'd say we are > > doing pretty well. > > > For accessing another application's data store from your code, I would > > (and have) recommended exposing an API that you can access via HTTP. > > I believe this is what Google has suggested in this post > > >http://groups.google.com/group/google-appengine/browse_thread/thread/... > > > which is quoted in Issue 106. > > > If you do have a use case where you do want/need to run queries across > > customer data stores, then I would have that customer data in the same > > data store - i.e. what do you need the partition for in the first > > place? > > > Unfortunately the idea of a data partition and an application > > partition are the same thing at the moment with GAE, so perhaps you > > need the partition for quota and billing purposes, which forces you to > > have separate data stores when you don't want them. In that case I > > would raise a feature request for multiple applications to be able to > > share a single data store - would this satisfy what you are trying to > > achieve? > > > On Dec 22, 3:03 am, Andy Freeman <[email protected]> wrote: > > > > 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 <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 > > ... > > 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 [email protected] 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 -~----------~----~----~----~------~----~------~--~---
