Details page gets extremely slow with many and large relationships

[estyrke]

Checklist

• The bug is reproducible against the latest release or master.
• There are no similar issues or pull requests to fix it yet.

Describe the bug

We have a model with quite a few (maybe 10) relationships (some one-to-many, some many-to-one). When showing the details for such an object, all those relationships are joinedload:ed:

sqladmin/sqladmin/models.py

Lines 804 to 805 in fadf4d6

	for relation in self._details_relations:
	stmt = stmt.options(joinedload(relation))

This causes a combinatorial explosion when those relationships get bigger. Let's say one relation has 10 objects, another has 15 and a third has 37. This causes the resulting query to return 10*15*37 = 5550 rows! Doing that with three separate queries (selectinload or just default lazyload) would load the expected 1+10+15+37 = 63 rows.

This seems to have been introduced in #212.
Changing the joinedload on L805 to selectinload or simply removing L804-805 resolves the issue in my case. If the joinedload is really required to prevent regressions, maybe we could have a way to override what type of eager load is used?

Steps to reproduce the bug

No response

Expected behavior

No cross product between relations in detail view.

Actual behavior

No response

Debugging material

No response

Environment

SQLAdmin 0.16.0
PostgreSQL 14.7

Additional context

No response

[aminalaee]

I don't think this will cause a regression, but I'm thinking there will be some limitations with going to selectionload as joinedload is more suitable for Many-To-One relationships and there's a chance we are running in circles between the options because we have all possible cases of relationships One-To-Many, Many-To-One, One-To-One and Many-To-Many and we probably can't find one option that fits all.

I will create a PR to test this and see if people have any feedback on it.