Questions about the binary protocol

[CodesInChaos]

1. Where is Set allowed/required in type descriptors?

   My understanding is that the root and any shape elements are conceptually sets, but I don't know if they're modeled like that in the type descriptors as well?

2. What is the purpose of the Tuple/InputTuple distinction?

   I see that InputTuple is lacking a reserved field that Tuple has, but I don't know why this distinction exists and when each of them is used.

3. Is there a way to get the cardinality of a set (root object or shape element)?

   Statically typed languages model the cardinality as type (Option<T> and Vec<T> in rust) and I'd expect an error when the data model doesn't match the type.

[elprans]

Where is Set allowed/required in type descriptors?

The root result is always returned as a Set with cardinality specified in a PrepareComplete message. Additionally, Set may appear in non-singleton elements of shapes.

What is the purpose of the Tuple/InputTuple distinction?

We had a bug in the protocol that forced that distinction, which has since been fixed. I imagine it's a vestige of that. All Tuple values have a reserved field.

Is there a way to get the cardinality of a set (root object or shape element)?

Root cardinality is in the PrepareComplete response message. For shape elements, if it's a Set, the cardinality is MANY, and AT_MOST_ONE otherwise. I don't think we currently reflect the lower cardinality bound correctly, and it's actually a bug. \cc @1st1

[CodesInChaos]

All Tuple values have a reserved field.

Does that mean all InputTuple related code in the rust driver can be deleted?

[elprans]

I think so, @tailhook to confirm.

[tailhook]

We still use protocol 0.7. We first should switch to 0.8. Second we can only drop InputTuple once we decide that we don't want compatibility with older versions of edgedb. Since 0.8 is alpha3 we can already do that? I think it's better timing to do that right after alpha 6 (early next week), so stable CLI will support older versions for another release cycle.

[CodesInChaos]

4. Is an empty set inside a shape always encoded via Element.length = -1 on the parent and never via a set element with 0 children?
5. Is an empty set at the root encoded via a set element with 0 children?
6. There is never a distinction between a missing set and an empty set, right?
7. When a shape contains an array, both an empty array and a missing array (Element.length = -1) can be encoded and are semantically different, right?

[elprans]

4. I think it can be both. -1 datum length on the parent if the cardinality is AT_MOST_ONE, and a Set with zero length if the cardinality is MANY.
5. Yes.
6. Right.
7. Yes, {} and {[]} are different values.

[CodesInChaos]

The PrepareComplete message contains in input type. However query parameters are currently untyped. So what does it return? A named tuple of AnyType?

[1st1]

The query never declares those types and needs to cast the them because they're untyped, right?

It's a bit tricky, because <int32>$param syntax is actually a way to say that $param is of type int32. So the server always knows types of paramaters beforehand; this "cast" before a parameter name is currently required syntax.

In the future, we might implement more advanced inferencing and allow parameters without casts if we can unambiguously determine the correct type, like in SELECT 'Hello, ' ++ $name; query. But even then the server will know all parameters types when the query is prepared.

[CodesInChaos]

What happens if I take the same parameter and cast it to different types? Is that illegal?

[1st1]

This is perfectly valid: SELECT <str><int32>$foo. $foo is expected to be an int32 (that will be indicated in its type descriptor) and will later be cast into a string.

[CodesInChaos]

@1st1 With casting it to different types I meant referencing the parameter twice and using a different cast on each of them. Not chaining casts.

For example:

SELECT (<str>$foo, <int32>$foo)

[1st1]

That should be a compile-time error. It's a bug if it currently isn't.

[CodesInChaos]

Why does the Prepare client message contain an expected cardinality? Isn't that something the client only learns from the PrepareComplete server message?

[elprans]

This is an assertion the client makes for cases when a query is made from a method that only expects a singleton result, such as query_one(). If the supplied query may return a result of different cardinality, an exception is raised immediately.

[CodesInChaos]

1. Is there an advantage in the server raising an exception there, instead of the client looking at the cardinality in the response and raising the exception?
2. If the client sends many as expected cardinality, will it always work, even if the query has a cardinality of 0/1?

[elprans]

Yes, expected_cardinality dictates how the query is actually compiled. For example, in JSON output mode, if expected_cardinality was specified as ONE, the result would be a JSON object rather than an aggregated array of JSON.

if the client sends many as expected cardinality, will it always work

Yes, the client specifies the maximum expected cardinality.