Semantic Check Fails: Please specify the from_id for vertex device

1

I can’t figure out what the error message “Please specify the from_id for vertex device” below is really trying to tell me. Any idea?

GSQL > select count(*) from device-(device_has_host_event)->host_event
[{
  "count": 884911,
  "e_type": "device_has_host_event"
}]
GSQL > select * from device-(device_has_host_event)->host_event limit 10
Semantic Check Fails: Please specify the from_id for vertex device
2

Looks like query language in GSQL console is not the same as in .gsql file :sweat_smile: . I will stick to .gsql for now.

1 Like
3

The query you were running (with a minor syntax error, hence the error message) is what we call a “Built-in Query”: https://docs.tigergraph.com/start/gsql-examples/common-applications#built-in-queries
Built-in Queries are not GSQL; they are very SQL-like, but also limited in capability. They provide a handy way to select and inspect the vertices and edges that are in the database. They are not for graph traversal or analytics or transactions.

The specific error: You can only select edges if you specific a single source vertex using the clause
WHERE from_id==<source_id>

Note, however, that running built-in queries is unrelated to whether you are in the GSQL interactive console or not. For example, if you in a Linux shell, you can run a built-in query the same way you would run a GSQL command, but enclosing it in quotes (or by naming a file containing your commands).

Linux> gsql -g MyGraph 'SELECT count(*) FROM Person'
Linux> gsql -g MyGraph 'RUN QUERY pageRank(<parameters>)'
2 Likes
4

Victor,

Thanks for your detailed explanation! It all makes sense now.

I was mainly using the help page below for reference. It would be nice if it had a note explaining that distinction between the built-in select statement and gsql select statement.
https://docs.tigergraph.com/dev/gsql-ref/querying/select-statement#gsql-select-statement

1 Like
5

The concept of “Built-In” query is confusing to me…

It’s not mentioned in the documentation built-in-queries how they are special and “not GSQL even though they are SQL-like”… I had the impression that GSQL is SQL-like (from the marketing materials), but now I see that’s not true but I’m failing to understand the differences.

The error message is also not helpful. (Thankfully, when I searched for it, I got this page.). Perhaps you can put in an example of what’s expected? Since there are at least two people who were puzzled by this, a better error message is warranted.

If you’re used to SQL, then the fact that this works:

select COUNT(*) from person-(friendship)-person

and this doesn’t:

select * from person-(friendship)-person limit 3

is deeply disturbing in that it breaks the paradigm I have in my mind about how SQL-like languages should work.

Worse, when I accidently use a Built-in Query without realizing and it works, then I’m getting positive reinforcement for a paradigm that is incorrect.

Clearly, there’s something afoot here in TigerGraph land that I (a noob) haven’t uncovered in the documentation yet. Is there a page that explains this?

Thanks.

[added]
Maybe the “Semantic Check” error message should say something more along the lines that this is not a “built-in query” and you need to reformulate the query as a “non-built-in query” (or whatever the proper phraseology is.)

Is the bottomline that I need to provide a lot more boilerplate code in order to untap the full power of GSQL?

6

We probably should not have called them built-in GSQL queries but simply built-in queries.
The table at https://docs.tigergraph.com/start/gsql-examples/common-applications#built-in-queries is the entire syntax supported by the built-in queries.

They are a remnant of some early work that was done before GSQL was introduced.
They are handy for checking how many vertices you have, or to do a spot check of some data you inserted.

There is no plan to ever expand upon them; we are more likely to drop them when we add more syntax sugar to GSQL so that writing ad hoc GSQL queries by hand is even more streamlined.

7

Could you please improve the error message to be more informative?

I’m certain “Semantic Check Fails” is meaningful to the developers but it’s not all intuitive to newbies.

“Semantic Check Fails” is also not explained here: