Add new method ApplyTag

[haoxins]

What type of PR is this?

• bug
• feature
• enhancement

What problem(s) does this PR solve?

Issue(s) number:

Description:

ApplyTag applies the given tag to the graph.

1. If the tag does not exist, it will be created.
2. If the tag exists, it will be checked if the fields are the same.
2.1 If not, the new fields will be added.
2.2 If the field type is different, it will return an error.
2.3 If a field exists in the graph but not in the given tag,
it will be removed.

Notice:
We won't change the field type because it has
unexpected behavior for the data.

How do you solve it?

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

[codecov-commenter]

Codecov Report

Attention: 14 lines in your changes are missing coverage. Please review.

Comparison is base (b220b12) 63.70% compared to head (747dec2) 64.32%.

Files	Patch %	Lines
schema_manager.go	75.00%	10 Missing and 4 partials ⚠️

❗ Your organization needs to install the Codecov GitHub app to enable full functionality.

Additional details and impacted files

@@            Coverage Diff             @@
##           master     #317      +/-   ##
==========================================
+ Coverage   63.70%   64.32%   +0.61%     
==========================================
  Files          10       11       +1     
  Lines        2579     2643      +64     
==========================================
+ Hits         1643     1700      +57     
- Misses        797      802       +5     
- Partials      139      141       +2     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[wey-gu]

This sugar on Client Side is so very inspiring.

We should consider do similar things on all Clients.

[Nicole00]

This is a very convenient interface that can provide users with an encapsulated and convenient interface. Thanks for your idea.
I'm thinking whether it's appropriate to put such syntactic sugar inside the client? Are their application scenarios general enough? After all, the client serves as an SDK rather than an ORM framework. Maybe we can add these sugar in another go file to differentiate from session or session_pool. What's your idea? @haoxin @wey-gu

[haoxins]

Maybe we can add these sugar in another go file to differentiate from session or session_pool.

The idea of applying xxx comes from the cloud-native community (or K8s), I think it is the basic requirement of schema management.

The benefit is that we don't need to pass session_pool if we add this into the session_pool struct.

But I agree that it does not belong to session_pool/session.
Do you have an idea for the name of this?

[haoxins]

SchemaManager?

[Nicole00]

SchemaManager?

LGTM. cc @wey-gu

[wey-gu]

Agree with @Nicole00 that it's strange to be placed under the session_pool tent, SchemaManager sounds great to me, too :D

[haoxins]

done cc @Nicole00 @wey-gu

[wey-gu]

We could later have some example/docs to highlight this sweet change :D

[haoxins]

We could later have some example/docs to highlight this sweet change :D

I have another PR for ApplyEdge on the way.
BTW, I don't see the docs for Nebula client or SDKs :)

[Nicole00]

We could later have some example/docs to highlight this sweet change :D

I have another PR for ApplyEdge on the way. BTW, I don't see the docs for Nebula client or SDKs :)

Great! Looking forward to your pr~ we have sdk api doc: https://pkg.go.dev/github.com/vesoft-inc/nebula-go/v3

[Nicole00]

LGTM, Great sugar!