2

I'm developing a real-time web app. The back end is NodeJS and ArangoDB. I would like to generate and send a unique _key to the web app in advance of creation of a document. That way the document can be created quickly on the fly without having to wait for a response from the server with the newly generated ID. To clarify:

  1. User logs in and Web app receives unique key from ArangoDB (via NodeJS)
  2. User creates a new document and Web App assigns it the unique key it was given in step 1
  3. Web app immediately requests a new unique key for use now that the previous one is being used
  4. User saves the newly created document to one of many collections in the database using the unique key from step 1
  5. Web app updates it's local cache of documents without needing to wait for auto generated key from database
  6. Begin again at step 2

This is just a rough overview of the intended workflow. I believe CouchDB has a function that will provide a user with unique ID's: http://docs.couchdb.org/en/1.6.1/api/server/common.html?highlight=id#get--_uuids

I did find this code in the ArangoDB documentation:

FOR i IN 1..10
  INSERT { value: i } IN test
  RETURN { _key: NEW._key, value: i }

It creates a batch of unique keys in a collection. However, I was unsure if the keys generated here would be unique for ALL collections or, what seems more likely, just the collection they are generated for. My app needs a key that could be used for any collection.

Is there a way to fetch one or more unique keys that could be used on multiple collections from ArangoDB? Is there a different way to approach this issue?

skinneejoe
  • 3,921
  • 5
  • 30
  • 45
  • if you dont care for ugliness of uuids, why not creating [uuids](https://www.npmjs.com/package/uuid) or even [sequential uuids](https://www.npmjs.com/package/sequential-guid) in nodejs itself? – raoof hojat Oct 21 '15 at 04:51

1 Answers1

7

Keys are always relative to the collection. The full document _id always consists of the collection name and the document key.

If you want to define keys yourself, you can simply provide a _key property as part of the document when saving it to the w collection. Of course this means it becomes your application's responsibility to pick unique keys and resolve any conflicts (i.e. failed saves due to duplicate keys). UUIDs are a good option if you don't mind the format.

Alan Plum
  • 10,814
  • 4
  • 40
  • 57
  • Thanks I don't know why I didn't think of generating my own unique keys in Node, duh... And thanks to @raoof hojat for his comment on my original post suggesting [sequential ids](https://www.npmjs.com/package/sequential-guid), I think I will probably go that route. – skinneejoe Oct 21 '15 at 13:35
  • @skinneejoe Just keep in mind with sequential IDs that you can't easily keep them in sync if you are going to spread out your node app to multiple processes. – Alan Plum Oct 22 '15 at 13:00
  • ok good to know. But with uuids it's easier correct? Maybe I will go that route, I'm not too concerned about the look of the ID. – skinneejoe Oct 22 '15 at 16:17
  • you could use one collection to obtain the new `_key` values, and then use them insert the documents into another collection. That way you can avoid the overhead of update, and have the database generate the IDs for you. – dothebart Oct 23 '15 at 08:29
  • @dothebart That would not solve the problem of duplicate keys, though, would it? I don't think auto-generated keys are guaranteed to be globally unique – Alan Plum Oct 24 '15 at 12:46
  • @pluma they're only unique per instance, so yes, you shouldn't shard this collection. – dothebart Oct 26 '15 at 08:59