Adding two vertices with an edge as one transaction

GSQL
#1

Hello all.
I’d like to write a query to insert two new vertices and then insert an edge that connects them.

As a created query considered as a single transaction, I believe the two inserted vertices will not yet be committed before the query ends, therefore not available for the edge to be inserted.

What would be the right approach to achieve this task so that I have a single query to call that inserts the two vertices with the edge between them?

#2

That is the correct approach. You can do that in a single query. Here is the documentation with a sample that illustrates this approach https://docs.tigergraph.com/dev/gsql-ref/querying/data-modification-statements#query-body-insert

#3

Thanks Jon.
So, my assumption that the newly inserted vertices are not available later in the query - was wrong.
I can immediately use those vertices as I insert them while the query is still executing.

Thanks!

#4

Yes, you can insert them all as a single transaction. One quirk to be aware of is that you can’t query inserted vertices inside the transaction. Probably not an issue for you, but just in case!

#5

Thanks rik!
Somewhat confusing that the inserted vertices are available for adding an edge on them, but not for other (“select”) queries…

#6

It’s because of the way we handle transactions. We use Snapshot/MVCC (Multi-version Concurrency Control) to implement isolation of concurrent operations. So, in the new version of snapshot created by your transaction (i.e. within your query) the two edge already exists when you want to create the edge between them, but none of the newly created vertices and edges are visible to other sessions/transactions until you “commit”, i.e. until your query ends. When it does, your updates version of the database state will become part of the new global state, i.e. the vertices and edges become visible to other sessions/transactions.

2 Likes
#7

Hi Szilard.
It is understood that outside of my query, the objects I’m adding are not visible until commit.
But the snapshot taken on query entry, it does not yet include the two vertices I am about to insert within the query.
Still, between the snapshot and the commit, these two vertices are visible for adding an edge to them, but not visible for additional sub-select query.
OK, as long as we know the rules…

#8

They aren’t really visible. It relies on coincidence.

So, for example, if you add an edge where the vertices don’t yet exist, then the storage engine will create the implied vertices with default values in all the fields. If/when the vertices are later created, since we upsert, we get into the same position as if we had done it the other (correct) way round.

You can detect these “fake” vertices as all their fields will be defaults.

Note that there are no errors in these situations. This is the correct and expected behavior, and is one reason why we are so fast.

#9

Yes, Rik, I understand the implementation process.
I’m saying, that the same temporary objects could have also serve a sub-select within the same query - but that is not the case with select - only with insert/upsert of the edge.

#10

helpful conversation here. Thanks everyone :clap:!

  1. Is there a sample code available for loading job that shows how to use commit interval & batch size for transactions.
  2. What are the most important config settings related to processing DB transactions in loading job utility.

would love to explore more

1 Like