Drop `espresso.input_index` table and review other espresso schema tables

[miltonjonat]

• The espresso.input_index table is unnecessary: the same information info is available in public.application table's processed_inputs field
• Other tables should be refactored to use application.id instead of address, to ensure database consistency

[ZzzzHui]

The espresso.input_index table is unnecessary: the same information info is available in public.application table's processed_inputs field

After looking into this, I think the table is necessary. espresso.input_index is increased when an input is inserted into the db, application.processed_inputs is increased when an input is processed by the advancer. So these two can have different timelines.

Other tables should be refactored to use application.id instead of address, to ensure database consistency

Not sure about how id is better than address in this case.

[miltonjonat]

About espresso.input_index: if that's the case, then couldn't we retrieve the info from the public.input table? Like MAX(index)? And store in cache to make it fast in the general use case.

About application.id: it's about ensuring there's no entry there that doesn't match a registered app. Not sure what happens too if you unregister and re-register an app: maybe the address is the same, but the id (and the processed history) is different!

[ZzzzHui]

if that's the case, then couldn't we retrieve the info from the public.input table? Like MAX(index)?

max operation can take time if the input table grows, especially because there can be many entries from other applications in the input table. espresso.input_index already works best, we don't need to get rid of it and settle for something less performant.

And store in cache to make it fast in the general use case.

There are 2 different packages read/writes this input index. Not sure how to practically keep it in cache.

maybe the address is the same, but the id (and the processed history) is different

Should that affect espresso tables?

[miltonjonat]

maybe the address is the same, but the id (and the processed history) is different

Should that affect espresso tables?

I think so. If an application is de-registered and re-registered, the Node will process it from scratch. This has been designed to work when an application's Consensus is changed, for instance (which is currently expected to generate new claims since genesis). But I think the point is that, whatever the policy is inside the Node, the Espresso tables' info should be compatible with it.

In any case, as discussed in our call today, let's revisit this after #13