[
https://issues.apache.org/jira/browse/THRIFT-4685?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17248423#comment-17248423
]
Yuxuan Wang commented on THRIFT-4685:
-------------------------------------
parquet-go is actually the exact example for "the compiler gets mixed in".
If you look into the source, they committed the thrift compiled go files into
git: https://github.com/xitongsys/parquet-go/blob/master/parquet/parquet.go.
The first line is a lie, it's certainly not generated by thrift 0.12.0. My
guess would be that the author manually modified that thrift compiled go file
to fix the breaking change introduced by the upgrade of go library (in go.mod),
instead of building the compiler from the same version as the library (it's not
released yet so there's no pre-built compiler for that version available in the
wild) and run the actual compiler to regenerate the file.
When things are done properly, it should have the thrift compiled go ran from
the thrift compiler that's the same version of the thrift library they depend
on. If that's the same version your code uses, then everything is fine. But if
that's a different and incompatible version from the version your code uses,
even if they have a different import path, there will be a lot of problems for
them to co-exist. For example, in parquet-go, an exported API,
[page.ReadPageRawData|https://github.com/xitongsys/parquet-go/blob/cb8d8853825eb1adfd98e356d8a0785985daac83/layout/page.go#L390],
takes *thrift.TBufferedTransport as the type of one of its args. In that API
the package "thrift" must be thrift in the version parquet-go uses, not the
version your code uses. So when your code needs to call that API, you need to
convert whatever thrift-v2.TBufferedTransport into thrift.TBufferedTransport to
be able to call that function.
I'm aware of protobuf's apiv2 approach. The key difference between protobuf's
case and thrift's case is that protobuf's go API is much more mature and
stable. They can maintain backward compatibility in all their pre-v2 API, and
this is the first breaking change they are introducing in a long time. As a
result, this kind of breaking change upgrade is more like a one-time thing,
that they do once in a lot of years. They also only anticipate 2 incompatible
versions to co-exist in the foreseeable future, and supporting 2 versions at
the same time is something manageable. In thrift's case, we could have breaking
changes every year, if we go that approach we would get into the situation that
we have to support 4 versions at the same time after 4 years. Thrift is an open
source project maintained by volunteers (while protobuf is backed by Google),
and we really don't have the resource to do that. Protobuf's approach does have
the benefit of import path does not need to match the version tag, though.
> Support the new golang modules (1.11 or later)
> ----------------------------------------------
>
> Key: THRIFT-4685
> URL: https://issues.apache.org/jira/browse/THRIFT-4685
> Project: Thrift
> Issue Type: Improvement
> Components: Go - Library
> Affects Versions: 0.12.0
> Environment: golang 1.11 or later
> Reporter: James E. King III
> Assignee: Duru Can Celasun
> Priority: Minor
>
> Go added new module support in 1.11, see:
> https://github.com/golang/go/wiki/Modules
> We should move towards it.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
