FQL random and SHA256 functions

[ptpaterson]

You have several different questions here. The incrementing key is probably easier to talk about first.

Auto-Incrementing Keys

This has been covered in a previous topic:

Autoincrement property

Is there any concept of an autoincrement property? In my case, I have an Orders collection and want to use an autoincremenet property. I don’t want to replace the default object id, but rather use another property for a public order number.

1. Every document has a unique id that uses the snowflake algorithm. Whenever you can, you should rely on the id’s provided to new documents.
2. You can use the NewId function to generate an ID as well.
3. You can create a UDF that increments a value, saves it, and returns it. WARNING – this can easily create write-contention issues if you try to call it too often. The linked post mentions “conflict free” counters, which is not implemented yet but still on the roadmap.

Random Numbers

There is no built-in functionality for random numbers, yet. You can get a pseudo-random implementation together using FQL, though. You can follow this discussion in this previous topic:

Random number generation

FQL does not provide random number generation, as its operations attempt to be as deterministic as possible. This is a strange feature to be missing from a language and I don’t see how the attempt to be deterministic is helpful. I need to construct a UDF and connect it with a GraphQL mutation. The UDF requires multiple steps in a transaction where I need to randomly select an item in an array. I have a similar use case where I need to generate a random dice roll. This is trivial in any other…

Depending on your implementation you may also need to worry about contention. For example, this implementation saves a seed value in a document and iterates that seed on every call. If the random function needs called often then the each potential caller (user) can store their own random seed to avoid contention.

Also, let us put a lot of emphasis on pseudo-random. I wouldn’t trust it for anything you actually need crypto-protected. But we know this has been used successfully to offer users random awards, for example.

SHA-256 Algorithm

Today I learned about the SHA-256 algorithm!

Reviewing the explanation here, it is certainly possible to create an FQL expression to calculate a SHA-256 hash. You could even use it as Index binding! FQL is quite powerful that way.

But you should hesitate to use FQL as a general compute engine. Calculating a single SHA-256 could cost 70+ Compute Ops. So, it is probably a very bad idea to create a SHA-256 index binding

Part of this is FQL lacking bit-shift operators. Part of this is that there is plainly a lot of operations to perform.

It’s definitely now on my list to try my hand at it, though!

Working around SHA-256 algorithm

You can provide credentials when you Create a document, and the password is saved as a hashed value. You can also create Credentials Documents directly. If you are interested in storing a hashed value given a string, you might consider creating a document with a password set to that string.

See Security model - Fauna Documentation

Such a document would not be used for login or for providing tokens, but you can still use the Identify function to check a string against that hashed password.