When inserting edge - type of <vertex attribute in key> in the list is not consistent with other elements

GSQL
1

I am getting this error when I try to install a query:

“type of ryr in the list is not consistent with other elements”

and it’s not entirely clear what this mean. ryr is a local variable of type UINT that is set in the ACCUM section using a custom UDF that returns a int64_t value. the UDF works according to the tests and also the LOG statements I have reporting the value.

Where things breaks, it is an INSERT INTO line creating a new edge - the two vertices do already exist (one vertex (D) is the one currently being processed by the ACCUM block; the other (V) has a composite key that is a string, a uint (the ryr value) and another uint)

– INSERT INTO edgeType VALUES (
(aString, ryr, rper), (d.myid, d.stringID, d.year, d.period)),

I have tried changing the type of the return value from the UDF to uint64_t but that doesn’t work. I added a line

INSERT INTO sourceVertexType VALUES (aString, ryr, rper)

before this just to see if things broke / new vertices were created and the compiler did not complain and the code ran. Only when the 2nd INSERT line is present do things break.

Is conversion to/from UINT and INT that fragile? Or something is off with inserts that I do not understand?

Should I:

a) do this creation of an edge in the post-accum block w/ this calculated value being stored for each destination vertex (D)?

b) explicitly fetch the vertex being connected from and use another form of INSERT INTO?

c) redo everything differently?

thanks
Doug

2

bump… any insights on what might be the issue?

4

What is the schema definition for the source and destination vertices? I’ve played around with some variations and they worked, but I may not have the exact schema you do.

5

Aha, I spoke too soon. In a query the insert of a numeric breaks (in the GSQL shell it works fine). This looks like a bug, though I’d note that using numerics in primary keys is historically a little fraught, not for any good reasons. You might try stringifying the numeric to avoid the issue. Meanwhile I’ll raise a JIRA. Thanks for your patience.

6

Hey, no problem. I had an idea the composite key was the issue, but had many other things to deal with so couldn’t fiddle with this any longer. Thanks for the info (and the working pretty well already software); I will revamp the schema.