-
-
Notifications
You must be signed in to change notification settings - Fork 25
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
Taggingfixes 71 74 86 ..and 78 #96
Conversation
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.
This looks great! 😍
TIL Thank you again for the detailed notes! |
@billglover - adding you for review to make sure I haven't screwed up something in my battles with the ORM & docker. Ok if you don't want to give specific feedback..just not quite ready to merge this without additional eyes. 😄 |
Will try and get to this in the next 48 hours. Have been tied up. |
call_command('loaddata', 'users.json', verbosity=0) | ||
call_command('loaddata', 'resources.json', verbosity=0) | ||
call_command('loaddata', 'tags.json', verbosity=0) | ||
call_command('loaddata', 'tagging.json', verbosity=0) | ||
call_command('loaddata', 'taggeditems.json', verbosity=0) |
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.
Instead of loading fixtures, I'd recommend either using pytest
fixtures, a library like factory_boy
to generate data, or just creating the needed model instances here in the setUp
. Fixtures get out of date quickly and are fairly hidden. It's also hard to know if you can change them to create new data conditions for tests. This would also solve your problem of needing to fetch items below as you could associate the created objects with the class and then use them in tests below.
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.
Thank you for the reminder. We have #48 out as a specific issue around this...the logic being that I was struggling to get tagging related features done (and wanted at least some very minimal tests to go with them), so bailed on the testing infrastructure in the short term.
I will be adding additional issues for testing models, serializers, and views as well now that the "major" changes are done-ish.
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.
I haven't run this so I won't approve/deny it, but I don't see anything suspicious or worrisome.
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.
This is all heaps of awesomeness. Many, many thanks @BethanyG. I ran a clean copy of the site off master, pulled this PR and re-deployed. Migrations ran smoothly, the site works, the tests pass.
oop. Brain fart on the merge process. Mashing big, green button now.... |
Note: In order to get the migration order to work correctly, adding dependancies to the migration files was necessary per documentation here and adding the
__latest__
flag to dependent migrations as noted heretagging
app. ( fixes #86)guid
for tags. (fixes #71 )tags
field when POSTing a resource. ( fixes #74 )python-slugify
version to 4 (fixes #78)__latest__
tagging
migrations toresources
0006_auto_20200303-1257.py migration file.tagging.json
&taggeditems.json
files to populate the custom_tags and taggeditems tables.resources
tests.