Hello,

It turns out that it is not possible to remove the boolean fields while
generating the java file using thrift. So, one option is to manually store
the objects to a different POJO before actually pushing them to the
storehouse.

Best,
Abhinav Jain

On Thu, Oct 19, 2017 at 1:37 AM Jens Geyer <[email protected]> wrote:

>
> https://stackoverflow.com/q/46804847/499466
>
>
> -----Ursprüngliche Nachricht-----
> From: Randy Abernethy
> Sent: Wednesday, October 18, 2017 9:18 PM
> To: [email protected]
> Subject: Re: Extra boolean set fields in java generated file using thrift
>
> Hello,
>
> Maybe you are looking for "required"?
>
> user@ubuntu:~/test$ cat point.thrift
> struct Point {
>   1: required double lat,
>   2: required double lon}
> user@ubuntu:~/test$ thrift -gen java point.thrift
> user@ubuntu:~/test$ cat gen-java/Point.java | grep public | grep -v '{'
>   public double lat; // required
>   public double lon; // required
>   public static final java.util.Map<_Fields,
> org.apache.thrift.meta_data.FieldMetaData> metaDataMap;
>   public Point(
> user@ubuntu:~/test$
>
>
> Required means the field must always be present so make sure the semantics
> fit.
>
> -Randy
>
> On Wed, Oct 18, 2017 at 2:14 AM, Abhinav Jain <[email protected]>
> wrote:
>
> > I have a thrift file point.thrift that has only two variables as follows:
> >
> > struct Point {
> >   1: double lat,
> >   2: double lon}
> >
> > But when I generate the java file using,
> >
> > thrift --gen java point.thrift
> >
> > then the generated java code has other boolean variables, setLat and
> > setLon. So, my Point object looks like below:
> >
> > "point": {
> >   "lat": 12.983451879142935,
> >   "lon": 77.75181960314512,
> >   "setLat": true,
> >   "setLon": true}
> >
> > Is there any way these extra boolean variables can be removed from my
> > point
> > object because it is increasing the size of my object, which in turn will
> > take up a lot of space when I store them. Note that this is the basic
> > definition but the actual definition will have lots of other fields. So,
> > storage is a concern for me.
> >
>
>

Reply via email to