Ok - I understand (maybe), I don't think it matches what 106 is asking
for though
It doesn't support 106, but that wasn't the goal.
The goal was to show that one could support application--driven
datastore choice with an appropriate amount of security.
The call to support 106 would be
Hi Joseph,
I've previously made this point here -
http://groups.google.com/group/google-appengine/browse_thread/thread/6319dceae6ec73e7/4d4d464c25537bda?lnk=gstq=#4d4d464c25537bda
- so Google - people really do recommend against GAE because your
rodmap is so impenetrable. Joseph, you may
Huh? How can you make a wrong call that doesn't have any
parameters?
Here's the application code:
{operations on application-wide datastore}
change_to_application_userstore() # note - no parameters
{operations on user-specific datastore}
{return to user}
Ok - I
Guys, I think you need to take a step back and look at this from a
higher level.
Appengine supplies you with an instance in a cloud that includes a
customized python set, and a BigTable backend. It does not support
multiple BigTable backends and design wise I doubt it ever will. There
comes a
How do you know how the current GAE code actually works?
I read the API docs - how do you manage it?
I'm not the one asserting that there are hard boundaries between GAE
datastores that the GAE run-time can't pierce.
Neither am I - I am asserting that there are hard boundaries that you
I guess one of us will be surprised then :) - I would be surprised if
gmail, sites, blogger, picassa, orkut etc. all operated in an open
space and avoided data exposure through code implemented in each of
those applications.
If the separation is by name and ordinary file access control, the
On Dec 30 2008, 3:14 pm, Andy Freeman ana...@earthlink.net wrote:
No, I would prefer GAE to implement the system completely, using
existing elements.
I was unaware of the weight that your preferences have.
Isn't that what a feature request is? Should I raise feature requests
for other
As it stands GAE does not allow cross data store queries,
and from my perspective that is an aspect of the security
architecture. 106 wants that aspect 'relaxed'.
How do you know how the current GAE code actually works?
I read the API docs - how do you manage it?
I'm not the one
The system in this case is the combination of the GAE platform and
an application running on said platform.
No, I would prefer GAE to implement the system completely, using
existing elements. How? In app.yaml, you specify that your
application supports mapping multiple google apps user
No, I would prefer GAE to implement the system completely, using
existing elements.
I was unaware of the weight that your preferences have.
I note that your implementation requires new elements, namely
additions to app.yaml.
It would allow some great additions, such as a
common billing and
Huh? You were requesting the ability to spawn a new datastore and to
have the login scheme for a given pile of application code pick the
datastore. The above is about methods for separating datastores and
whether the method for separating them should depend on how the
datastore is chose
I
They're trusting you with their data. Why should they trust your code
not to email all of the data they input to malicious people if they
can't trust you to write code that keeps their data separate enough
from other people's data?
Because one is a malicious attack, and one is a bug. From
You're hoping that the partitioning for a given datastore depends on
how google allows access to said datastore
Exactly - that is the feature request I am proposing. It seems
likely to me that GAE uses a data partitioning feature of BigTable
(maybe not, I don't know, but to me it seems the
In fact, given that Google already
have a data partitioning mechanism for applications, I wouldn't be
surprised if it was even lower level than the GAE platform, and part
of the BigTable implementation.
You're hoping that the partitioning for a given datastore depends on
how google allows
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
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
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
For the admin console, I'm saying you can only use this feature to run
against each datastore in isolation.
My point is that that's not true. If I have access to multiple admin
consoles (for maintenance reasons), I can combine the results that I
get from each of the consoles, effectively
No, I don't agree. Even if we ignore the admin console hole, strict
data partitioning is a fantasy in an environment where data lives on
the same hardware. The google code for handling multiple datastores
could go wonky. Or, their user login code could do the wrong thing.
I think you are
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
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
Apologies - the following fragment
'...moving something as fundamental as data partitioning out of the
application platform will enhance this capability.'
should read
'...moving something as fundamental as data partitioning out of the
application layer will enhance this capability.'
On Dec
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
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
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
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
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
You can just use separate tables for each customer. I haven't tried it
myself yet, so I don't know all the problems you will have to deal
with. Of course than the dynamic handling with class names for the
models gets more complex (and I am not aware of any existing framework
for that) and porting
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
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
It's currently not possible to address multiple datastores. Just
looking at the API, it looks like addressing datastores should be
possible because the keys include an app name, etc, but the App Engine
team has said this feature is not coming any time soon. Cross-app
datastore queries
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
32 matches
Mail list logo
