There are some fields you'd like to use almost ever time you use a user object, like first_name and last_name.

However, there are some fields you only have one use case for, for example, twitter_oauth_token and twitter_oauth_secret, and it's somewhat inefficient to bother serializing and deserializing these when they're not needed 95% of the time.

You can put a ReferenceProperty to the User in the UserTwitterOauth, but this would actually be one-to-many as there's nothing stopping there to being multiple UserTwitterOauth objects per User. You want there to be at most one UserTwitterOauth related to any User. How can you relate these models on a one-to-one basis?

As an aside: Do not split up your model just because you think it will be more efficient. It will be much more efficient to keep it all on one entity in the long run, saving multiple expensive api calls, especially with the example you have posted. Come back and ask this when you have hundreds of properties on your User model, and only then to improve write performance ;-)
–
Chris FarmiloeJun 7 '11 at 19:13

@Chris: In essence this question might be about premature optimization. But personally I like the idea of separating a User artifact with its potential connections. What if a you want to model a linkedin connection besides a twitter connection... and so on and so forth.
–
Jon NylanderJun 7 '11 at 21:55

1

@jon, a large part of working with GAE tends to be finding ways to de-normalise your data models to allow you to easily query against them and reduce API calls, for this particular case it seems unnecessary, even if there were 20 various connections.
–
Chris FarmiloeJun 7 '11 at 22:06

You can add a straightforward method or property to the User class to make it easy to retrieve the additional information, and a class method to UserTwitterOauth to serve as a factory method, preserving the convention.

Incidentally, note that User is a dangerous name for an entity - the Users API has a class called User too, and unless you're very careful with your imports, you may end up referring to one when you intend to refer to the other.

A reference property to the user from the twitter access token is by far the easiest to maintain, in my view. It is true that the user could be referenced by many access tokens.

You will however find yourself doing things by convention a lot of times when working GAE.

EDIT preventing several access tokens referencing same user:

You can access referencing access tokens as a query via the User.usertwitteroauth_set property. If you want a more descriptive name, specify the parameter collection_namewhen setting up the ReferenceProperty. Say for example you want to remove any referencing access tokens before you add a new one, you could gather that logic as such: