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
We aim to make our TypeQL queries more consistent and expressive, reformulating them in terms of streams/iterators commonly known from programming languages, also allowing them to be chained into longer sequences of operations.
Proposed Solution
We aim to have the following type system for different clauses and operations on streams of concept maps (Stream<ConceptMap>). Operations can be freely composed based on this type system.
Production operations
These operations are used to produced streams.
match clause: Stream<ConceptMap> -> Stream<ConceptMap>
Acts like a 'flatMap' in general (for each input concept map, continue the output stream with 0 or more concept maps).
The first match clause can be consistently thought of mapping from an empty stream.
always returns unique stream elements, i.e., streams are de-duplicated.
While match can operate on an empty input stream, the following operations cannot. We also refer to them as modifying operations. They are all of type Stream<ConceptMap> -> Stream<ConceptMap>.
filter $x, $y : filter + distinct the input concept map stream to a smaller concept map stream. Note that the variables that we filter (e.g. $x, $y) must exist in the concept maps of the input stream.
skip N: replaces offset with a better term indicating costliness.
take N: replaces limit with a term that is consistent with skip.
sort $x, $y: sorts the stream on the given variables (in order). Sometimes this may be optimized to avoid collecting all answers and re-emitting them as a stream.
Effect operations
These operations are called primarily for their effect on the DB (rather than on the stream). This effect may also affect the stream.
Each input concept map is possibly shrunk as concepts are deleted from the map, in the exact inverse of the insert clause.
Outputs are non unique - if all concepts are deleted, a stream of empty concept maps is produced. These are still useful - they can be counted!
If a delete statement contains an @cascade annotation then deletes will cascade based on the original input stream, i.e., we will cascade through potentially already deleted objects.
put clause: Stream<ConceptMap> -> Stream<ConceptMap>
the clause put P for a pattern P does the following: if match P yields an empty stream then execute insert P on the original input stream otherwise do nothing (keeping the executed match P).
Aggregation operations
These operations aggregate a stream into a single object (e.g. a value, a list of values, or a list of JSONs). These operation end a query clause chain.
check clause: Stream<ConceptMap> -> bool
A new clause that just checks for the existence of any answers, and returns this as a boolean
when running assert COND @or_print("test failed"); then the output is the input stream if COND is true, and otherwise an error is returned (with customizable error message as indicated by an annotation @or_print).
the precise syntax for assert conditions is TBD.
Summary
As a result of these changes, the user will always be able to truncate their query stream at any clause and execute it, without having to do an explicit get clause. This makes get redundant for this operation, and we absorb get's filtering operating into the new filter modifier.
Here's an example of building a longer query stream:
match
($x, $y) isa friendship;
// Unique stream<$x, $y>
filter $x;
// Unique stream<$x>
insert
$x has name "Alice";
// Unique stream<$x>
match
$x has email $e; $e == "[email protected]";
// Unique stream<$x, $e>
delete
$x isa person;
// Non-unique stream<$e>
reduce count;
// returns number of elements in the stream, which is the number of deleted people
The text was updated successfully, but these errors were encountered:
Problem to Solve
We aim to make our TypeQL queries more consistent and expressive, reformulating them in terms of streams/iterators commonly known from programming languages, also allowing them to be chained into longer sequences of operations.
Proposed Solution
We aim to have the following type system for different clauses and operations on streams of concept maps (
Stream<ConceptMap>
). Operations can be freely composed based on this type system.Production operations
These operations are used to produced streams.
match
clause:Stream<ConceptMap> -> Stream<ConceptMap>
While
match
can operate on an empty input stream, the following operations cannot. We also refer to them as modifying operations. They are all of typeStream<ConceptMap> -> Stream<ConceptMap>
.filter $x, $y
: filter + distinct the input concept map stream to a smaller concept map stream. Note that the variables that we filter (e.g.$x, $y
) must exist in the concept maps of the input stream.skip N
: replacesoffset
with a better term indicating costliness.take N
: replaceslimit
with a term that is consistent withskip
.sort $x, $y
: sorts the stream on the given variables (in order). Sometimes this may be optimized to avoid collecting all answers and re-emitting them as a stream.Effect operations
These operations are called primarily for their effect on the DB (rather than on the stream). This effect may also affect the stream.
insert
clause:Stream<ConceptMap> -> Stream<ConceptMap>
delete
clause:Stream<ConceptMap> -> Stream<ConceptMap>
insert
clause.@cascade
annotation then deletes will cascade based on the original input stream, i.e., we will cascade through potentially already deleted objects.put
clause:Stream<ConceptMap> -> Stream<ConceptMap>
put P
for a patternP
does the following: ifmatch P
yields an empty stream then executeinsert P
on the original input stream otherwise do nothing (keeping the executedmatch P
).Aggregation operations
These operations aggregate a stream into a single object (e.g. a value, a list of values, or a list of JSONs). These operation end a query clause chain.
check
clause:Stream<ConceptMap> -> bool
reduce
clause:Stream<ConceptMap> -> (... values ...)
, replacing theget; aggregate fn;
clauses.reduce
clause applies one or more reducing operators to the input stream:count(var) -> long
: returns 0 for 0 element streammin/mean/max/sum/stddev
return an optional value that must be handled with a new optional-empty handlermatch $x... $a... $b...; reduce count(), min($a), mean($b) ?: 0.0
(syntax not finalised)fetch
clause:Stream<ConceptMap> -> Stream<JSON>
Control operation
Control operation give the user the ability to control the execution of a chained query.
assert
:Stream<ConceptMap> -> Result<Stream<ConceptMap>>
:assert COND @or_print("test failed");
then the output is the input stream ifCOND
is true, and otherwise an error is returned (with customizable error message as indicated by an annotation@or_print
).assert
conditions is TBD.Summary
As a result of these changes, the user will always be able to truncate their query stream at any clause and execute it, without having to do an explicit
get
clause. This makesget
redundant for this operation, and we absorbget
's filtering operating into the newfilter
modifier.Here's an example of building a longer query stream:
The text was updated successfully, but these errors were encountered: