yuqi1129 commented on PR #5634:
URL: https://github.com/apache/gravitino/pull/5634#issuecomment-2516680798
> > > I think we should not simply delete this configuration, it would be
better to 1) make it deprecated; 2) keep the compatible if user set this
configuration; 3) warn user that this configuration is deprecated.
> >
> >
> > I'm not 100% clear on why we only need to deprecate it. The change in PR
is a compatibility modification, and the previous one was not very elegant in
design.
> > for the user which uses `fs.gvfs.filesystem.providers` in 0.7.0 will
definitely work in 0.8.0 after this change is merged.
>
> Can you please explain more why it is compatible?
In 0.7.0, If the user does not specify `fs.gvfs.filesystem.providers` , it
won't work even though the corresponding bundle jar has been placed in the
classpath.
After this PR is merged, if users:
1. Assign `fs.gvfs.filesystem.providers` a value like `s3`, this
configuration will not take effect, as long as the AWS-bundle are in the
classpath, the GVFS client can always use it.
2. Do not set `fs.gvfs.filesystem.providers` a value, the GVFS client will
automatically load all file system providers in the classpath, things are also
okay.
The only difference is that if users put `aws-bundle` and `gcs-bundle` in
the classpath, and then they do not assign a value to
`fs.gvfs.filesystem.providers`, Gravitino will throw exceptions in 0.7 but work
well in 0.8.0. In my opinion, the behavior in 0.8.0 is more acceptable and
reasonable. GVFS clients should be transparent to file system providers.
Please correct me if I'm wrong, thanks.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
