Generalize UniqueIndex keys

[maurolacy]

Closes #209.

Use generic index keys in UniqueIndex, so we can prefix() and range() over them.

[ethanfrey]

Looks good. I would make the key less opaque now (no need for index_int hidden away... at least for UniqueIndex).

Otherwise, I would add a testcase for composite index. I don't know, maybe another type... where (first_name, last_name) must be unique, but each alone can exist.

John Doe
John Wayne
Maria Doe

are all fine, but adding a second John Doe will return an error.

[ethanfrey]

Also note these storage-plus changes may be api breaking... If any contracts have to be modified when doing so, please label that api breaking in the title (meaning it must be v0.5.0 not v0.4.1)

[maurolacy]

Also note these storage-plus changes may be api breaking... If any contracts have to be modified when doing so, please label that api breaking in the title (meaning it must be v0.5.0 not v0.4.1)

Good point. This doesn't happen here AFAIK, but it can happen with changes to MultiIndex. Will take it into account in general.

[maurolacy]

prefix() and range() now work as expected. But, they are the "canonical" impl. That is, they require Prefix to be over the value type, i.e. Prefix<T>.

Given that range() is a method of Prefix<T>, there isn't much else that can be done here. That means that, on one side, I had to make the value type used in the UniqueIndex map (called UniqueRef) public. On the other, I cannot change the structure / format of these returned values; because range() is outside my control.

I'm thinking that a good way forward could be to create a MappedPrefix type, which can build prefixes over arbitrary value types, but then accepts a mapping function as a parameter, in order to transform these arbitrary values to our desired types during ranging / iteration. That way, we can specify generic types (i.e. our desired <T>) as outputs, and use indirections internally; whose values are then "magically" mapped to <T>.

Something like you're already doing in pks(), items(), etc., but generic / parametric. And, contained in its own type.

[maurolacy]

I'm thinking that a good way forward could be to create a MappedPrefix type

Done in the latest commits. Not with a new MappedPrefix type, but by simply generalizing Prefix's deserialization function.

[maurolacy]

These commits are mostly a rebase from master.

I would like to merge this, as I think it's stable.

[ethanfrey]

I would use a different name, but I see this extension, and good to keep the default behavior the same.

Definitely need more time to review this

[maurolacy]

Yes, I was struggling when naming it.

Maybe new_custom_de?
Another option would be to keep only new, and add a helper method set_de_fn or so. But I think it's more confusing / unclear.

[maurolacy]

Take your time to review this. It's a more complex variant of the unique index case, but in the end it's the same mechanism: when creating the Prefix, a custom deserialization function is passed, which handles the indirection.

I couldn't make it simpler, because of the different maps / namespaces, and the need to access the store.

[maurolacy]

I meant, the related PR for the multi index.