RQL sent to server for links should use encoding that the server can understand

[sync-by-unito]

Currently, if you set a subscription on a link in flexible sync, the following query will look like the following:

NET Code: 
var newQuery = realm.All<AllPrimitiveTypes>().Where(o => o.LinkingObjectField == linkingObject);

RQL sent to server
(LinkingObjectField == O0)

This is the internal realm object key and is not something that the server knows anything about. Ideally this would contain the _id field of the linking object (primary key) and perhaps the table name being linked to as well. Any idea if this is a big lift or is this something that can be easy to change for how this is sent to the server?

cc [~[email protected]] [~[email protected]]

[sync-by-unito]

➤ On 2022-04-19, Jørgen Edelbo commented:

We could support a syntax like = "LinkingObjectField = []". The reason for choosing something like an index notation would be that the object is "indexed" by the primary key. I don't know if there is already a common way to express this.

[~[email protected]] [~[email protected]] [~[email protected]] what do you think about the syntax?

[sync-by-unito]

➤ On 2022-04-19, Tyler Kaye commented:

So in MongoDB the Namespace and the _id field are an "index". In Sync we can safely map a TableName to a Namespace so we would just need a TableName and a PrimaryKey. I see in the bison grammar that there seems to be a Link and a TypedLink type. What are those used for out of curiousity?

[sync-by-unito]

➤ Jørgen Edelbo commented:

As we have to include the table name, it was not straight forward to invent an unambiguous syntax, so what I suggest is " = '{' ':' '}'". One query string could then look like this: "item = {Items:'coffee'}".

[sync-by-unito]

➤ Michael O'Brien commented:

A drawback with "{tablename:'primarykey'}" is that the syntax looks so similar to the way a JSON object is declared that it might imply that it's doing something more sophisticated, or would support multiple keys/values.

What if we did something more explicit like this:
items = LinkToObject("table", "primarykey")

[sync-by-unito]

➤ Tyler Kaye commented:

Seeing that this just went to the backlog but I think this is something that should be prioritized ideally. This is what is preventing us from having "links" as a valid queryable field which I think is a requested thing. cc [~[email protected]]

[sync-by-unito]

➤ Ian Ward commented:

Yes - this is a stepping stone to the future relationship project which could take a while. [~[email protected]] [~[email protected]] - is there czar/quality work that can pick this up? I don't think this would take very long

[sync-by-unito]

➤ Alexander Stigsen commented:

It should not take long. Jørgen already has a partial implementation. What is missing is final agreement on the syntax.

There are three link types we need to support: Link, TypedLink and Mixed. So the syntax has to be able to express a link both by only its primary key (for Link), and with the combination of table and primary key (for TypedLink and Mixed). It also has to be unambiguously parsable in the RQL syntax, without clashing with future features like the ability to express JSON objects as query targets.

Current suggestions are:

• {table:primarykey} - conflicts with JSON obj/dict syntax
• LinkToObject("table", "primarykey") - a bit verbose

A third option could be for Link, table:primarykey for TypedLink and Mixed. Which is concise and does not clash with existing syntax.

[sync-by-unito]

➤ Jørgen Edelbo commented:

I like the last suggestion from [~[email protected]] . So the syntax would be: 

compare
{{    : ...}}
{{    | expr equality primary_key}}

primary_key
{{    : '<' constant '>'}}
{{    | '<' STRING ',' constant '>'}}

[sync-by-unito]

➤ Michael O'Brien commented:

 LinkToObject("table", "primarykey") - a bit verbose

It's more verbose, but it's also explicit about what it means - /table:primarykey is very opaque.

Minimizing verbosity seems to me like the wrong axis to optimize for, given that most of these queries are going to be generated via SDK builder APIs rather than explicit strings anyway.

[sync-by-unito]

➤ Alexander Stigsen commented:

It is true that it is less self-explanatory, but it using <> does make it look like an identifier, and verbosity can really add up. We have to keep in mind that it has to fit in with the rest of the RQL syntax. It will not only be used with simple equality, it has to fit in to IN queries as well: {}"link IN \{<key1>, <key2>, <key3>}"{}.

While it will likely mainly be generated, there are also cases where you could imagine users using the syntax directly to match objects by their primary key.

[sync-by-unito]

➤ James Stone commented:

I don’t have a strong opinion either way on this. I like that the syntax is concise. On the other hand, Mike’s suggestion follows existing precedent of sort/distinct/limit:

SORT(age ASCENDING)
DISTINCT(name, age, city)
LIMIT(1)

while <x> is inventing new syntax.
Though instead of being so verbose with LinkToObject("table", "primarykey") I would suggest something simpler like Obj(table, "primarykey")

[sync-by-unito]

➤ Alexander Stigsen commented:

So far we have used the method syntax for things that were actual functions (like sort, distinct and limit), rather than for values. If we choose to use that syntax, we should at least prepend it with an @ to make it clear that it is a value rather than a function (similar to how we do with @links and the aggregates).

I am open for both, but personally I'd prefer the <x> syntax, as it at least for me visually signals that it is an identifier.

[nirinchev]

A constructor can also be viewed as a function and is in line with types such as objectId and uuid where the query syntax is oid(...)/uuid(...). I don't have strong opinions, but I think @ironage's suggestion with obj(table, key) would be most consistent with the current syntax.

[sync-by-unito]

➤ Jørgen Edelbo commented:

The constructor approach (obj()) would also work for me. [~[email protected]] if you are fine with that, I think we all agree.

[sync-by-unito]

➤ Alexander Stigsen commented:

Works for me. I think old() and uuid() are good precedents.

[sync-by-unito]

➤ Michael O'Brien commented:

Yeah, I like thinking of it as a constructor. I don't feel strongly about calling it "LinkToObject" - something short like "obj()" or "link()" seems nice

[sync-by-unito]

➤ Jørgen Edelbo commented:

We are all happy. I will continue the work.