[DSIP-] Rename field `operator` to `modify_user_id`

[sdhzwc]

Search before asking

• [x] I had searched in the DSIP and found no similar DSIP.

Motivation

The field named "operator" in the project should be modified to "modify_user_id" for better clarity and easier maintenance

1. First modify the backend code uniformly
2. Then unify the table fields in backend
3. Not involving the front-end UI, no adjustments needed

Design Detail

Incompatible changes

• Rename backend code fields from operator to modifyUserId.
• Rename tables fields from operator to modify_user_id.

These incompatible changes may affect users of secondary development based on API and Database.

Compatibility, Deprecation, and Migration Plan

No response

Test Plan

Test by UT.

Code of Conduct

• [x] I agree to follow this project's Code of Conduct

[SbloodyS]

If this is to be optimized, all relevant frontend and backend codes and table field names need to be modified uniformly. You should create an DSIP first.

[sdhzwc]

If this is to be optimized, all relevant frontend and backend codes and table field names need to be modified uniformly. You should create an DSIP first.

Modified

[SbloodyS]

Not all operator fields are modify_user_id. It may represent the creator. You should distinguish between them.

[sdhzwc]

Not all operator fields are modify_user_id. It may represent the creator. You should distinguish between them.

ok

[ruanwenjun]

I don't disagree with this issue, but this kind of change will bring some incompatible changes. Before making any of these kinds of changes to db schema and API schema, need to make a specification firstly, and list all the fields that need to be changes, otherwise this looks very much like a random personal alteration. In the future, if someone think some fields is not suitable, he might submit another pr to change again, will bring an incompatible changes again.

[sdhzwc]

I don't disagree with this issue, but this kind of change will bring some incompatible changes. Before making any of these kinds of changes to db schema and API schema, need to make a specification firstly, and list all the fields that need to be changes, otherwise this looks very much like a random personal alteration. In the future, if someone think some fields is not suitable, he might submit another pr to change again, will bring an incompatible changes again.

#16515 In fact, the ideas are similar. Whether to make changes can be discussed, 和 the operation can be postponed if there is not enough support. What do you think?

[ruanwenjun]

In fact, the ideas are similar. Whether to make changes can be discussed, 和 the operation can be postponed if there is not enough support. What do you think?

This isn't similar to https://github.com/apache/dolphinscheduler/issues/16515, https://github.com/apache/dolphinscheduler/issues/16515 has been discussed long time ago, it is not a simple rename operation or code style change, It's a conversion of concepts between workflow and process.