You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@thrift.apache.org by Jonathan Kanarek <Jo...@kaltura.com> on 2015/04/19 16:57:56 UTC
String enums
Hi,
I want to expose existing server which currently supports enums that their values are strings.
How would you implement it without generating translation map?
T.
RE: String enums
Posted by Jonathan Kanarek <Jo...@kaltura.com>.
Thank you Wilm for the detailed answer.
You are mostly right and I don't think it's the right place to explain myself or my design.
I was trying to enjoy the strength of thrift where it comes to fast and simple clients generation because my REST enums are changing in every installation, but obviously I'll need to find a different solution.
Thank you,
T.
-----Original Message-----
From: Wilm Schumacher [mailto:wilm.schumacher@gmail.com]
Sent: Monday, April 20, 2015 1:02 AM
To: user@thrift.apache.org
Subject: Re: String enums
Hi,
I hope my answer isn't going to be percepted as rude, but your request is kind of strange. "string enums" in the way you described below does not make any sense.
You have two concepts:
1.) enums: (internaly of course some integer) the reason why enums are used is to distiguish between something (states or whatever) which only can take a specific non changable set of values.
1,2,3 ... and done, or with names "aaa", "bbb", "ccc" (as enum names, not strings) ... and done. Not more, not less.
2.) strings:
well, more or less arbitrary arrays of characters. Without further
restriction(!) there is no limit in the set of possible strings.
Thus, enums and strings are in that respect kind of opposite concepts.
In the respect of representing values of a somehow defined set. And:
this is not a thrift question, but a general question on how to represent ... the state, or plugin etc..
In the desription below you wrote something about a "plugin system"
where the clients can trigger the function. And of course only if the plugin is available the function can by pulled.
>From a thrift perspective (or general coding perspective) the question
arises: is the set of values somehow bound to a very specific not/almost not changing set of values which is known beforehand? You answer seems to be "no", thus enums are not working for you. Is there a good representation of your "possible values" by integer? Seems not to be.
Thus string seems to be a good idea.
As you wrote, a older client could speak with a new servers, thus unkown functions are avaiable and new clients could speak with old servers where there are funtions triggered with no "backend". I would go with something like
void triggerFunction( 1:string pluginName , .... ) throws (1:PluginNotKnown, ...)
and
list<string> availablePlugins( ); // for checking
or so.
Hope it helps
Wilm
Am 19.04.2015 um 18:27 schrieb Jonathan Kanarek:
> Assuming this enum(AAA = 'aaa', CCC = 'ccc').
> Today the client send the server the string value=aaa and the server validates it against the optional values.
> I can create a server side map that will create a new enum(AAA = 1, CCC = 2) and when I get value=1 I'll know the client actually means aaa.
>
> However, our server grows rapidly and new enum values may be added in the future, e.g. BBB.
> How can I make sure that all generated client will match all compatible versions of the servers on different environments if the map is generated dynamically based on the existing values.
> Note that the order of the values is also not always the same because on different environments I may install different plugins that may cause different values sets in the enums.
>
> Of course that mapping the enums on the client side will only increase the issue.
>
> So I was wondering if there is a way to implement string enums using constants that instantiated with string value for example.
> T.
>
> -----Original Message-----
> From: Jens Geyer [mailto:jensgeyer@hotmail.com]
> Sent: Sunday, April 19, 2015 7:14 PM
> To: user@thrift.apache.org
> Subject: Re: String enums
>
> Ok, now I'm pretty sure I don't understand the problem.
> Why do you have to change the API when you only want to map enums to strings in the client?
>
>
>
> -----Ursprüngliche Nachricht-----
> From: Jonathan Kanarek
> Sent: Sunday, April 19, 2015 5:46 PM
> To: user@thrift.apache.org
> Subject: RE: String enums
>
> I want to keep the server side as is and implement only client libraries.
> If no one have a better idea, I guess I'll have to implement changes
> on the server side as well.
>
> T.
>
> -----Original Message-----
> From: Jens Geyer [mailto:jensgeyer@hotmail.com]
> Sent: Sunday, April 19, 2015 6:22 PM
> To: user@thrift.apache.org
> Subject: Re: String enums
>
>> How would you implement it without generating translation map?
> That was my first thought, to be honest. What speaks against it? Or
> maybe I just don't understand the problem right.
>
>
> -----Ursprüngliche Nachricht-----
> From: Jonathan Kanarek
> Sent: Sunday, April 19, 2015 4:57 PM
> To: user@thrift.apache.org
> Subject: String enums
>
> Hi,
> I want to expose existing server which currently supports enums that
> their values are strings.
> How would you implement it without generating translation map?
>
> T.
>
Re: String enums
Posted by Wilm Schumacher <wi...@gmail.com>.
Hi,
I hope my answer isn't going to be percepted as rude, but your request
is kind of strange. "string enums" in the way you described below does
not make any sense.
You have two concepts:
1.) enums: (internaly of course some integer)
the reason why enums are used is to distiguish between something (states
or whatever) which only can take a specific non changable set of values.
1,2,3 ... and done, or with names "aaa", "bbb", "ccc" (as enum names,
not strings) ... and done. Not more, not less.
2.) strings:
well, more or less arbitrary arrays of characters. Without further
restriction(!) there is no limit in the set of possible strings.
Thus, enums and strings are in that respect kind of opposite concepts.
In the respect of representing values of a somehow defined set. And:
this is not a thrift question, but a general question on how to
represent ... the state, or plugin etc..
In the desription below you wrote something about a "plugin system"
where the clients can trigger the function. And of course only if the
plugin is available the function can by pulled.
>From a thrift perspective (or general coding perspective) the question
arises: is the set of values somehow bound to a very specific not/almost
not changing set of values which is known beforehand? You answer seems
to be "no", thus enums are not working for you. Is there a good
representation of your "possible values" by integer? Seems not to be.
Thus string seems to be a good idea.
As you wrote, a older client could speak with a new servers, thus unkown
functions are avaiable and new clients could speak with old servers
where there are funtions triggered with no "backend". I would go with
something like
void triggerFunction( 1:string pluginName , .... ) throws
(1:PluginNotKnown, ...)
and
list<string> availablePlugins( ); // for checking
or so.
Hope it helps
Wilm
Am 19.04.2015 um 18:27 schrieb Jonathan Kanarek:
> Assuming this enum(AAA = 'aaa', CCC = 'ccc').
> Today the client send the server the string value=aaa and the server validates it against the optional values.
> I can create a server side map that will create a new enum(AAA = 1, CCC = 2) and when I get value=1 I'll know the client actually means aaa.
>
> However, our server grows rapidly and new enum values may be added in the future, e.g. BBB.
> How can I make sure that all generated client will match all compatible versions of the servers on different environments if the map is generated dynamically based on the existing values.
> Note that the order of the values is also not always the same because on different environments I may install different plugins that may cause different values sets in the enums.
>
> Of course that mapping the enums on the client side will only increase the issue.
>
> So I was wondering if there is a way to implement string enums using constants that instantiated with string value for example.
> T.
>
> -----Original Message-----
> From: Jens Geyer [mailto:jensgeyer@hotmail.com]
> Sent: Sunday, April 19, 2015 7:14 PM
> To: user@thrift.apache.org
> Subject: Re: String enums
>
> Ok, now I'm pretty sure I don't understand the problem.
> Why do you have to change the API when you only want to map enums to strings in the client?
>
>
>
> -----Ursprüngliche Nachricht-----
> From: Jonathan Kanarek
> Sent: Sunday, April 19, 2015 5:46 PM
> To: user@thrift.apache.org
> Subject: RE: String enums
>
> I want to keep the server side as is and implement only client libraries.
> If no one have a better idea, I guess I'll have to implement changes on the
> server side as well.
>
> T.
>
> -----Original Message-----
> From: Jens Geyer [mailto:jensgeyer@hotmail.com]
> Sent: Sunday, April 19, 2015 6:22 PM
> To: user@thrift.apache.org
> Subject: Re: String enums
>
>> How would you implement it without generating translation map?
> That was my first thought, to be honest. What speaks against it? Or maybe I
> just don't understand the problem right.
>
>
> -----Ursprüngliche Nachricht-----
> From: Jonathan Kanarek
> Sent: Sunday, April 19, 2015 4:57 PM
> To: user@thrift.apache.org
> Subject: String enums
>
> Hi,
> I want to expose existing server which currently supports enums that their
> values are strings.
> How would you implement it without generating translation map?
>
> T.
>
RE: String enums
Posted by Jonathan Kanarek <Jo...@kaltura.com>.
Assuming this enum(AAA = 'aaa', CCC = 'ccc').
Today the client send the server the string value=aaa and the server validates it against the optional values.
I can create a server side map that will create a new enum(AAA = 1, CCC = 2) and when I get value=1 I'll know the client actually means aaa.
However, our server grows rapidly and new enum values may be added in the future, e.g. BBB.
How can I make sure that all generated client will match all compatible versions of the servers on different environments if the map is generated dynamically based on the existing values.
Note that the order of the values is also not always the same because on different environments I may install different plugins that may cause different values sets in the enums.
Of course that mapping the enums on the client side will only increase the issue.
So I was wondering if there is a way to implement string enums using constants that instantiated with string value for example.
T.
-----Original Message-----
From: Jens Geyer [mailto:jensgeyer@hotmail.com]
Sent: Sunday, April 19, 2015 7:14 PM
To: user@thrift.apache.org
Subject: Re: String enums
Ok, now I'm pretty sure I don't understand the problem.
Why do you have to change the API when you only want to map enums to strings in the client?
-----Ursprüngliche Nachricht-----
From: Jonathan Kanarek
Sent: Sunday, April 19, 2015 5:46 PM
To: user@thrift.apache.org
Subject: RE: String enums
I want to keep the server side as is and implement only client libraries.
If no one have a better idea, I guess I'll have to implement changes on the
server side as well.
T.
-----Original Message-----
From: Jens Geyer [mailto:jensgeyer@hotmail.com]
Sent: Sunday, April 19, 2015 6:22 PM
To: user@thrift.apache.org
Subject: Re: String enums
> How would you implement it without generating translation map?
That was my first thought, to be honest. What speaks against it? Or maybe I
just don't understand the problem right.
-----Ursprüngliche Nachricht-----
From: Jonathan Kanarek
Sent: Sunday, April 19, 2015 4:57 PM
To: user@thrift.apache.org
Subject: String enums
Hi,
I want to expose existing server which currently supports enums that their
values are strings.
How would you implement it without generating translation map?
T.
Re: String enums
Posted by Jens Geyer <je...@hotmail.com>.
Ok, now I'm pretty sure I don't understand the problem.
Why do you have to change the API when you only want to map enums to strings
in the client?
-----Ursprüngliche Nachricht-----
From: Jonathan Kanarek
Sent: Sunday, April 19, 2015 5:46 PM
To: user@thrift.apache.org
Subject: RE: String enums
I want to keep the server side as is and implement only client libraries.
If no one have a better idea, I guess I'll have to implement changes on the
server side as well.
T.
-----Original Message-----
From: Jens Geyer [mailto:jensgeyer@hotmail.com]
Sent: Sunday, April 19, 2015 6:22 PM
To: user@thrift.apache.org
Subject: Re: String enums
> How would you implement it without generating translation map?
That was my first thought, to be honest. What speaks against it? Or maybe I
just don't understand the problem right.
-----Ursprüngliche Nachricht-----
From: Jonathan Kanarek
Sent: Sunday, April 19, 2015 4:57 PM
To: user@thrift.apache.org
Subject: String enums
Hi,
I want to expose existing server which currently supports enums that their
values are strings.
How would you implement it without generating translation map?
T.
RE: String enums
Posted by Jonathan Kanarek <Jo...@kaltura.com>.
I want to keep the server side as is and implement only client libraries.
If no one have a better idea, I guess I'll have to implement changes on the server side as well.
T.
-----Original Message-----
From: Jens Geyer [mailto:jensgeyer@hotmail.com]
Sent: Sunday, April 19, 2015 6:22 PM
To: user@thrift.apache.org
Subject: Re: String enums
> How would you implement it without generating translation map?
That was my first thought, to be honest. What speaks against it? Or maybe I just don't understand the problem right.
-----Ursprüngliche Nachricht-----
From: Jonathan Kanarek
Sent: Sunday, April 19, 2015 4:57 PM
To: user@thrift.apache.org
Subject: String enums
Hi,
I want to expose existing server which currently supports enums that their
values are strings.
How would you implement it without generating translation map?
T.
Re: String enums
Posted by Jens Geyer <je...@hotmail.com>.
> How would you implement it without generating translation map?
That was my first thought, to be honest. What speaks against it? Or maybe I
just don't understand the problem right.
-----Ursprüngliche Nachricht-----
From: Jonathan Kanarek
Sent: Sunday, April 19, 2015 4:57 PM
To: user@thrift.apache.org
Subject: String enums
Hi,
I want to expose existing server which currently supports enums that their
values are strings.
How would you implement it without generating translation map?
T.