Error with Edge Pairs - 'Loading statement should specify FROM vertex'

GSQL
#1

First time Tigergraph user basic question: I have an edge that can take its source vertex as one of two types, specified as follows:

CREATE UNDIRECTED EDGE is_type_of (
FROM square, TO shape | FROM circle, TO shape)

Now square and circle id’s are globally unique. Square’s id’s begin exclusively with ‘S_’ and circle’s begin with ‘C_’. I want to import my simple two column shapefile that contains all these links as follows:

LOAD shapefile TO EDGE is_type_of VALUES ($0 "square", $1)
    WHERE gsql_substring($0,0,2)=="S_"
LOAD shapefile to EDGE is_type_of VALUES ($0 "circle", $1)
    WHERE gsql_substring($0,0,2)=="C_"

but of course this fails because gsql_substring is an attribute function and not available as a WHERE function. Alternatively I’d like to find some way of expressing

LOAD shapefile TO EDGE is_type_of VALUES
    ($0 gsql_substring($0,0,2) =="S_" ? "square" : "circle",
    $1);

It seems as thought the functionality is almost there but I just can’t close the loop. Or do I need to preprocess the import file?

#2

Hi @rom_chavalier, welcome to our community.

I think we have two possibilities to solve this.

  1. using a UDF (then geting boolean back, i.e. S_ would be true, C_ would be false
    https://docs.tigergraph.com/dev/gsql-ref/ddl-and-loading/creating-a-loading-job#user-defined-token-functions
  2. expand your import file with a new field “S” or “C”. then you can use WHERE $0 == “C” || WHERE $0 == “S”

Maybe you could try if LIKE is working (WHERE $0 LIKE “S_%” ?

Best,
Bruno

#3

Thanks Bruno, I tried LIKE but it’s not a valid predicate operator in a WHERE clause. I also tried a flavour of your point 2:

LOAD shapefile TO TEMP_TABLE temp(from_v, prefix, to_v)
    VALUES ($0, gsql_substring($0,0,2), $1);
LOAD TEMP_TABLE temp TO EDGE is_type_of VALUES($"from_v" "circle", $"to_v")
    WHERE $"prefix"=="C_";
LOAD TEMP_TABLE temp TO EDGE is_type_of VALUES($"from_v" "square", $"to_v")
    WHERE $"prefix"=="S_";

but i get the same The edge type is_type_of is composed of edge pairs, the loading statement should specify FROM vertex error.

At this point I figure I’m not understanding how to specify FROM vertex for an edge with multiple source vertex types.

I also added a UDF to the TokenBank per your point 1, which successfully compiles and unit tests (after installing g++ to the docker container and fixing all the messed up includes for Boost in nonstandard locations), but I get the same error. So is this even correct to specify the source vertex type as a string literal (ie in the schema I have CREATE VERTEX square(...)):

LOAD shapefile TO EDGE is_type_of VALUES ($0 "square", $1) ?

EDIT Partly answered: Vertex is specified by name, not string literal, ie no quotes. Guess it’s bootstrapping me up the learning curve though! New problem now I don’t understand with my UDF in WHERE clauses:

WHERE myudf_IsPrefixC($0) works OK in the interpreter, but WHERE NOT myudf_IsPrefixC($0) gets complained about with Encountered " "not" "NOT "" at line... - curious quotes and phrasing…

It compiles and gets past the interpreter if I enter as WHERE NOTmyudf_IsPrefixC($0) (ie no space) but then unsurprisingly fails at runtime with Semantic Check Fails: when loading edge is_type_of , UDF NOTmyudf_IsPrefixC is not found in TokenBank.cpp. Parsing issue with interpreter? Is there a bugtracker somewhere?

#4

Maybe use a temp table that has all the fields/columns of your data source, plus one more column to indicate the type. This indicator could be extracted from the ID in round 1 (gsql_substring()), and then in round 2 you can use this in the WHERE condition.
I think it would work. Unless of course if you have gigabytes of data to load in one round (not sure how much data a temp table can hold, but I think it is maintained in memory, so there is an upper limit for sure).

#5

Thanks, yes I tried a TEMP_TABLE as in the script above but it didn’t work (realised my syntax error later on) so I ended up creating a UDF which did work, except for what seems to be a WHERE NOT parsing bug in the gsql interpreter (which I worked around by creating a second negating UDF rather than being able to use the WHERE NOT clause). Is there an appropriate place to report a bug?