These are unsorted indexes that contain all the vertices that have the label the indexes are for (one index per label). These kinds of indexes get automatically generated for each label used in the database.
Whenever something gets added to the record we update the index (add that record to index). We keep an index which might contain garbage (not relevant records, because the value got removed or something similar) but we will filter it out when querying the index. We do it like this because we don’t have to do bookkeeping and deciding if we update the index on the end of the transaction (commit/abort phase), moreover current interpreter advances the command in transaction and as such assumes that the indexes now contain objects added in the previous command inside this transaction, so we need to update over the whole scope of transaction (whenever something is added to the record).
These kinds of indexes are internally keeping track of pair (record, vlist). Why do we need to keep track of exactly those two things?
Problems with two different approaches
VersionList for creating an accessor (this in itself is a deal-breaker).VersionList.VersionList we can’t reach the newly created record.VersionList in the index.VersionList, checking if it should be removed implies checking all the reachable records, which is not thread-safe. Second, there are issues with concurrent removal and insertion. The cleanup thread could determine the vertex/edge should be removed from the index and remove it, while in between those ops another thread attempts to insert the VersionList into the index. The insertion does nothing because the VersionList is already in, but it gets removed immediately after.Because of inability to keep track of just the record, or value, we need to keep track of both of them. Resolution of problems mentioned above, in the same order, with (record, vlist) pair
vlist.find(current transaction) will get us the newest visible record