Hi Josh,
Sorry that I do not reply at your post, but the page asked me to log in
before I could comment, which I refused to do.
I'm not sure if I agree with you. Soft versioning is a feature, IMHO. The
picture you draw there could be drawn in a similar way, essentially to the
same effect. Let's assume the following struct, which could transport
multiple events at once (notice the
struct DangerousCreaturesEvent {
1: optional i32 FRANKENSTEINS_MONSTERs
2: optional i32 YETIs
3: optional i32 LOCH_NESS_MONSTERs
}
Now I release a new, upgraded version of my ocean sensors, which can also
report Godzillas
struct DangerousCreaturesEvent {
1: optional i32 FRANKENSTEINS_MONSTERs
2: optional i32 YETIs
3: optional i32 LOCH_NESS_MONSTERs
4: optional i32 GODZILLAs
}
We could also do something similar with functions in the service interface.
So we would have the same problem here and there, right?
Yes, and no. The point is NOT, that we have a different type now. Because
that's fully expected, due to the ability to do soft versioning.
The conclusion would be however, if your Tokyo civil defense system
absolutely must be able to detect Godzillas at the time, the new version
becomes available (the quicker the better, because these Godzillas tend to
hit you when you expect them at least) then you should ship your upgrade to
server in Tokyo first, before you put the updates out to the clients at the
coast and out there in the ocean.
FInally, we have to consider that before you finished the update and shipped
it, nobody was there to report any passing Godzillas either, regardless of
enum, struct or whatever else vehicle we used to transport that information.
So it's not really a technical issue, neither seems it specific to enums. It
is merely an organizational thing. In your final notes you wrote, that the
server should drop messages that he could not handle, or thrown an exception
to notify the client about the incompatibility, I absolutely agree. The
important point is, that one should be aware of the perils of soft
versioning and enable the implementation to deal with it in a well-defined
manner.
$0,02
JensG
-----Ursprüngliche Nachricht-----
From: Josh Rosenblum
Sent: Wednesday, November 13, 2013 4:15 PM
To: [email protected]
Subject: Blog post on schema evolution and enums
Hello Thrift-Users,
I've benefited from a lot of third-part documentation on schema design in
Thrift and from the work that's been put into supporting forward and
backward compatibility. One edge case that we at Conductor have run into in
a couple of places involves enums. Unlike a lot of other incompatibilities,
it's pretty easy to make incompatible schema changes to enums without any of
your usual tools helping you; in particular the generated code before and
after a change to allowable enum values will typically not raise compilation
errors. I've tried to gather up some of our experiences and possible
workarounds that reduce the chance of unexpected incompatibilities in a blog
post. Would appreciate any review and comments / corrections. Please shout
out with any errors you see.
http://bit.ly/1boyizy
Thanks!
-Josh
