Bring back ability to define indexes on built in collections

Feature Requests
,
1

In FQLv4, indexes were able to have sources that included built in collections, such as Key. In FQLv10, this capability has been lost. In my use case I am managing several database access keys for different services based on metadata stored on the keys themselves, and efficient access to these keys via indexing as well as applying unique constraints to metadata fields have been extremely useful to this end.

Now that FQLv10 is released, and this feature is missing, it is very difficult to port this from FQLv4. The workaround involves adding extra collections that store a ref to the key. These are cumbersome because it requires extra code to manage this extra collection and to keep it up to date as keys are created, rotated, and deleted. It would be much cleaner if I was able to index the built in collection.

2

I actually found a scenario where I would have to do some major rework as the workaround will not work either.

I have some code that bootstraps new services by giving them a new child database and an admin key within that child database. Once this is created, this secret gets stored into the secrets management solution outside of Fauna. That secrets management solution will use the admin key to rotate the key every so often, which involves creating a new key and deleting the old one. In FQLv4, as I could index on the Key collection, the bootstrap code could reliably look up keys by data.name and see that the named admin key for the service still existed, even after rotation.

Now, since this is not possible in FQLv10, it would have to use Key.firstWhere or something similar and do a full table scan. The tracking collection does not work here as the rotation code and the bootstrapping code are not aware of each other. Since the rotation code deletes the old key after rotation, the bootstrap code is now left with an invalid key reference in its tracking collection. When checking if the key existed, it would return null due to the invalid reference and try to create a new key.

4

So the index is not by name, but instead by a token value located in the custom user data one can set on a key using the data. This token is what the Secrets Manager rotation logic uses to uniquely identify a secret version, so I need to be able to efficiently look up the key that way.

So the index definition would actually be:

collection Key {
    index byToken {
        terms [.data.token]
    }
    unique [.data.token]
}

At the moment it’s 2 per service domain (prod and nonprod) + N*2 keys per service within that domain (prod and nonprod) where N is the number of services. I think I’ve got about 12 at the moment.

I don’t yet foresee a use case where I will need to generate temporary access keys, but it could be applicable in that use case where I imagine indexing on custom user data would become required.

5

I swear there was a response here by @Bryan_Fauna I was replying to earlier. It seems to have disappeared. That’s what the message above was about.