Looks great!

@jsenecal It looks like Travis is failing because of isort (curiously, only Python 3.4 🤔 ). I think isort gets a little tricky because the config file is trying to be correct for the rest_framework_json_api, but it also has to satisfy the included example package. I'm guessing you can solve this by including --thirdparty packaging to the isort command that checks example.

$ isort --check-only --verbose --recursive --diff --thirdparty pytest \
 --thirdparty polymorphic --thirdparty pytest_factoryboy \
 --thirdparty packaging example

I'll look at the code closer to give it some review.

I like what's here a lot!

What do you think about documentation for this stuff? IMO, features don't really exist until they are documented so that users know how to use them. With that stated, it doesn't matter to me if the features are documented in this branch or in some other branch as long as there is some prose before in the docs before the next release.

Once Travis is green, I'm ok with merging. If you decide to add some docs, I can give it another look.

Thanks for pulling this together with @aidanlister. 👍

@mblayman I did add some docs.

See my notes about this and b96d79d

Should we open another issue for that and merge this ?

@jsenecal thanks for including my cite, might be better to give some context there though? Let me write something:

Using the helper to prefetch, rather than attempting to minimise queries via select_related might give you better performance depending on the characteristics of your data and database.

For example:

If you have a single model, e.g. Book, which has four relations e.g. Author, Publisher, CopyrightHolder, Category.

To display 25 books and related models, you would need to either do:

a) 1 query via selected_related, e.g. SELECT * FROM books LEFT JOIN author LEFT JOIN publisher LEFT JOIN CopyrightHolder LEFT JOIN Category

b) 4 small queries via prefetch_related.

If you have 1M books, 50k authors, 10k categories, 10k copyrightholders in the select_related scenario, you've just created a in-memory table with 1e18 rows which will likely exhaust any available memory and slow your database to crawl. The prefetch_related case will issue 4 queries, but they will be small and fast queries.

No need to cite me, my paragraph in that issue is about the query explosion from displaying FKs -- let's merge this and we'll keep working out of that issue.