sui-field-count: const instead of fn and use it in sui-indexer-alt

[gegaowp]

Description

• change field_count trait from fn to const as we want to use it as part of const def
• use it in sui-indexer-alt

Test plan

1. existing tests for sui-field-count
2. for replacements, I added temp tests to ensure the values before and after were the same, removed them afterwards to avoid unnecessary changes later on when we change struct definition

---

Release notes

Check each box that your changes affect. If none of the boxes relate to your changes, release notes aren't required.

For each box you select, include information after the relevant heading that describes the impact of your changes that a user might notice and any actions they must take to implement updates.

• Protocol:
• Nodes (Validators and Full nodes):
• Indexer:
• JSON-RPC:
• GraphQL:
• CLI:
• Rust SDK:
• REST API:

[vercel]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name	Status	Preview	Comments	Updated (UTC)
sui-docs	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	Nov 1, 2024 8:38pm

3 Skipped Deployments

Name	Status	Preview	Comments	Updated (UTC)
multisig-toolkit	⬜️ Ignored (Inspect)	Visit Preview		Nov 1, 2024 8:38pm
sui-kiosk	⬜️ Ignored (Inspect)	Visit Preview		Nov 1, 2024 8:38pm
sui-typescript-docs	⬜️ Ignored (Inspect)	Visit Preview		Nov 1, 2024 8:38pm

[gegaowp]

@amnn I saw the *_CHUNK_ROWS only exist in these 2 files, while it should be applied to all tables?

[amnn]

So having seen how things are set-up, I think we'll want to make use of FIELD_COUNT slightly differently -- sorry for the churn:

• We need to handle the integration of FIELD_COUNTs differently for concurrent and sequential pipelines. This means we can't do the integration once, in the Processor trait. We need to do it in the concurrent and sequential Handler traits respectively.
• The concurrent::Handler is easiest to integrate with -- it already has a MAX_CHUNK_ROWS parameter whose definition we can replace as you've done here, and this parameter is used by the framework automatically.
• You will also need to remove the overrides for MAX_CHUNK_ROWS in concurrent::Handler impls.
• Sequential pipelines (like this one) don't automatically chunk their rows -- that's done by each implementation of sequential::Handler::commit, so for these ones, the best thing to do is to keep the constants per handler implementation. (we also can't say that e.g. all deletions in sequential pipelines need exactly one bind per row).

[gegaowp]

added temp tests to ensure values are the same before and after, removed them to avoid overheard later on.

[amnn]

Thanks @gegaowp -- the change from a function to a constant looks good, but the integration needs some tweaking, PTAL.

[amnn]

So having seen how things are set-up, I think we'll want to make use of FIELD_COUNT slightly differently -- sorry for the churn:

• We need to handle the integration of FIELD_COUNTs differently for concurrent and sequential pipelines. This means we can't do the integration once, in the Processor trait. We need to do it in the concurrent and sequential Handler traits respectively.
• The concurrent::Handler is easiest to integrate with -- it already has a MAX_CHUNK_ROWS parameter whose definition we can replace as you've done here, and this parameter is used by the framework automatically.
• You will also need to remove the overrides for MAX_CHUNK_ROWS in concurrent::Handler impls.
• Sequential pipelines (like this one) don't automatically chunk their rows -- that's done by each implementation of sequential::Handler::commit, so for these ones, the best thing to do is to keep the constants per handler implementation. (we also can't say that e.g. all deletions in sequential pipelines need exactly one bind per row).