[server] Integrate remote directory selector into table/partition creation#2769
[server] Integrate remote directory selector into table/partition creation#2769LiebingYu wants to merge 1 commit intoapache:mainfrom
Conversation
a510c15 to
c911eb4
Compare
...-server/src/main/java/org/apache/fluss/server/coordinator/remote/RemoteDirDynamicLoader.java
Outdated
Show resolved
Hide resolved
| public void createPartition( | ||
| TablePath tablePath, | ||
| long tableId, | ||
| String remoteDataDir, |
There was a problem hiding this comment.
I am thinking about possible improvements here:
1.
Will it be better to put the remote dir selection logic inside into the MetadataManager.createPartition() and MetadataManager.createTable().
I notice that now there exist some code pattern that (a). select a remoteDataDir value. (b) pass the value into createTable/createPartition functions, when we need to createTable/partition otherwhere.
Put the step(a) inside those functions will make the code more focused and void adding a remoteDataDir parameter in these functions.
Or
2.
Is is good to add the 'remoteDataDir' field into the TablePath class? Make the TablePath object carrys the remote dir info, and pass it through to everywhere. Then we don't need to care about adding an independent remoteDataDir parameter in functions which already has the TablePath parameter.
The implementation now is good to work. Just put my thoughts here. What do you think?
There was a problem hiding this comment.
-
Put the selection into
MetadataManageralso need to change a lot. By comparison, I think the current approach would actually introduce smaller changes. -
TablePathrepresents the logical path of a Fluss table, whileremoteDataDiris the physical storage path in the implementation. I don’t think it’s appropriate to putremoteDataDirintoTablePath.
c911eb4 to
a398846
Compare
b77b6bc to
0818c44
Compare
0818c44 to
860ffd3
Compare
Purpose
Linked issue: close #2755
Brief change log
Tests
API and Format
Documentation