chore(kf): query composed contracts more efficiently

[MicBun]

Description

Applying the suggestion from Brennan to make the query more efficient despite current kwil limitation.
Notes:
The original suggestion is modified:

    return select r.date_value as date_value, sum(r.value) as value from get_record_internal($date_from, $date_to, $frozen_at) as r
    group by r.date_value;

into:

    for $row in SELECT date_value, sum(value) as value FROM get_index_internal($date_from, $date_to, $frozen_at) GROUP BY date_value {
        return next $row.date_value, $row.value;
    }

It will cause errors. It looks like there is a bug on return select ... group, since the for statements works

error calling action: call action: jsonrpc.Error: code = -300, message = ERROR: structure of query does not match function result type (SQLSTATE 42804), data = null
err code = -300, msg = ERROR: structure of query does not match function result type (SQLSTATE 42804)

Related Problem

resolves: #291

How Has This Been Tested?

1. Kwil-cli configure and set private key to 0000000000000000000000000000000000000000000000000000000000000001
2. Run the test get records with taxonomy on composed_stream_contract_test.md file
3. 

[MicBun]

tagging @brennanjl, you may want to take a look at note section. for loop works, but the return select ... group by returned structure of query does not match function result type (SQLSTATE 42804)

[pr-time-tracker]

@outerlook
@zolotokrylin
⚠️⚠️⚠️
You must submit the time spent on this PR.
⚠️⚠️⚠️

[brennanjl]

Just to confirm, using return next works, but returning the query does not?

[brennanjl]

Ah never mind, I have found the source of the bug. Thank you for flagging.

[MicBun]

Just to confirm, using return next works, but returning the query does not?

@brennanjl. Yes, it is. Also which one is considered best practice between those two? I see no difference

[brennanjl]

Yes, it is. Also which one is considered best practice between those two? I see no difference

In general, if you can do it in SQL, you should. It will virtually always be more efficient. Therefore, I'd say the one without return next.

The bug stems from the fact that postgres returns a numeric data type when calling sum on int8. A fix should be up soon

[brennanjl]

FYI, a fix is up here: kwilteam/kwil-db#790. You will need to typecast your sum(r.value) to be an int: sum(r.value)::int. Kwil will automatically treat it as a decimal(1000,0) to prevent overflow. If you are concerned that a sum might lead to overflow, you can keep it as a numeric.

[MicBun]

In general, if you can do it in SQL, you should. It will virtually always be more efficient. Therefore, I'd say the one without return next.
You will need to typecast your sum(r.value) to be an int: sum(r.value)::int. Kwil will automatically treat it as a decimal(1000,0) to prevent overflow.

Alright, thanks for the note. 👍

converted to the draft:

1. Need to change return next with SQL ones
2. Waiting for added tests for decimal kwilteam/kwil-db#790 PR to be merged
3. Re-test result with type assertion

[brennanjl]

@MicBun it just got merged

[MicBun]

@MicBun it just got merged

Alright, thanks!