[
https://issues.apache.org/jira/browse/THRIFT-5340?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17270045#comment-17270045
]
Jens Geyer edited comment on THRIFT-5340 at 1/22/21, 10:24 AM:
---------------------------------------------------------------
{quote}
> A schema can evolve as needed and - following a few simple rules - still be
> held compatible with earlier versions of that schema.
Exactly. I was trying to find a list of such simple rules. But I couldn't find
them anywhere (maybe I didn't look in the right place?)
{quote}
https://diwakergupta.github.io/thrift-missing-guide/ is a good read.
The "executive summary" re your topic is:
* Field numbers are fix (with regard to the surrounding structure/method call)
and may not be changed nor re-used.
* If a field changes its type, its a different field then. Readers will skip
what they don't know/understand or when an unexpected type comes along.
* Think twice about making a field "required", because it is forever
* Service methods are identified by name, not numbers. This is the only place
where a name is important
{quote}
For example, I'm creating a schema that defines a list of a scalar type. Then,
I transform the schema that has a list of a structure where the scalar is the
first and only element. I then encode data with the old schema and attempt to
decode it with the new schema, and viceversa, to determine if the schema
transformation is forwards, backwards, or fully compatible.
{quote}
That's a different type then. Will not work.
As a kind of best practice, one can make especially return values easily
extensible by defining a struct form the beginning. It is hard to add another
field to the return of this:
{code}
service foo {
int bar()
]
{code}
but instead we could start with this, which is extensible:
{code}
struct bardata {
1: int value
// more here if needed
}
service foo {
bardata bar()
]
{code}
A simolar thing could be done by means of a union, which is especially handy to
serialize stuff:
{code}
union container {
1: bardata bardata
2: foobar foobar
3: baz baz
}
{code}
was (Author: jensg):
{quote}
> A schema can evolve as needed and - following a few simple rules - still be
> held compatible with earlier versions of that schema.
Exactly. I was trying to find a list of such simple rules. But I couldn't find
them anywhere (maybe I didn't look in the right place?)
{quote}
https://diwakergupta.github.io/thrift-missing-guide/ is a good read.
The "executive summary" re your topic is:
* Field numbers are fix (with regard to the surrounding structure/method call)
and may not be changed nor re-used.
* If a field changes its type, its a different field then. Readers will skip
what they don't know/understand or when an unexpected type comes along.
* Think twice about making a field "required", because it is forever
* Service methods are identified by name, not numbers. This is the only place
where a name is important
{quote}
For example, I'm creating a schema that defines a list of a scalar type. Then,
I transform the schema that has a list of a structure where the scalar is the
first and only element. I then encode data with the old schema and attempt to
decode it with the new schema, and viceversa, to determine if the schema
transformation is forwards, backwards, or fully compatible.
{quote}
That's a different type then. Will not work.
As a kind of best practice, one can make especially return values easily
extensible by defining a struct form the beginning. It is hard to add another
field to the return of this:
{code}
service foo {
int bar()
]
{code}
but instead we could start with this, which is extensible:
{code}
struct bardata {
1: int value
// more here if needed
}
service foo {
bardata bar()
]
{code}
> Document schema evolution features
> ----------------------------------
>
> Key: THRIFT-5340
> URL: https://issues.apache.org/jira/browse/THRIFT-5340
> Project: Thrift
> Issue Type: Improvement
> Components: Documentation
> Reporter: Juan Cruz Viotti
> Priority: Minor
> Original Estimate: 24h
> Remaining Estimate: 24h
>
> I could not find a section in the documentation outlining the schema
> evolution/versioning features that Thrift provides.
> In case there is none, I volunteer to write the first draft, as I've been
> writing a paper involving Apache Thrift as part of my MSc at University of
> Oxford, and ran plenty of schema evolution experiments.
> Please let me know your thoughts and where would this section fit!
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)