ORM codegen

[aaronc]

We may want to codegen a friendly client API than what we can do just with #10735. Details to be determined based on whatever shortcomings arise with #10735.

[aaronc]

/cc @fdymylja

[aaronc]

Here's what I'm currently thinking in terms of design.

Let's consider this simplified bank schema which by convention we could store in a file call state.proto

// state.proto

package bankexample;

message Balance {
  option (cosmos.orm.v1alpha1.table) = {
    id: 1;
    primary_key:{fields: "address,denom"}
    index: {id: 1 fields: "denom"}
  };

  string address = 1;
  string denom = 2;
  uint64 amount = 3;
}

message Supply {
  option (cosmos.orm.v1alpha1.table) = {
    id: 2;
    primary_key:{fields: "denom"}
  };

  string denom = 1;
  uint64 amount = 2;
}

This would generate two Store interfaces for Balance and Supply and one combined StateStore interface with its name derived from the file name state.proto. (If there are multiple files with ORM definitions in the same package we probably wouldn't try to combine them.)

type StateStore interface {
	BalanceStore
	SupplyStore
}

type BalanceStore interface {
	HasBalance(address string, denom string) (found bool, err error)
	GetBalance(address string, denom string) (*testpb.Balance, error)
	InsertBalance(*testpb.Balance) error
	UpdateBalance(*testpb.Balance) error
	SaveBalance(*testpb.Balance) error
	DeleteBalance(*testpb.Balance) error
	ListBalance(BalanceIndexKey, ...ormlist.Option) (BalanceIterator, error)
	ListBalanceRange(from, to BalanceIndexKey, ...ormlist.Option) (BalanceIterator, error)
        DeleteBalanceBy(BalanceIndexKey) error
}

type SupplyStore interface {
  ...
}

with index key types like this:

type BalanceIndexKey interface { ... }

type BalanceAddressDenomKey struct {	address, denom *string }

type BalanceDenomAddressKey struct { denom, address *string }

var _, _ BalanceIndexKey = BalanceAddressDenomKey{}. BalanceDenomAddressKey

func (k BalanceAddressDenomKey) WithAddress(address string) BalanceAddressDenomKey { ... }

func (k BalanceAddressDenomKey) WithAddressDenom(address, denom string) BalanceAddressDenomKey { ... }

func (k BalanceDenomAddressKey) WithDenom(denom string) BalanceAddressDenomKey { ... }

func (k BalanceDenomAddressKey) WithDenomAddress(denom, address string) BalanceAddressDenomKey { ... }

a range query with partial keys might look like:

it, err := stateStore.ListBalanceRange(
  BalanceAddressDenomKey{}.WithAddress("bar"),
  BalanceAddressDenomKey{}.WithAddress("foo"))

In terms of context.Context, we'd either need to add it as a param to each of the methods above or we could maybe get away with something like this where context isn't needed for every method:

type keeper struct {
  stateStoreAccessor bankexample.StateStoreAccessor
}

func (k keeper) Send(ctx context.Context, from, to, denom string, amount uint64) error {
  stateStore := stateStoreAccessor.Open(ctx)
  ...
}

I think we could get away with this accessor approach better with codegen than the current API because with the current API you probably want to statically store all the tables and indexes on the keeper like in

cosmos-sdk/orm/model/ormdb/module_test.go

Lines 29 to 35 in 5622115

	type keeper struct {
	balanceTable ormtable.Table
	balanceAddressDenomIndex ormtable.UniqueIndex
	balanceDenomIndex ormtable.Index
	supplyTable ormtable.Table
	supplyDenomIndex ormtable.UniqueIndex

---

What do you think @fdymylja @technicallyty ?

[technicallyty]

+1 It looks like this design will simplify spinning up a module with the ORM by reducing boilerplate code. Are there any downsides to this approach?

[aaronc]

+1 It looks like this design will simplify spinning up a module with the ORM by reducing boilerplate code. Are there any downsides to this approach?

generally the only downside I can think of is the dev time to write the codegen. but that will pay off many fold IMHO