Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Dev apitoken #155

Closed
wants to merge 2 commits into from
Closed

Dev apitoken #155

wants to merge 2 commits into from

Conversation

dmgciubotaru
Copy link
Contributor

No description provided.

Gabriel Ciubotaru added 2 commits February 24, 2016 11:00
Signed-off-by: Gabriel Ciubotaru <[email protected]>
@dlespiau
Copy link
Owner

dlespiau commented Mar 1, 2016

This work introduces 128 new pep8 warnings. We currently have ~280 pep8 warnings, adding 50% with just this patch is not an option, so I'll have to fix that before going further. Or maybe you have time to do it?

$ (on master) tox -e pep8  > pep8.master
$ (dev-apitoken) tox -e pep8  > pep8.token
$ env)damien@strange:patchwork (20160301-token.2 %)
$ diff -u pep8.master pep8.token  | grep ^+ | wc -l
128

@cburlacu
Copy link
Collaborator

Here you have pep8 warnings fixed
https://github.com/cburlacu/patchwork/tree/apitoken-gciubotaru

@dlespiau
Copy link
Owner

Would you mind creating a real pull request rather than a branch? This way I can get travis to test it. Thanks.

@cburlacu cburlacu mentioned this pull request Mar 21, 2016
@cburlacu
Copy link
Collaborator

done

@dlespiau
Copy link
Owner

Closing that one in favour of the new pull request from Cezar. #170

@dlespiau dlespiau closed this Mar 23, 2016
@dlespiau dlespiau deleted the dev-apitoken branch March 24, 2016 11:18
@dlespiau
Copy link
Owner

For the problems with the HTTP errors: The URL hard codes the token ID ('tokens/1/'), but mysql doesn't reuse IDs when across test (ie the ID of the token increments as we run the tests).

In this case, I think you should be able to reuse the user1_at1 and user1_at2 'id' field in the query URL instead of always using '1'.

Now for the timestamps. The are two possible problems: we don't serialize the full precise timestamp in the JSON response, so when comparing it back to the local timestamp, it's truncated. MySQL also doesn't store the microseconds by default anyway. We don't really care about that amount of precision in this particular field. Truncating both timestamps to second precision before the comparison sounds like an acceptable trade off in the tests to me.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants