Enhancement: Optionally make use of SQLAlchemy joinedloads in `instances` queries

[boydgreenfield]

Depending on how ones' relationships are configured in SQLAlchemy, adding .options(joinedload("relationship_name")) to the query can substantially reduce the number of queries executed.

I've prototyped this a bit for our code, relationship set ups, and on Postgres, and would be happy to share that snippet or start a preliminary PR. Unfortunately, I'm not 100% sure how well this generates to different model specifications, DB backends, etc.

[lyschoening]

Great suggestion! I would love to see your prototype code for that. It should be a relatively simple addition.

A problem with SQLAlchemy is that it needs to request objects in the relationship even if only the id-attribute is accessed. So to work efficiently with Potion, every relationship unfortunately needs to be joined.

[boydgreenfield]

I'll put a PR together for this then. In my experience, joinedload tends to be the right hammer for "return all instances of"-style queries, but there are other loading options (see http://docs.sqlalchemy.org/en/latest/orm/loading_relationships.html#what-kind-of-loading).

Do you have preferences on whether: (1) this is on by default for the SQLAlchemy manager (vs. a use_joinedload kwarg); or (2) whether additional loading options can be used (e.g., subqueryload)?

For an initial implementation, I'd err towards just using joinedload, having a flag to turn it off/on (default on probably makes sense), and then writing it as an overridable method so a SQLAlchemyManager subclass could specific different eager/lazy/subquery-based loading as desired.