You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Aug 3, 2023. It is now read-only.
In https://github.com/regen-network/cosmos-modules/pull/14/files#diff-cd553207888c76d3acb6e9284c4e02e4, group member table and vote table are effectively "join tables" and their primary key is derived from two fields rather than one. Having them as natural key tables is a bit inefficient because then two indexes are needed, when this could be reduced to one with the table itself serving as an index in one direction. For example, the group member primary key is just concat(group, member) so this is sufficient for prefix scans already (assuming we add a final length byte).
So what about a JoinTable that instead of NaturalKeyed takes an interface like:
typeJoinKeyedinterface {
JoinKeys() [][]byte
}
Then the interface for JoinTable could be something like:
In https://github.com/regen-network/cosmos-modules/pull/14/files#diff-cd553207888c76d3acb6e9284c4e02e4, group member table and vote table are effectively "join tables" and their primary key is derived from two fields rather than one. Having them as natural key tables is a bit inefficient because then two indexes are needed, when this could be reduced to one with the table itself serving as an index in one direction. For example, the group member primary key is just
concat(group, member)
so this is sufficient for prefix scans already (assuming we add a final length byte).So what about a
JoinTable
that instead ofNaturalKeyed
takes an interface like:Then the interface for
JoinTable
could be something like:Thoughts @alpe?
The text was updated successfully, but these errors were encountered: