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

Test for #123 #124

Open
wants to merge 1 commit into
base: master
Choose a base branch
from
Open

Test for #123 #124

wants to merge 1 commit into from

Conversation

ktosiek
Copy link

@ktosiek ktosiek commented Jun 30, 2015

See #123

@landscape-bot
Copy link

Code Health
Code quality remained the same when pulling 3216fdc on ktosiek:get_prep_value into 3b235cb on djangonauts:master.

@nemesifier
Copy link
Member

Great, thanks. I will review as soon as possible.

@ktosiek
Copy link
Author

ktosiek commented Jun 30, 2015

I've amended the commit according to the previous discussion (split the test into 2, added missing __eq__). I've also dropped saving the SchemaDataBag - it's not needed.

I've tried to fix this by just calling get_prep_value in HStoreDict.__setitem__, but that broke lots of tests (most notably test_schemadatabag_validation_error - it depends on invalid values being stored on the model as requested, and only checked at full_clean) - what would be a better place?

I think that to make django-hstore's behavior consistent with Django it should just work with Python values until save - when the values would be run through get_db_prep_value of field in schema. (I just tested, and with Django I can assign anything to a field and I'll get back the same object. It will only fail at clean/save).

def test_serializing_custom_type(self):
d = SchemaDataBag()
d.custom = CustomType('some value')
self.assertEqual(dict.get(d.data, 'custom'), '[some value]')
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I got the previous test to pass but here I have some doubts.

Isn't dict.get(d.data, 'custom') the same as d.data.get('custom')?
If that is correct it should return the CustomType instance, not the serialized value "[some value]".
If I'm not wrong the serialized value must be used only before storing the value into the database, which would mean this is not the right way to test for the desired behaviour.
What do you think?

PS: in django-hstore's VirtualField implementation, calling d.data.get('custom') is equivalent to calling d.custom

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If the first test passes even after saving/reloading the instance, then this one is not really needed. dict.get(d.data, 'custom') is pretty much what d.data.get('custom') calls when calling super().get().

When writing this test I assumed the serialization would be done when assigning values, and only later did I realize that's not how native Django fields work.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ok.

@nemesifier
Copy link
Member

I haven't been able to go ahead unfortunately, but I'll try to commit my unfinished work in a separate branch ASAP so hopefully more people can audit and send suggestions.

@nemesifier
Copy link
Member

Quick update: when I started working on this it required more time than I had available and I could not finish it. Disappointing..

@nemesifier nemesifier force-pushed the master branch 2 times, most recently from d1c11c8 to b0c59b3 Compare December 7, 2015 18:49
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