-
Notifications
You must be signed in to change notification settings - Fork 15
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
Drf 3.0 #6
Drf 3.0 #6
Conversation
Ugh, stupid python 2.7. I'll try to figure why the tests aren't working in 2.7 soon. Or if anyone happens to see the reason sooner, happy to take a tip |
|
|
hi @jannon, thank you very much for contributing. It looks good, I'll look for some spare time to analyze soon. Could you squash all the commits into one commit please? |
self.assertEqual(s['email'], '[email protected]') | ||
self.assertEqual(s['ip'], '10.10.10.10') | ||
self.assertEqual(s['url'], 'http://test.com') | ||
# should be hidden | ||
self.assertTrue('data' not in s) | ||
|
||
# self.assertTrue('data' not in s) # Why? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
by design, the dictionary field is hidden in schema mode, this is because dictionary keys should be accessed via the virtual fields.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
have you read this?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
hey @jannon, have you read the preceding comment?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sorry, just had a super busy week. Right, so the only thing I know for sure right now is that the 'data' item is present after upgrading to DRF3.1 and the changes needed to support it didn't add or remove anything related to the 'data' item. So it seemed to me that this was just new behavior and the test needed to be updated. If that's not the case, I can find some time to see the best way to explicitly remove 'data'
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ok I see, you could also just uncomment the line and let the test fail. We can take care of this in subsequent commits.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
okay, done
I'll get to squashing soon |
|
great, only 1 minor issue remaining, I left an inline comment |
|
the test of the 'data' dictionary item is uncommented and everything should be good to go |
I had to edit your commit because your email did not match your github account and you wouldn't have shown in the contributors. |
Okay, here's a Django Rest Framework 3.0+ compatibility PR (addresses #4). Actually, this is DRF 3.1+ compatibility update because the ModelSerializer API for custom field mapping needed for the schema hstore fields only returned on 3.1. DRF 3.x contains non-backward-compatible changes. As such, this update will no longer be compatible with DRF < 3.1. The main points are as follows:
Field
instead of the non-existentWritableField
HStoreField.to_native
->HStoreField.to_representation
HStoreField.from_native
->HStoreField.to_internal_value
HStoreSerializer.restore_object
->HStoreSerializer.create
andHStoreSerializer.update
HStoreSerializer.get_field
->HStoreSerializer.build_standard_field
and modified to use new ModelSerializer APIMIDDLEWARE_CLASSES
to test settings to silence Django 1.7 warnings