Open Phylodome opened 4 years ago
In theory, this test, as described in #481, should cover this case.
Yet in practice when I attempt to structure my queries using this fragment-based approach, I do not see any of the properties from the targeted type included in the relation's orderBy
parameter, as described above.
As of
2.15.0
, specifying a type containing an inline@relation
directive, like so:Will generate an augmented type like:
But specifying the relation as its own property-containing type, like so:
Appears to lose the
orderBy
functionality with respect to the targeted node type (here,Genre
), and only generates:Where
_MovieGenreRelationOrdering
only provides the capacity toorderBy
the properties of the relation itself (above,type_asc
andtype_desc
), but does not provide the ability toorderBy
any properties of the relationally targetedGenre
type.Additionally, the resulting
_MovieGenreRelation
contains no parameters on the targetedGenre
key, so AFAICT filtering can't be accomplished at this level, either.Is this by design? Forcing a tradeoff between a relation's capacity to contain properties and its capacity to order the related target nodes dramatically limits architectural flexibility, and appears to force the splitting into separate queries of any property-containing relations that require filtering / ordering.