Nested Sorting: interface by non-derived child entity

[kamilkisiela]

Sorting an interface on a child basis.

• Fix: Kamil, please fix me :(
• Replace use_sort_key_alias boolean with something

[lutter]

Is this ready for review or should I wait until you've done your refactor?

[kamilkisiela]

@lutter wait until refactor, I will @mention you

[lutter]

Looks good to me. I like how you avoided passing that somewhat mysterious boolean flag around.

To me, the most important thing is that this won't change the behavior of queries that work today - I think that is true, and I don't have a great idea how we could test that more rigorously. The existing query tests should ensure that.

This is good to be merged after a rebase, and addressing the comment about making sorting by an interface where the field has mixed storage in implementers an error. I think it would lead to a SQL error anyway, but an explicit error would be clearer.

[lutter]

The crazy thing here is that AFAIK it's possible for different object types that implement the same interface to store that attribute directly or derived. I have no idea how well that actually works in practice, but I don't think we enforce anything there.

I don't think we should hold this PR up any longer because of that, but it's likely that this will lead to issues if anybody uses that somewhat crazy mix of derived and direct storage. I have no idea if anybody does that, and we should have a look at the specific subgraph if that ever leads to issues. It might be a good idea though to require that all implementers of the interface use the same storage and return an error otherwise just to make sure we don't inadvertently return incorrect data.

[gatleas17]

Hi