You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on May 24, 2023. It is now read-only.
In its final form, the query language should allow a wide variety of combinations, to makes queries as easy to write as they are to think. Diaspora should perform following query-to-assertion translations:
Rules are that several operator properties are implicitly resolved as &&, and implicit { [field]: value} without operator will have different results depending on the type of the value.
If its a primitive, it will be resolved as { "==": { [field]: value }}
If its an object, it will be resolved as { "$contains": { [field]: value}}
We've seen with @IkarosWilo that operators at root set a "prefix" mode.
If it's a field name, the "infix" mode is enabled: it projects its left operand in a new operator child object.
About escaping
We have to support the case where a field is named the same way as an operator, like $equal or ||. Escaping query keys may be done with ., this way: { ".$equal": { ">": 1}}. The leading dot forces the key to be treated as a field name instead of an operator, and is removed in the resulting query.
To output a leading dot in the output query, 2 dots should be used: { "..$equal": { ">": 1}}
About fields relation
It may be relevant to support in-entity fields comparisons, like this assert: entity.a == entity.b. But how to mark the value as a field instead of a string ?
The text was updated successfully, but these errors were encountered:
In its final form, the query language should allow a wide variety of combinations, to makes queries as easy to write as they are to think. Diaspora should perform following query-to-assertion translations:
{ "foo": { "==" { "bar": 2 }}}
=>entity.foo == {bar: 2}
{ "foo": { "bar": 2, "baz": 3 }}
=>entity.foo.bar == 2 && entity.foo.baz == 3
{ "foo" { "$contains": { "bar": 2, "baz": 3 }}}
=>entity.foo.bar == 2 && entity.foo.baz == 3
{ "==": { "foo": 1 }}
=>entity.foo == 1
{ "foo": { "||" [ 1, 2 ]}}
=>entity.foo == 1 || entity.foo == 2
{ "foo": { "||": [ 1, 2, 3 ] }, "bar": { ">": 1 }}
=>(entity.foo == 1 || entity.foo == 2 || entity.foo == 3) && entity.bar > 1
{ "||": [{ "foo": { "==": 1 }}, { "bar"; { "==" 2 }}]}
=>entity.foo == 1 || entity.bar == 2
Rules are that several operator properties are implicitly resolved as
&&
, and implicit{ [field]: value}
without operator will have different results depending on the type of the value.{ "==": { [field]: value }}
{ "$contains": { [field]: value}}
We've seen with @IkarosWilo that operators at root set a "prefix" mode.
If it's a field name, the "infix" mode is enabled: it projects its left operand in a new operator child object.
About escaping
We have to support the case where a field is named the same way as an operator, like
$equal
or||
. Escaping query keys may be done with.
, this way:{ ".$equal": { ">": 1}}
. The leading dot forces the key to be treated as a field name instead of an operator, and is removed in the resulting query.To output a leading dot in the output query, 2 dots should be used:
{ "..$equal": { ">": 1}}
About fields relation
It may be relevant to support in-entity fields comparisons, like this assert:
entity.a == entity.b
. But how to mark the value as a field instead of a string ?The text was updated successfully, but these errors were encountered: