chore: update logcall

[andylokandy]

I hereby agree to the terms of the CLA available at: https://docs.databend.com/dev/policies/cla/

Summary

Tests

• Unit Test
• Logic Test
• Benchmark Test
• No Test - Explain why

Type of change

• Bug Fix (non-breaking change which fixes an issue)
• New Feature (non-breaking change which adds functionality)
• Breaking Change (fix or feature that could cause existing functionality not to work as expected)
• Documentation Update
• Refactoring
• Performance Improvement
• Other (please describe):

---

This change is 

[drmingdrmer]

Reviewed 5 of 5 files at r1, all commit messages.
Reviewable status: all files reviewed, 1 unresolved discussion (waiting on @andylokandy)

---

src/meta/api/src/schema_api_impl.rs line 269 at r1 (raw file):

        req: CreateDatabaseReq,
    ) -> Result<CreateDatabaseReply, KVAppError> {
        debug!(req :? =(&req); "SchemaApi: {}", func_name!());

Is it able to keep the struct name SchemaApi in the debug log?

[andylokandy]

Reviewable status: all files reviewed, 1 unresolved discussion (waiting on @drmingdrmer)

---

src/meta/api/src/schema_api_impl.rs line 269 at r1 (raw file):

Previously, drmingdrmer (张炎泼) wrote…

Is it able to keep the struct name SchemaApi in the debug log?

It's not possible in current logcall. But it's possible to upgrade.

[drmingdrmer]

Reviewable status: all files reviewed, 1 unresolved discussion (waiting on @andylokandy)

---

src/meta/api/src/schema_api_impl.rs line 269 at r1 (raw file):

Previously, andylokandy (Andy Lok) wrote…

It's not possible in current logcall. But it's possible to upgrade.

In that case, retaining the manual debug statements is a sensible choice. Given that there are several structures with nearly identical method sets, such as catalog.create_table invoking SchemaApi::create_table.

And having debug statements at the start of each method can be useful. This approach allows for better traceability and understanding of the workflow, especially when diagnosing issues, as opposed to only logging when a method completes.

[andylokandy]

having debug statements at the start of each method can be useful. This approach allows for better traceability and understanding of the workflow, especially when diagnosing issues, as opposed to only logging when a method completes.

For such aspect, I recommend enabling structlog for meta, which will arrange the log in the way functions is call in hierarchy, and is already setup for query

[andylokandy]

The new patch will log the function in full path: fast/logcall#5

[drmingdrmer]

Can you keep the original debug log statement so that I can still get enough information while evaluating the new logging?

[andylokandy]

updated

[drmingdrmer]

Thank you

Reviewed 2 of 2 files at r2, 1 of 2 files at r3, 2 of 2 files at r4, all commit messages.
Reviewable status: all files reviewed, 1 unresolved discussion (waiting on @andylokandy)