Simulating Auto Increment in VoltDB

Auto incrementing fields are quite useful, particularly for allocating values to primary keys. MySQL has AUTO_INCREMENT and PostgreSQL has a SERIAL data type. VoltDB has neither, nor anything remotely close to them. This brief article will show you how to simulate auto-incrementing fields in VoltDB. It assumes some knowledge of VoltDB.

VoltDB implements a subset of ANSI-standard SQL. It supports the basic CRUD operations (INSERT, SELECT, UPDATE, DELETE) but it does not have support for automatically generating unique identifiers. It is possible, however, to simulate these in VoltDB, as per this entry in the FAQ. What we can do is create a table that stores the name of the table and the current value that can be used as the unique value for, say, a given column. The schema for the table is shown below:

The next step is to create a stored procedure that, when called, will return the current value for a given table. The stored procedure will read the current value, increment it, and then return the value to the client.

The stored procedure looks like this:

import org.voltdb.*;


@ProcInfo (    partitionInfo = "IDENTIFIER.TABLE_NAME: 0",    singlePartition = true  )  public class GenerateUniqueIdentifier extends VoltProcedure {      public final SQLStmt select = new SQLStmt(      "SELECT CURRENT_VALUE FROM IDENTIFIER WHERE TABLE_NAME = ?"    );      public final SQLStmt update = new SQLStmt(      "UPDATE IDENTIFIER SET CURRENT_VALUE = CURRENT_VALUE + 1 " +      "WHERE TABLE_NAME = ?"    );      public VoltTable[] run(String tableName)      throws VoltAbortException {          voltQueueSQL(select, tableName);        VoltTable[] idResult = voltExecuteSQL();          voltQueueSQL(update, tableName);        voltExecuteSQL(true);          return idResult; // Return the current value for the table    }  }

As this procedure demonstrates, it is possible to execute multiple SQL statements from inside a stored procedure. It also highlights the advantage of having single-threaded partitions. The table is partitioned on the table name therefore the current value for a given table (each row) is stored in a single partition. As each partition is single-threaded, and stored procedures are run sequentially, there is no risk of the current value for a given table being altered between the time the procedure reads the current value and updates it; this would not be the case in a multi-threaded environment where some kind of locking would have to be used.

With the stored procedure in place, it can be called at will. The returned values can then be used in subsequent calls to other stored procedures. And that is how you can simulate auto-increment in VoltDB. At some point I will upload a complete working solution. Checkout the autoincrement branch of my example VoltDB project to play around with some working code that implements the above. The End.

7 thoughts on “Simulating Auto Increment in VoltDB

  1. Tim Callaghan

    Another option, if you can get by with just two unique values per stored procedure invocation, is to use the positive and negative values of getTransactionId() from within the stored procedure.  I wrote up this in the following post, 


  2. Zithromax dosage

    Hi Tom,

    No, I haven’t tried using VoltDB with Alfresco. VoltDB only supports a subset of SQL so would be interesting to see if it would be possible to port Alfresco’s database schema to it. Is this something you are considering doing?


  3. Ryan Betts

    If you need unique but not necessarily auto-increment, you might also consider the builtin as mentioned by Tim.  Note that the unique id generated by this example will not be globally unique — it will only be partition-wise unique — which is very different. 

  4. Priidu

    How come will the ID generated by the example above be unique only partition-wise? I can’t see it for some reason…

Leave a Reply