New virtual index

[alpe]

Add a new index type on top of a natural key table.

Resolves #16 with a different approach

[aaronc]

Could you comment on the pros and cons of this as opposed to the approach in #16?

One thing I would note is that I think #16 potentially simplifies key construction because it doesn't require manual concatenation, you just need to return two byte slices.

[aaronc]

What would you do if the first element doesn't have a fixed size? Is there a way you could use the max 255 dynamic length codec with this?

[alpe]

Without a fixed size we would easily get overlapping results in a prefix scan. We may be able to filter them out with a custom iterator on "simple natural" keys but this is a very special use case.

The one I wanted to cover was a natural key starting with the groupID so that we can have a typed index:
idx := AsUInt64Index(NewVirtualIndex(builder)) without extra costs.

[alpe]

Could you comment on the pros and cons of this as opposed to the approach in #16?

It is a bit hard for me to argue for the one or the other as #16 is not completely clear to me. I can see how it moves the concat one layer down into orm for simple create/get/has operations with all the key parts are available. How would a prefix scan look like? Is there any "special" logic involved in building the RowID from this like adding separater chars, etc?

This Virtual index is based on mostly existing components and logic. In combination with the UInt64Index it can replace a persistent index and save gas on IO. But the concept is probably not very intuitive and the use cases are limited.

[aaronc]

@alpe let's chat about this live next time we get a chance. I want to understand this approach better and think about how it addresses the needs of say that GroupMember table.