Support recursive types

[drewwells]

🚀 Feature

#1437 removed the ability to use recursive types. We used these in protoc-gen-gorm to created nested query structures. We parse SQL where clauses into an AST tree ie. WHERE group=acme AND tag=recent. The issue is that this syntax can have multiple layers of logical operators (AND OR).

WHERE (group='acme' AND tag  = 'recent') or tag = 'override')

Now that nested query parameters are specifically rejected, we are unable to parse these nested structures. I would like to be able to have recursive types to build trees. Here's an example proto definition. One of the possible parameters of LogicalOperator is LogicalOperator. As openapiv2 plugin inspects this, it returns the error: panic: recursive types are not allowed for query parameters, cycle found on ".infoblox.api.LogicalOperator"

https://github.com/infobloxopen/atlas-app-toolkit/blob/master/query/collection_operators.proto#L83

message LogicalOperator {
    oneof left {
        LogicalOperator left_operator = 1;
        StringCondition left_string_condition = 2;
        NumberCondition left_number_condition = 3;
        NullCondition left_null_condition = 4;
        StringArrayCondition left_string_array_condition = 11;
        NumberArrayCondition left_number_array_condition = 12;
    }
    oneof right {
        LogicalOperator right_operator = 5;
        StringCondition right_string_condition = 6;
        NumberCondition right_number_condition = 7;
        NullCondition right_null_condition = 8;
        StringArrayCondition right_string_array_condition = 13;
        NumberArrayCondition right_number_array_condition = 14;
    }
    enum Type {
        AND = 0;
        OR = 1;
    }
    Type type = 9;
    bool is_negative = 10;
}

[johanbrandhorst]

Hi Drew, thanks for the issue. It seems to me the original block on recursive types in query parameters was because it was causing an infinite loop in the parsing (#1167). I'd be happy to reintroduce recursive types as long as we have a plan to deal with that issue, which may mean detecting loops and short circuiting some recursion instead of outright disallowing the messages.

I think there's plenty of prior art here to study, but if you're unsure where to start, #1266 and #1437 are probably good places.

[drewwells]

I agree on the infinite loop piece. I think starting with type detection made sense. We just need add counters to them. If type encountered 1000 times, panic.