Best Practices for adding new Vertex ID values

Can anyone tell me what are the Best Practices for adding new vertex ID values. Or, will V3 have an auto-number option for INT and UINT?

If there are many client apps adding new vertices then this needs to be managed centrally either in the graph db or on the web server in the data access method.

An easy solution would be to use GUIDs for Primary Keys, but I would like to avoid that and use INT or UNIT if possible.

Thank you.

Best practice here is the same as for all databases, that the primary key should either be related to a physically unique value, or generated by the client. This is true for any database technology. The reason to do it this way is that it allows you to be relatively failure proof, so that it is okay to retry any insertion and not worry that you will end up with duplicate values.

We do not currently have an auto-number option, though it is possible we will get one, but my advice is to avoid it if at all possible.

Why do you want the id to be an int or uint?

When I have done this in the past, I have used a client identifier prefix, with a numeric suffix. This avoided the problem of clashing keys between clients who knew nothing about each other.

If there is no other way, and you need server keys, then the best way is to use a stored query which can manage transactional updates to a central counter held on a stored “Counter” vertex, but performance (due to locking and synchronisation overhead) will be much less than the previous options.

1 Like

Thanks rik.
In all apps that we’ve built – in most cases we use GUIDs generated by the client except for small lists that are rarely changed such as values used in a dropdown list. Think of this app as being like twitter with millions of clients adding data. There’s no good logic here for adding prefixes so if an auto-number is not an option, then GUIDs is the only option I can think of.

I didn’t see GUIDs used in any of the TG demos and did see plenty of examples using INTs so I figured there must be a good way to manage this server side.

Thanks again.