Pull Request Test Coverage Report for Build 1148

• 10 of 10 (100.0%) changed or added relevant lines in 2 files are covered.
• No unchanged relevant lines lost coverage.
• Overall coverage increased (+0.004%) to 98.26%

Totals
Change from base Build 1144:	0.004%
Covered Lines:	3954
Relevant Lines:	4024

💛 - Coveralls

Thanks for the PR!

As you said, it's not always true that all results in sub-loaders are distinct. I also understand from the added test case. But it's also not always true that all results have to be distinct to make this tuple distinct, depending on use cases. For example, I want to iterate through (company, team) pairs instead of company.teams which needs two levels of for-loops.
As a tuple loader, each tuple represents a row in the raw result, so the job for it should be to simply convert elements in the raw result to models, and users need to decide how to use them.

Hm... i have an idea, TupleLoader must also relay on group by columns inside query to correctly handle all cases

By group by, do you mean the group by in the SQL? If so, there won't be duplicated rows. Say group by company.id, we won't get two rows of the same company.id, right?

One way to get what you want may be to check each returned tuple, and save it to context, like ModelLoader does. I'll explore and see if it makes sense.

I mean, when you have query result like that, with group by User:

we can automaticaly find it in group by columns and call company attribute to load Companies list,
to not explicitly add User.Distinct in query

I'm not sure I get what you mean.
If it's implemented, what would the syntax be like?

Like this?

TupleLoader(
    (
        User.load(add_company=Company),
        ColumnLoader(query.c.test_column),
    ),
    group_by=User,
)