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
Please replace every line in curly brackets { like this } with appropriate answers, and remove this line.
Description
match $p isa person, has full-name $n; get;
could have been made
match $p isa person, has first-name $n; get;
first-name is a defined attribute in the phone_calls keyspace, while full-name is not.
It is all very nice to read along and visualize what the database will do, it is a much better thing to try the code out at the same time.
Some of these examples could have easily been adjusted to work with the phone_calls keyspace.
Attributes could have been defined first in the docs, rather than a note explaining why the code does not work.
The graphics on concepts should have been shown earlier in the docs, along with the associated keywords.
On a different note I expected version 2.0 to be available in September 2020 and run on a more efficient database, e.g. Scylladb instead of Cassandra.
Running off aws ebs is bad for a database and there should have been an option to run on Scylladb on nvme.
I read somewhere the network has to be loaded separately for each query. I hope that is wrong as it severely limits concurrent queries on limited hardware or makes infrastructure costs exorbitant.
I have not seen any benchmarking, and also have not seen any comparative benchmarking.
It looks like every node (concept) has to be read in a query.
I don't think Grakn could handle a billion nodes (concepts), but I would like to be proven wrong.
The docs are not the worst I have seen, but it certainly deters me from considering it as an alternative to a column graph.
Maybe I just don't need insights that much and can use ML to analyze traditional data structures.
Hoping for improvements here.
Please replace every line in curly brackets { like this } with appropriate answers, and remove this line.
Description
match $p isa person, has full-name $n; get;
could have been made
match $p isa person, has first-name $n; get;
first-name is a defined attribute in the phone_calls keyspace, while full-name is not.
It is all very nice to read along and visualize what the database will do, it is a much better thing to try the code out at the same time.
Some of these examples could have easily been adjusted to work with the phone_calls keyspace.
Attributes could have been defined first in the docs, rather than a note explaining why the code does not work.
The graphics on concepts should have been shown earlier in the docs, along with the associated keywords.
On a different note I expected version 2.0 to be available in September 2020 and run on a more efficient database, e.g. Scylladb instead of Cassandra.
Running off aws ebs is bad for a database and there should have been an option to run on Scylladb on nvme.
I read somewhere the network has to be loaded separately for each query. I hope that is wrong as it severely limits concurrent queries on limited hardware or makes infrastructure costs exorbitant.
I have not seen any benchmarking, and also have not seen any comparative benchmarking.
It looks like every node (concept) has to be read in a query.
I don't think Grakn could handle a billion nodes (concepts), but I would like to be proven wrong.
The docs are not the worst I have seen, but it certainly deters me from considering it as an alternative to a column graph.
Maybe I just don't need insights that much and can use ML to analyze traditional data structures.
Hoping for improvements here.
Location of Content
https://dev.grakn.ai/docs/query/match-clause
Expected Content
{ Please describe what you expected to happen. }
Actual Content
{ Please describe what actually happened. }
Additional information
{ Any additional information, including logs or screenshots if you have any. }
The text was updated successfully, but these errors were encountered: