So this is a tip that catches people out a lot, and is to do with TigerGraph transactions.
It’s like this, if you write out a vertex or an edge inline with your code in a GSQL function, you cannot read it again. Similarly, if you delete something, it won’t disappear.
This is actually quite clever in that it enables efficient distributed processing (all updates don’t need to fly around the cluster on each synchronisation step), but it can be a surprise for those of us who come from a SQL background.
Accumulators are your friend for this kind of thing, though they can’t help you with inserts. My best suggestion here is to make global lists of tuples your friend, and perform all updates at the very end of the function. This can also make debugging much much easier (print those lists!), so is not such a bad thing.
2 Likes
I would further explain it this way:
In TigerGraph, the term “query” refers to a named procedure which can contain several reads and writes. The whole query is treatws as one transaction. Insert and Delete operations don’t became visible, even to other parts of the same query, until the entire query is finished and committed.
2 Likes
Victor is (of course) absolutely correct. Reading my post back, I think I need to make my own clarification as it could be misinterpreted and I’ve passed the edit period (doh):
if you write out a vertex or an edge inline with your code in a GSQL function, you cannot read it again within the same function.
That was kind of important. I wasn’t saying all inserts/deletes just vanished never to be seen again. Nope. Definitely not. Just within the same transactional scope, which is the top-level function call (as Victor points out).
When I first bumped into this, it felt odd (30 years of SQL rather set my assumptions), but now, it feels quite natural. The graph state remains as a perfect snapshot from beginning to end, and you don’t need to be concerned that something you have done will affect later code i.e. the snapshot will remain entirely consistent. When adjusting edges at any sort of scale this really avoids problems, and a simple OrAccum accumulator can be attached if you want to avoid revisiting edges/vertices.
2 Likes
