Service definition: support recursive types

proposal

#1

We need to support recursive types in order to have type definitions on child fields of an object type where child fields referring to its parental type.

This is the current syntax that doesn’t support recursive types. Please see comments in the yml below:

events:
  query:
    data:
      fields:
        repeated: true
        type: Object
        object: # field
          name:
            type: String
          fields: # fields is actually type 'fields' *recursive*
            type: Any
          args:
            type: Object
            repeated: true
            object:
              name:
                type: String
              value:
                type: String

I’m thinking about having a syntax like below to support recursive types:

events:
  query:
    data:
      fields:
        name: fields
        repeated: true
        type: Object
        object:
          name:
            type: String
          fields: +fields
          args:
            type: Object
            repeated: true
            object:
              name:
                type: String
              value:
                type: String

So with the syntax above, we’re introducing a new key called name in the parameter type while also supporting special values in field values to identify named values by checking for + sign.


#2

I don’t see the necessity for this feature. Could you provide an concrete example?


#3

I’m not a big fan of that, I don’t think we should support recursive data, it makes things really complicated and data are never really recursive you can always define the schema and if it’s really recursive it makes more sense to me to call this task multiple time, having a loop on the outputs.

Same as Nico, I would like to see a concrete use case of that to convince me :slight_smile:


#4

I’ve a real world need for this please check fields section in service-graphql.

query event is emitted with wanted fields on every GraphQL Query request. A query request looks like below:

 { services { sid, owner, versions { hash }  } }

As you can see, in this example, a query is consist of nested objects(fields) and every field might have child fields. And nesting level for each field is unknown, in other words, it’s dynamic.

We need to implement this proposal in order to have -nested- typed query fields. Otherwise we’re going to end up having typed fields for only one(root) level.

I don’t see any reason to not implement this, I think implementation wouldn’t be complicated, we just need to wrap the current logic inside a recursive func.


#5

I don’t see the recursion here. You talk about the nested and this is done with the type object already

nested1:
  type: Object
  object:
    nested2:
      type: Object
      object:
        ...

You can add different level of nested like that so you are not limited to the root. Of course you have to define all the nested but I don’t really see the value of having an unlimited nested.

This might also help, I’m not 100% sure of the syntax but using the yaml variables but I think here you will have some issues when parsing this (kind of infinite loop)

nested1: &nested
  type: Object
  object:
    <<: *nested

#6

By nested, I was talking about having recursively nested types. Not nested types by itself. I think, there is value having recursively nested types because otherwise, child fields are never typed.

The syntax you provide for the yml parser won’t work because it’s an infinite loop and since yml parsers generates a static output from yml syntax, it’s not possible for them to generate an output for recursive definitions.

So if we want to have this feature, we need to do it on our side with a new syntax to let devs to define recursive types virtually.