showIndexByID

[sworduo]

What type of PR is this?

• [ ] bug
• [ ] feature
• [☑️] enhancement

What problem(s) does this PR solve?

Issue(s) number:

related to https://github.com/vesoft-inc/nebula/issues/4320

Description:

How do you solve it?

Special notes for your reviewer, ex. impact of this fix, design document, etc:

Checklist:

Tests:

• [ ] Unit test(positive and negative cases)
• [ ] Function test
• [ ] Performance test
• [ ] N/A

Affects:

• [ ] Documentation affected (Please add the label if documentation needs to be modified.)
• [ ] Incompatibility (If it breaks the compatibility, please describe it and add the label.）
• [ ] If it's needed to cherry-pick (If cherry-pick to some branches is required, please label the destination version(s).)
• [ ] Performance impacted: Consumes more CPU/Memory

Release notes:

Please confirm whether to be reflected in release notes and how to describe:

ex. Fixed the bug .....

[Shylock-Hg]

Please add test in tests folder.

[sworduo]

Please add test in tests folder.

How can I get indexID except explain expression? Or could I make an assumption that the indexID of space nba loading by make up in tests are fixed?

[Shylock-Hg]

Please add test in tests folder.

How can I get indexID except explain expression? Or could I make an assumption that the indexID of space nba loading by make up in tests are fixed?

I'm not sure why you added this PR, but in our design, we don't intend to expose any ID of schema.

[sworduo]

we don't intend to expose

For example, in production, a tag may contain 20~30 fields, and the number of associated indexes may near 100 (I have no idea why they need so much, but they did). When we use explain expression to analyze the ngql, it's hard to find the corresponding index by indexID exposed in indexCtx.

[Shylock-Hg]

we don't intend to expose

For example, in production, a tag may contain 20~30 fields, and the number of associated indexes may near 100 (I have no idea why they need so much, but they did). When we use explain expression to analyze the ngql, it's hard to find the corresponding index by indexID exposed in indexCtx.

Ok, but we'd better to expose the name of id in explain. If you don't plan to pull request it, could create a issue.

[sworduo]

we don't intend to expose

For example, in production, a tag may contain 20~30 fields, and the number of associated indexes may near 100 (I have no idea why they need so much, but they did). When we use explain expression to analyze the ngql, it's hard to find the corresponding index by indexID exposed in indexCtx.

Ok, but we'd better to expose the name of id in explain. If you don't plan to pull request it, could create a issue.

That's ok. But should the id of space/tag/edge/index expose in explain any more? Or we just illustrate the name of space/tag/edge/index in explain expression.

[Shylock-Hg]

we don't intend to expose

For example, in production, a tag may contain 20~30 fields, and the number of associated indexes may near 100 (I have no idea why they need so much, but they did). When we use explain expression to analyze the ngql, it's hard to find the corresponding index by indexID exposed in indexCtx.

Ok, but we'd better to expose the name of id in explain. If you don't plan to pull request it, could create a issue.

That's ok. But should the id of space/tag/edge/index expose in explain any more? Or we just illustrate the name of space/tag/edge/index in explain expression.

Both is better.

[codecov-commenter]

Codecov Report

Merging #4363 (4a45b49) into master (1644523) will increase coverage by 0.02%. The diff coverage is 92.85%.

@@            Coverage Diff             @@
##           master    #4363      +/-   ##
==========================================
+ Coverage   84.82%   84.85%   +0.02%     
==========================================
  Files        1343     1345       +2     
  Lines      133544   134503     +959     
==========================================
+ Hits       113279   114132     +853     
- Misses      20265    20371     +106     

Impacted Files	Coverage Δ
src/graph/validator/MaintainValidator.h	62.50% <ø> (ø)
src/graph/executor/maintain/EdgeIndexExecutor.cpp	90.15% <66.66%> (-0.55%)	:arrow_down:
src/graph/executor/maintain/TagIndexExecutor.cpp	90.15% <66.66%> (-0.55%)	:arrow_down:
src/graph/executor/algo/ShortestPathBase.cpp	51.63% <100.00%> (+0.64%)	:arrow_up:
src/graph/planner/plan/Maintain.h	88.84% <100.00%> (+0.29%)	:arrow_up:
src/graph/validator/MaintainValidator.cpp	75.74% <100.00%> (+0.11%)	:arrow_up:
src/parser/MaintainSentences.cpp	82.19% <100.00%> (+0.29%)	:arrow_up:
src/parser/MaintainSentences.h	86.62% <100.00%> (+0.17%)	:arrow_up:
src/parser/test/ParserTest.cpp	100.00% <100.00%> (ø)
src/storage/mutate/AddEdgesProcessor.cpp	77.86% <100.00%> (+0.08%)	:arrow_up:
... and 63 more

---

Continue to review full report at Codecov.

Legend - Click here to learn more Δ = absolute <relative> (impact), ø = not affected, ? = missing data Powered by Codecov. Last update 2d319e9...4a45b49. Read the comment docs.

[xtcyclist]

An conclusion has been reached that internal representations shall not be exposed via nGQL. Thus, I close this PR. In #4320, we can discuss more on how to improve the display of indexes.