Is there any functionality exposed from adding predicates to types? What does a predicate being added to a type actually do?

I’m writing a golf scorekeeping app and I’m trying to flesh out the schema updates for the actual game scores. I’m trying to keep my schema well organized with types and strict mutations but while designing my “Round” type it got me wondering what the actual point of putting all of these predicates in my type definition is. For reference a “Round” is a node that represents a single game. It contains edges to each hole on the course, from the hole to the player, and from the score (though I might reorganize this as I work).

So for my Round type I can only add a HoleNumber as an attribute because the rest of the nodes that make up the information in a Round is below the top-level. But I don’t actually need to add HoleNumber as an attribute to the Round type because… why? Why does it do? What’s the difference between having a “User” type which includes attributes for the predicates “Username”, “Email”, etc. and just having an empty “User” type? As far as I can tell this is only useful for categorizing the node for filtering.

The obvious solution in my mind was to use other types as attributes of types for a nested type system. So I would create a “Score” type to define score nodes and list them in the “Round” type as attributes but this isn’t supported by the type system.

So I guess my question is, why would I ever go through the trouble of defining type attributes in the first place rather than just having the type names to categorize my nodes?

The type attributes are useful if you want to do expand queries:

If your queries are more of the type “for all of nodes of type X or type Y”, you’re right. Just marking the nodes as having a type without defining the type themselves should be enough for your use case.

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.