CODEWITHSUNDEEP
google-app-engine
Casey Marshall
Casey Marshall

Reputation: 954

Infuriating user queries on Google's App Engine

I have a web service on Google's App Engine that uses Google's user API for authenticating users, managing accounts (including premium service subscriptions), and for managing data ownership. For almost everything, it works really great.

However, very often I need to use the datastore viewer to check on a user's entry in response to a support request, and need to enter GQL to look up someone's account info. The query usually looks like this:

SELECT * FROM UserAttr WHERE user = USER('[email protected]')

This should work just fine, but for whatever reason, the USER constructor (?) above is case sensitive, and furthermore, sometimes has weird behavior if the user has a Google account with a gmail.com address. If it's a gmail.com address, sometimes USER('[email protected]') works, but sometimes USER('whoever') works. It's maddening that I have to try all kinds of different permutations in the GQL console to try and look things up, and I usually give up if the obvious case differences don't work.

Am I doing something totally wrong here, or is the behavior of this really this bad? Any idea if this kind of thing works better in the Python API (that is, if I do a similar request via Python, will it still exhibit this idiotic behavior?). I'd like to avoid writing my own admin pages for this app, if I can make Google's dashboard work for me.

Upvotes: 3

Views: 142

Answers (1)

akiva
akiva

Reputation: 2737

I'm having the same problem, I figured out that google doesn't recommend storing users at the datastore at all as the email address might change:

from here:

Both the db and NDB libraries have UserProperty property types so that applications can store user values. However, since these values become invalid when users change email address, most applications have no good use for this feature.

they probably also mean when the user representation changes internally.

I'll let you know if I find anything to solve this

---- EDIT ----

here they recommend storing the user's ID for the sake of queries and comparisons. makes sense...

Upvotes: 1

Related Questions