Andreas, The datastore provides virtually no security mechanisms for data partitioning within the same application. The responsibility for access control belongs in your application layer.
On Thu, Dec 3, 2009 at 8:28 AM, Robert Kluin <[email protected]> wrote: > Andreas, > I have a very similar application. It tracks a league's season, team, > player, and game scores / statistics. I needed to have isolation between > leagues and within leagues between seasons, teams, players. Basically the > approach I settled on was adding a "league" and "season" property to most of > the models. > > When a user logs in they must select a league they have permissions to > access or manage, I store the league key in a datastore-backed session. Any > time they access something I verify that the league key matches, and, of > course, any queries I run filter out content from different leagues. I > continue this approach down to the lower level items (players and games for > example). > > I do use entity groups, but at a much finer level, and they may not > really be needed at all. For storing statistics I have models like > PlayerSeason, PlayerWeek. I put Player, PlayerSeason, and PlayerWeek into > the same entity group. Likewise for the teams and their stats. I did this > so that if a part of my db.put() that stores all games and related > statistics models fails I do not have players or teams getting mismatched > within themselves -- not really sure it helps much though. > > Robert > > > > > On Thu, Dec 3, 2009 at 9:07 AM, andreas_b <[email protected]>wrote: > >> I chose the wrong wording in my original post. I didn't mean actual >> full databases, but something like a schema yes. >> Have a lot to learn when it comes to efficient database usage in any >> case :-). >> >> Actually I'm not using the LLAPI for portability reasons. I don't want >> to build too many dependencies on a particular web service, so >> I chose JDO instead, although LLAPI seems a bit more powerful. I might >> actually look into it to gain more flexibility. >> >> Thanks for the tip! >> >> BR, Andreas >> >> On Dec 3, 2:19 pm, Roy <[email protected]> wrote: >> > In an RDBMS world you would actually create a schema for each team, >> > not a full database (unless you have a morbid need to drive your >> > sysadmin to an early grave). I did make a feature request for this, >> > but you know how it is with GAE feature requests. >> > >> > If you're using LLAPI, there is actually a very simple trick that will >> > work, Append the team name to the kind. >> > So instead of a kind called "player", you have kinds called "player- >> > spurs", "player-w19an", etc. >> > >> > You can have a very simple customer data access layer which does this >> > automatically based on a session variable. >> > >> > I use this trick for testing. Whenever I login using a designated test >> > username, I append "-test" to my kind names so that I'm not missing >> > live and test data in a single dataset. >> > >> > On Dec 3, 7:53 am, andreas_b <[email protected]> wrote: >> > >> > > Thanks both of you! >> > >> > > Very helpful answers. >> > >> > > Best Regards, Andreas >> > >> > > On Dec 2, 8:24 pm, "Ikai L (Google)" <[email protected]> wrote: >> > >> > > > Creating a database per team is a very heavyweight way to address >> the >> > > > problem of data segregation. This is unnecessary and in general, not >> a >> > > > recommended best practice, as you would provide data isolation at >> the >> > > > application layer. The intuitive solution here is to create an >> entity group >> > > > for a league or team (depending on your transactional needs) and >> place child >> > > > entities in that group. >> > >> > > > On Tue, Dec 1, 2009 at 10:40 AM, andreas_b < >> [email protected]>wrote: >> > >> > > > > Hi all. >> > >> > > > > I'm working on a GWT/GAE project where the idea is to create a >> portal >> > > > > for sport teams. Each sport team can sign up to get an account >> where >> > > > > they can register players, keep track of leagues, matches, >> statistics >> > > > > and so on. Each team should also be able to use their own domain, >> > > > > which automatically should load the site with their configuration >> when >> > > > > entered (basically just load the gwt-app with some url-parameter >> that >> > > > > is forwarded to server-side). >> > >> > > > > So, coming from a normal SQL-environment, it seems to me that each >> > > > > team that signs up should get their own private database for all >> their >> > > > > data. As I understand it, this is not possible with GAE datastore? >> > > > > There is a one-to-one mapping between an application and a >> datastore? >> > >> > > > > If this is the case, then what is the best way forward? I guess >> each >> > > > > entity could have a team ID, but it really doesn't seem like a >> good >> > > > > idea. There should be some kind of isolation between the different >> > > > > teams' data. >> > >> > > > > Registering a new GAE app for each team is not an option either >> since >> > > > > we expect at least hundreds of teams. >> > >> > > > > So, is there some way to isolate entities from each other within a >> GAE >> > > > > datastore? >> > > > > Also, would it be feasible from a performance point of view to do >> > > > > this? >> > >> > > > > Or is simply GAE not the right way to go for this kind of web >> > > > > offering? >> > >> > > > > Thanks in advance. >> > >> > > > > BR, Andreas >> > >> > > > > -- >> > >> > > > > 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]<google-appengine%[email protected]><google-appengine%2Bunsubscrib >> [email protected]> >> > > > > . >> > > > > For more options, visit this group at >> > > > >http://groups.google.com/group/google-appengine?hl=en. >> > >> > > > -- >> > > > Ikai Lan >> > > > Developer Programs Engineer, Google App Engine >> >> -- >> >> 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]<google-appengine%[email protected]> >> . >> For more options, visit this group at >> http://groups.google.com/group/google-appengine?hl=en. >> >> >> > -- > 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]<google-appengine%[email protected]> > . > For more options, visit this group at > http://groups.google.com/group/google-appengine?hl=en. > -- Ikai Lan Developer Programs Engineer, Google App Engine -- 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.
