search

muzny / tiletothetop

Repo for web app based vocabulary game.
0 stars 0 forks source link

Pushing Game Data fails #36

Closed cullensu closed 11 years ago

cullensu commented 11 years ago

When the ajax call to push game data returns, the response is null which causes Messenger.js:115 to get a null pointer exception. As far as I can tell the parameters passed into the Ajax call are correct, this seems like a back-end problem

lauredon commented 11 years ago

The schemamigration wasn't committed for this. I'll add it in a moment.

cullensu commented 11 years ago

I did a pip install, syncdb, and migrate and it still shows response as null, is there something I have to do?

lauredon commented 11 years ago

I hadn't tested it thoroughly since I didn't work on it, so I didn't see this particular error. But I do get the null error when I'm not logged in. getUserData also returns an error when not authenticated.

Reopening because we should probably handle these things better.

ghost commented 11 years ago

my vote: client side checks!

Also, my fault for the original bug. Did the migration, but forgot to add it to the repo (or more specifically, I forgot the -a command on commit only adds modified files)

muzny commented 11 years ago

If I play a game, finish it, and then go check the leaderboard without refreshing, it doesn't show my updated score. This appears to be the case also if you play multiple games without refreshing/reloading. It would be awesome if we could have the leaderboard show the very most recent stats.

jmcmanus commented 11 years ago

getUserData doesn't really return an error if the user isn't authenticated. It sends the ajax request, receives a 401: not authorized response -- which I believe is semantically correct -- and then passes control to the error callback). I prefer this approach.

As for pushGameData, you could check for null in its success callback, but why are you hitting the success function if the request didn't succeed? So, I guess my vote is to handle this on the backend.

ghost commented 11 years ago

Client side checks reduce our number of request sent by our application. And that is a good thing. I feel like its worth considering client side checks over returning 401 for this case. Also, 401 isn't technically correct here, because 401 implies providing authorization will make a retry succeed. While technically this is true, we don't give the user the option to try again after signing in, and going forward misses the chance forever. This could also cause score abuses through only submitting the games the user wants.

Ultimately either solution is fine, but I still feel like client side checks would be better here.

muzny commented 11 years ago

Is this still an issue? Cullen, were you working on this?

ghost commented 11 years ago

I believe the issue is pending on a confirmation of working in deployment. I saw the fix on my dev env.

Sent from my iPhone

On Dec 8, 2012, at 0:55, muzny notifications@github.com wrote:

Is this still an issue? Cullen, were you working on this?

— Reply to this email directly or view it on GitHub.

ghost commented 11 years ago

working on deployed version afaict

jmcmanus commented 11 years ago

Yeah. Looks good. I think we can close this. On Dec 8, 2012 2:55 PM, "dkeka" notifications@github.com wrote:

working on dev env afaict

— Reply to this email directly or view it on GitHubhttps://github.com/muzny/tiletothetop/issues/36#issuecomment-11164826.