[jira] [Created] (THRIFT-4255) Go generator has type errors when in read/write functions for set
Davin Chia created THRIFT-4255: -- Summary: Go generator has type errors when in read/write functions for set Key: THRIFT-4255 URL: https://issues.apache.org/jira/browse/THRIFT-4255 Project: Thrift Issue Type: Bug Components: Go - Compiler Affects Versions: 0.10.0 Reporter: Davin Chia Given the following thrift definition: {code:java} struct CustomSet { 1: required set values; }{code} The following go code is generated: {code:java} type CustomSet struct { Values map[string]struct{} `thrift:"values,1,required" db:"values" json:"values"` } func (p *ByteArraySet) ReadField1(iprot thrift.TProtocol) error { _, size, err := iprot.ReadSetBegin() if err != nil { return thrift.PrependError("error reading set begin: ", err) } tSet := make(map[string]struct{}, size) p.Values = tSet for i := 0; i < size; i ++ { var _elem2 []byte if v, err := iprot.ReadBinary(); err != nil { return thrift.PrependError("error reading field 0: ", err) } else { _elem2 = v } p.Values[_elem2] = struct{}{} } if err := iprot.ReadSetEnd(); err != nil { return thrift.PrependError("error reading set end: ", err) } return nil } func (p *ByteArraySet) writeField1(oprot thrift.TProtocol) (err error) { if err := oprot.WriteFieldBegin("values", thrift.SET, 1); err != nil { return thrift.PrependError(fmt.Sprintf("%T write field begin error 1:values: ", p), err) } if err := oprot.WriteSetBegin(thrift.STRING, len(p.Values)); err != nil { return thrift.PrependError("error writing set begin: ", err) } for v, _ := range p.Values { if err := oprot.WriteBinary(v); err != nil { return thrift.PrependError(fmt.Sprintf("%T. (0) field write error: ", p), err) } } if err := oprot.WriteSetEnd(); err != nil { return thrift.PrependError("error writing set end: ", err) } if err := oprot.WriteFieldEnd(); err != nil { return thrift.PrependError(fmt.Sprintf("%T write field end error 1:values: ", p), err) } return err } {code} In the *Read* function, *elem_2* needs to be cast to *string* before its used as a key to *Values*. In the *Write* function, *v* needs to be case to *byte[]* before its passed to *WriteBinary*. I have opened a couple of issues today and will slowly work through them as time frees up. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Comment Edited] (THRIFT-4253) Go generator assigns strings to field in const instead of pointers.
[ https://issues.apache.org/jira/browse/THRIFT-4253?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16090895#comment-16090895 ] Davin Chia edited comment on THRIFT-4253 at 7/18/17 3:44 AM: - Thanks for the quick reply [~jensg]. This is the first time I am contributing to a large C++ open source project, or writing much C++ to be honest, and it will be good to get some guidance on development workflow. I'm assuming I clone https://github.com/apache/thrift, make a branch and start working. Happy to jump on some other communication medium if that is better for you. If you can spare a few minutes, it will also be nice to have a point in the code I can start from. Thanks. was (Author: davinc): Thanks for the quick reply [~jensg]. This is the first time I am contributing to a large C++ open source project, or writing much C++ to be honest, and it will be good to get some guidance on development workflow. I'm assuming I clone https://github.com/apache/thrift, make a branch and start working. Happy to jump on some other communication medium if that is better for you. If you spare a few minutes, it will also be nice to have a point in the code I can start from. Thanks. > Go generator assigns strings to field in const instead of pointers. > --- > > Key: THRIFT-4253 > URL: https://issues.apache.org/jira/browse/THRIFT-4253 > Project: Thrift > Issue Type: Bug > Components: Go - Compiler >Affects Versions: 0.10.0 > Environment: Generated using docker-thrift. >Reporter: Davin Chia > > Given the follow thrift definition: > {code:java} > struct custom { > 1: required string field_a; > 2: optional string field_b; > } > {code} > with the following constant map defined in the same file: > {code:java} > const mapcustom_map = { > ..., > 42 : { 'field_a':'www.testa.com', 'field_b':'www.testb.com'}, > ..., > } > {code} > Thrift generates the following go struct in the main {code:java}x.go{code} > file: > {code:java} > type Custom struct { > FieldA string `thrift:"field_a,required" db:"field_a" json:"field_a"` > FieldB *string `thrift:"field_b,2" db:"field_b" json:"field_b,omitempty"` > } > {code} > with the corresponding assignments in the {code:java} X-consts.go {code} file: > {code:java} > CUSTOM_MAP = map[int]*Custom { > ..., > 42: {FieldA: "www.testa.com", FieldB: "www.testb.com"}, > ..., > } > {code} > I assume field_b's pointer type is to allow for null values as per the > optional. The generator should be assigning pointers instead of strings. > I'm not sure how much effort it would take to fix this. I am encountering > this problem at work right and would be very happy to starting working on > this with some guidance from experts around here. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Comment Edited] (THRIFT-4253) Go generator assigns strings to field in const instead of pointers.
[ https://issues.apache.org/jira/browse/THRIFT-4253?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16090895#comment-16090895 ] Davin Chia edited comment on THRIFT-4253 at 7/18/17 3:15 AM: - Thanks for the quick reply [~jensg]. This is the first time I am contributing to a large C++ open source project, or writing much C++ to be honest, and it will be good to get some guidance on development workflow. I'm assuming I clone https://github.com/apache/thrift, make a branch and start working. Happy to jump on some other communication medium if that is better for you. If you spare a few minutes, it will also be nice to have a point in the code I can start from. Thanks. was (Author: davinc): Thanks for the quick reply [~jensg]. This is the first time I am contributing to a large C++ open source project, or writing much C++ to be honest, and it will be good to get some guidance on development workflow. I'm assuming I clone https://github.com/apache/thrift, make a branch and start working. If you spare a few minutes, it will also be nice to have a point in the code I can start from. Thanks. > Go generator assigns strings to field in const instead of pointers. > --- > > Key: THRIFT-4253 > URL: https://issues.apache.org/jira/browse/THRIFT-4253 > Project: Thrift > Issue Type: Bug > Components: Go - Compiler >Affects Versions: 0.10.0 > Environment: Generated using docker-thrift. >Reporter: Davin Chia > > Given the follow thrift definition: > {code:java} > struct custom { > 1: required string field_a; > 2: optional string field_b; > } > {code} > with the following constant map defined in the same file: > {code:java} > const mapcustom_map = { > ..., > 42 : { 'field_a':'www.testa.com', 'field_b':'www.testb.com'}, > ..., > } > {code} > Thrift generates the following go struct in the main {code:java}x.go{code} > file: > {code:java} > type Custom struct { > FieldA string `thrift:"field_a,required" db:"field_a" json:"field_a"` > FieldB *string `thrift:"field_b,2" db:"field_b" json:"field_b,omitempty"` > } > {code} > with the corresponding assignments in the {code:java} X-consts.go {code} file: > {code:java} > CUSTOM_MAP = map[int]*Custom { > ..., > 42: {FieldA: "www.testa.com", FieldB: "www.testb.com"}, > ..., > } > {code} > I assume field_b's pointer type is to allow for null values as per the > optional. The generator should be assigning pointers instead of strings. > I'm not sure how much effort it would take to fix this. I am encountering > this problem at work right and would be very happy to starting working on > this with some guidance from experts around here. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Comment Edited] (THRIFT-4253) Go generator assigns strings to field in const instead of pointers.
[ https://issues.apache.org/jira/browse/THRIFT-4253?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16090895#comment-16090895 ] Davin Chia edited comment on THRIFT-4253 at 7/18/17 3:13 AM: - Thanks for the quick reply [~jensg]. This is the first time I am contributing to a large C++ open source project, or writing much C++ to be honest, and it will be good to get some guidance on development workflow. I'm assuming I clone https://github.com/apache/thrift, make a branch and start working. If you spare a few minutes, it will also be nice to have a point in the code I can start from. Thanks. was (Author: davinc): Thanks for the quick reply [~jensg]. This is the first time I am contributing to a large C++ open source project, or writing much C++ to be honest, and it will be good to get some guidance on development workflow. Immediate questions are (Again sorry if they sound newbie, because I am): Where can I check the code out? What is the typical build for C++ projects? I also have a question about testing, but I now know where to do that (ConstantsDemo.thrift). If you spare a few minutes, it will also be nice to have a point in the code I can start from. Thanks. > Go generator assigns strings to field in const instead of pointers. > --- > > Key: THRIFT-4253 > URL: https://issues.apache.org/jira/browse/THRIFT-4253 > Project: Thrift > Issue Type: Bug > Components: Go - Compiler >Affects Versions: 0.10.0 > Environment: Generated using docker-thrift. >Reporter: Davin Chia > > Given the follow thrift definition: > {code:java} > struct custom { > 1: required string field_a; > 2: optional string field_b; > } > {code} > with the following constant map defined in the same file: > {code:java} > const mapcustom_map = { > ..., > 42 : { 'field_a':'www.testa.com', 'field_b':'www.testb.com'}, > ..., > } > {code} > Thrift generates the following go struct in the main {code:java}x.go{code} > file: > {code:java} > type Custom struct { > FieldA string `thrift:"field_a,required" db:"field_a" json:"field_a"` > FieldB *string `thrift:"field_b,2" db:"field_b" json:"field_b,omitempty"` > } > {code} > with the corresponding assignments in the {code:java} X-consts.go {code} file: > {code:java} > CUSTOM_MAP = map[int]*Custom { > ..., > 42: {FieldA: "www.testa.com", FieldB: "www.testb.com"}, > ..., > } > {code} > I assume field_b's pointer type is to allow for null values as per the > optional. The generator should be assigning pointers instead of strings. > I'm not sure how much effort it would take to fix this. I am encountering > this problem at work right and would be very happy to starting working on > this with some guidance from experts around here. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (THRIFT-4254) Go generator does not respect typedef types when generating read/write functions.
Davin Chia created THRIFT-4254: -- Summary: Go generator does not respect typedef types when generating read/write functions. Key: THRIFT-4254 URL: https://issues.apache.org/jira/browse/THRIFT-4254 Project: Thrift Issue Type: Bug Components: Go - Compiler Affects Versions: 0.10.0 Reporter: Davin Chia Give the following thrift definitions: {code:java} typedef i64 RequestId struct Custom { optional set field_a; } {code} The following go code is generated: {code:java} type RequestId int64 type Custom struct { FieldA map[RequestId]struct{} } ... func (p *Custom) ReadField1(iprot thrift.TProtocol) error { _, size, err := iprot.ReadSetBegin() if err != nil { return thrift.PrependError("error reading set begin: ", err) } tSet := make(map[int64]struct{}, size) p.ActiveImportIds = tSet for i := 0; i < size; i ++ { var _elem1 int64 if v, err := iprot.ReadI64(); err != nil { return thrift.PrependError("error reading field 0: ", err) } else { _elem1 = v } p.FieldA[_elem1] = struct{}{} } if err := iprot.ReadSetEnd(); err != nil { return thrift.PrependError("error reading set end: ", err) } return nil } {code} There are two errors here: 1. {code:java}tSet{code} should be {code:java} map[RequestId]struct{} {code} and not {code:java}map[int64]struct{}{code}. 2. {code:java} elem_1 {code}should be of type {code:java}RequestId{code} and the values need to be case to {code:java}RequestId{code} before assigning to {code:java}elem_1{code}. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (THRIFT-4253) Go generator assigns strings to field in const instead of pointers.
[ https://issues.apache.org/jira/browse/THRIFT-4253?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16090895#comment-16090895 ] Davin Chia commented on THRIFT-4253: Thanks for the quick reply [~jensg]. This is the first time I am contributing to a large C++ open source project, or writing much C++ to be honest, and it will be good to get some guidance on development workflow. Immediate questions are (Again sorry if they sound newbie, because I am): Where can I check the code out? What is the typical build for C++ projects? I also have a question about testing, but I now know where to do that (ConstantsDemo.thrift). If you spare a few minutes, it will also be nice to have a point in the code I can start from. Thanks. > Go generator assigns strings to field in const instead of pointers. > --- > > Key: THRIFT-4253 > URL: https://issues.apache.org/jira/browse/THRIFT-4253 > Project: Thrift > Issue Type: Bug > Components: Go - Compiler >Affects Versions: 0.10.0 > Environment: Generated using docker-thrift. >Reporter: Davin Chia > > Given the follow thrift definition: > {code:java} > struct custom { > 1: required string field_a; > 2: optional string field_b; > } > {code} > with the following constant map defined in the same file: > {code:java} > const mapcustom_map = { > ..., > 42 : { 'field_a':'www.testa.com', 'field_b':'www.testb.com'}, > ..., > } > {code} > Thrift generates the following go struct in the main {code:java}x.go{code} > file: > {code:java} > type Custom struct { > FieldA string `thrift:"field_a,required" db:"field_a" json:"field_a"` > FieldB *string `thrift:"field_b,2" db:"field_b" json:"field_b,omitempty"` > } > {code} > with the corresponding assignments in the {code:java} X-consts.go {code} file: > {code:java} > CUSTOM_MAP = map[int]*Custom { > ..., > 42: {FieldA: "www.testa.com", FieldB: "www.testb.com"}, > ..., > } > {code} > I assume field_b's pointer type is to allow for null values as per the > optional. The generator should be assigning pointers instead of strings. > I'm not sure how much effort it would take to fix this. I am encountering > this problem at work right and would be very happy to starting working on > this with some guidance from experts around here. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (THRIFT-2063) Go compiler cannot create code for maps with complex/binary keys
[ https://issues.apache.org/jira/browse/THRIFT-2063?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16090880#comment-16090880 ] Davin Chia commented on THRIFT-2063: Ah sorry for the noise. I am definitely going to fix this. My intention on opening discussion was to arrive at a community accepted solution. This is because I am not a Go expert and so am not sure about the best solution. The current monkey patch I am using is to convert all complex keys into strings, which is definitely only temporary. I will get to this after tackling *https://issues.apache.org/jira/browse/THRIFT-4253*. > Go compiler cannot create code for maps with complex/binary keys > > > Key: THRIFT-2063 > URL: https://issues.apache.org/jira/browse/THRIFT-2063 > Project: Thrift > Issue Type: Bug > Components: Go - Compiler >Reporter: Remo Hertig > > trying to generate code for ThriftTest leads to: > {code} > ../../compiler/cpp/thrift --gen go ../ThriftTest.thrift > [WARNING:/tbHD/Home/nairboon/dev/thrift/test/ThriftTest.thrift:41] No > generator named 'noexist' could be found! > [WARNING:/tbHD/Home/nairboon/dev/thrift/test/ThriftTest.thrift:42] cpp > generator does not accept 'noexist' as sub-namespace! > Error: Cannot produce a valid type for a Go map key: map[int32]bool - > aborting.{code} > the affected struct seems to be #3: > {code} > struct CrazyNesting { > 1: string string_field, > 2: optional set set_field, > 3: required list< map> > list_field, > 4: binary binary_field > } > {code} -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Comment Edited] (THRIFT-4253) Go generator assigns strings to field in const instead of pointers.
[ https://issues.apache.org/jira/browse/THRIFT-4253?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16090591#comment-16090591 ] Jens Geyer edited comment on THRIFT-4253 at 7/17/17 9:25 PM: - Confirmed, trying this ends up in a "{{cannot use "test" (type string) as type *string in field value}}". That seems absolutely wrong, and besides fixing it we also should integrate an test into [ConstantsDemo.thrift|https://git-wip-us.apache.org/repos/asf?p=thrift.git;a=blob;f=test/ConstantsDemo.thrift;hb=HEAD] [~DavinC], what specific questions that I can answer do you have? was (Author: jensg): Confirmed, trying this ends up in a "{{cannot use "test" (type string) as type *string in field value}}". That seems absolutely wrong, and besides fixing it we also should integrate an test into [ConstantsDemo.thrift|https://git-wip-us.apache.org/repos/asf?p=thrift.git;a=blob;f=test/ConstantsDemo.thrift;hb=HEAD] > Go generator assigns strings to field in const instead of pointers. > --- > > Key: THRIFT-4253 > URL: https://issues.apache.org/jira/browse/THRIFT-4253 > Project: Thrift > Issue Type: Bug > Components: Go - Compiler >Affects Versions: 0.10.0 > Environment: Generated using docker-thrift. >Reporter: Davin Chia > > Given the follow thrift definition: > {code:java} > struct custom { > 1: required string field_a; > 2: optional string field_b; > } > {code} > with the following constant map defined in the same file: > {code:java} > const mapcustom_map = { > ..., > 42 : { 'field_a':'www.testa.com', 'field_b':'www.testb.com'}, > ..., > } > {code} > Thrift generates the following go struct in the main {code:java}x.go{code} > file: > {code:java} > type Custom struct { > FieldA string `thrift:"field_a,required" db:"field_a" json:"field_a"` > FieldB *string `thrift:"field_b,2" db:"field_b" json:"field_b,omitempty"` > } > {code} > with the corresponding assignments in the {code:java} X-consts.go {code} file: > {code:java} > CUSTOM_MAP = map[int]*Custom { > ..., > 42: {FieldA: "www.testa.com", FieldB: "www.testb.com"}, > ..., > } > {code} > I assume field_b's pointer type is to allow for null values as per the > optional. The generator should be assigning pointers instead of strings. > I'm not sure how much effort it would take to fix this. I am encountering > this problem at work right and would be very happy to starting working on > this with some guidance from experts around here. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (THRIFT-4253) Go generator assigns strings to field in const instead of pointers.
[ https://issues.apache.org/jira/browse/THRIFT-4253?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16090591#comment-16090591 ] Jens Geyer commented on THRIFT-4253: Confirmed, trying this ends up in a "{{cannot use "test" (type string) as type *string in field value}}". That seems absolutely wrong, and besides fixing it we also should integrate an test into [ConstantsDemo.thrift|https://git-wip-us.apache.org/repos/asf?p=thrift.git;a=blob;f=test/ConstantsDemo.thrift;hb=HEAD] > Go generator assigns strings to field in const instead of pointers. > --- > > Key: THRIFT-4253 > URL: https://issues.apache.org/jira/browse/THRIFT-4253 > Project: Thrift > Issue Type: Bug > Components: Go - Compiler >Affects Versions: 0.10.0 > Environment: Generated using docker-thrift. >Reporter: Davin Chia > > Given the follow thrift definition: > {code:java} > struct custom { > 1: required string field_a; > 2: optional string field_b; > } > {code} > with the following constant map defined in the same file: > {code:java} > const mapcustom_map = { > ..., > 42 : { 'field_a':'www.testa.com', 'field_b':'www.testb.com'}, > ..., > } > {code} > Thrift generates the following go struct in the main {code:java}x.go{code} > file: > {code:java} > type Custom struct { > FieldA string `thrift:"field_a,required" db:"field_a" json:"field_a"` > FieldB *string `thrift:"field_b,2" db:"field_b" json:"field_b,omitempty"` > } > {code} > with the corresponding assignments in the {code:java} X-consts.go {code} file: > {code:java} > CUSTOM_MAP = map[int]*Custom { > ..., > 42: {FieldA: "www.testa.com", FieldB: "www.testb.com"}, > ..., > } > {code} > I assume field_b's pointer type is to allow for null values as per the > optional. The generator should be assigning pointers instead of strings. > I'm not sure how much effort it would take to fix this. I am encountering > this problem at work right and would be very happy to starting working on > this with some guidance from experts around here. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (THRIFT-2063) Go compiler cannot create code for maps with complex/binary keys
[ https://issues.apache.org/jira/browse/THRIFT-2063?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16090566#comment-16090566 ] Jens Geyer commented on THRIFT-2063: You can bump this in 5-Minutes intervals, but that will only fill the mailing list and disappoint people. This is Open Source, which by definition lives by *contributions, not decibels*. > Go compiler cannot create code for maps with complex/binary keys > > > Key: THRIFT-2063 > URL: https://issues.apache.org/jira/browse/THRIFT-2063 > Project: Thrift > Issue Type: Bug > Components: Go - Compiler >Reporter: Remo Hertig > > trying to generate code for ThriftTest leads to: > {code} > ../../compiler/cpp/thrift --gen go ../ThriftTest.thrift > [WARNING:/tbHD/Home/nairboon/dev/thrift/test/ThriftTest.thrift:41] No > generator named 'noexist' could be found! > [WARNING:/tbHD/Home/nairboon/dev/thrift/test/ThriftTest.thrift:42] cpp > generator does not accept 'noexist' as sub-namespace! > Error: Cannot produce a valid type for a Go map key: map[int32]bool - > aborting.{code} > the affected struct seems to be #3: > {code} > struct CrazyNesting { > 1: string string_field, > 2: optional set set_field, > 3: required list< map> > list_field, > 4: binary binary_field > } > {code} -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Comment Edited] (THRIFT-2063) Go compiler cannot create code for maps with complex/binary keys
[ https://issues.apache.org/jira/browse/THRIFT-2063?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16087783#comment-16087783 ] Davin Chia edited comment on THRIFT-2063 at 7/17/17 8:57 PM: - Bumping this. I know this is an old issue, but I am currently running into this problem while introducing go into our code base. I am compiling using thrift 0.10.0. Is there an update on this? Has there been a consensus to write thrift definitions without complex keys to avoid this problem and are there current work arounds? Or Is this still an open issue with solutions open to discussion? [~apesternikov] [~jensg] [~traviscline] was (Author: davinc): Bumping this. I know this is an old issue, but I am currently running into this problem while introducing go into our code base. I am compiling using thrift 0.10.0. Is there an update on this? Has there been a consensus to write thrift definitions without complex keys to avoid this problem and are there current work arounds? Or Is this still an open issue with solutions open to discussion? [~apesternikov] > Go compiler cannot create code for maps with complex/binary keys > > > Key: THRIFT-2063 > URL: https://issues.apache.org/jira/browse/THRIFT-2063 > Project: Thrift > Issue Type: Bug > Components: Go - Compiler >Reporter: Remo Hertig > > trying to generate code for ThriftTest leads to: > {code} > ../../compiler/cpp/thrift --gen go ../ThriftTest.thrift > [WARNING:/tbHD/Home/nairboon/dev/thrift/test/ThriftTest.thrift:41] No > generator named 'noexist' could be found! > [WARNING:/tbHD/Home/nairboon/dev/thrift/test/ThriftTest.thrift:42] cpp > generator does not accept 'noexist' as sub-namespace! > Error: Cannot produce a valid type for a Go map key: map[int32]bool - > aborting.{code} > the affected struct seems to be #3: > {code} > struct CrazyNesting { > 1: string string_field, > 2: optional set set_field, > 3: required list< map> > list_field, > 4: binary binary_field > } > {code} -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (THRIFT-4253) Go generator assigns strings to field in const instead of pointers.
Davin Chia created THRIFT-4253: -- Summary: Go generator assigns strings to field in const instead of pointers. Key: THRIFT-4253 URL: https://issues.apache.org/jira/browse/THRIFT-4253 Project: Thrift Issue Type: Bug Components: Go - Compiler Affects Versions: 0.10.0 Environment: Generated using docker-thrift. Reporter: Davin Chia Given the follow thrift definition: {code:java} struct custom { 1: required string field_a; 2: optional string field_b; } {code} with the following constant map defined in the same file: {code:java} const mapcustom_map = { ..., 42 : { 'field_a':'www.testa.com', 'field_b':'www.testb.com'}, ..., } {code} Thrift generates the following go struct in the main {code:java}x.go{code} file: {code:java} type Custom struct { FieldA string `thrift:"field_a,required" db:"field_a" json:"field_a"` FieldB *string `thrift:"field_b,2" db:"field_b" json:"field_b,omitempty"` } {code} with the corresponding assignments in the {code:java} X-consts.go {code} file: {code:java} CUSTOM_MAP = map[int]*Custom { ..., 42: {FieldA: "www.testa.com", FieldB: "www.testb.com"}, ..., } {code} I assume field_b's pointer type is to allow for null values as per the optional. The generator should be assigning pointers instead of strings. I'm not sure how much effort it would take to fix this. I am encountering this problem at work right and would be very happy to starting working on this with some guidance from experts around here. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Comment Edited] (THRIFT-2063) Go compiler cannot create code for maps with complex/binary keys
[ https://issues.apache.org/jira/browse/THRIFT-2063?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16087783#comment-16087783 ] Davin Chia edited comment on THRIFT-2063 at 7/17/17 8:00 PM: - Bumping this. I know this is an old issue, but I am currently running into this problem while introducing go into our code base. I am compiling using thrift 0.10.0. Is there an update on this? Has there been a consensus to write thrift definitions without complex keys to avoid this problem and are there current work arounds? Or Is this still an open issue with solutions open to discussion? [~apesternikov] was (Author: davinc): Bumping this. I know this is an old issue, but I am currently running into this problem while introducing go into our code base. I am compiling using thrift 0.10.0. Is there an update on this? Has there been a consensus to write thrift definitions without complex keys to avoid this problem and are there current work arounds? Or Is this still an open issue with solutions open to discussion? > Go compiler cannot create code for maps with complex/binary keys > > > Key: THRIFT-2063 > URL: https://issues.apache.org/jira/browse/THRIFT-2063 > Project: Thrift > Issue Type: Bug > Components: Go - Compiler >Reporter: Remo Hertig > > trying to generate code for ThriftTest leads to: > {code} > ../../compiler/cpp/thrift --gen go ../ThriftTest.thrift > [WARNING:/tbHD/Home/nairboon/dev/thrift/test/ThriftTest.thrift:41] No > generator named 'noexist' could be found! > [WARNING:/tbHD/Home/nairboon/dev/thrift/test/ThriftTest.thrift:42] cpp > generator does not accept 'noexist' as sub-namespace! > Error: Cannot produce a valid type for a Go map key: map[int32]bool - > aborting.{code} > the affected struct seems to be #3: > {code} > struct CrazyNesting { > 1: string string_field, > 2: optional set set_field, > 3: required list< map> > list_field, > 4: binary binary_field > } > {code} -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[GitHub] thrift pull request #1309: Use build tags to support context.
Github user dcelasun commented on a diff in the pull request: https://github.com/apache/thrift/pull/1309#discussion_r127776518 --- Diff: lib/go/thrift/multiplexed_processor.go --- @@ -1,3 +1,5 @@ +// +build go1.7 --- End diff -- Maybe this file should be named `multiplexed_protocol_go17.go` or something like that to be consistent with `TMultiplexedProcessor` in `multiplexed_protocol.go`? --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[GitHub] thrift pull request #1309: Use build tags to support context.
Github user dcelasun commented on a diff in the pull request: https://github.com/apache/thrift/pull/1309#discussion_r127775849 --- Diff: lib/go/thrift/simple_server2.go --- @@ -1,180 +0,0 @@ -/* - * Licensed to the Apache Software Foundation (ASF) under one - * or more contributor license agreements. See the NOTICE file - * distributed with this work for additional information - * regarding copyright ownership. The ASF licenses this file - * to you under the Apache License, Version 2.0 (the - * "License"); you may not use this file except in compliance - * with the License. You may obtain a copy of the License at - * - * http://www.apache.org/licenses/LICENSE-2.0 - * - * Unless required by applicable law or agreed to in writing, - * software distributed under the License is distributed on an - * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY - * KIND, either express or implied. See the License for the - * specific language governing permissions and limitations - * under the License. - */ - -package thrift - -import ( - "context" - "log" - "runtime/debug" - "sync" -) - -/* - * This is only a simple sample same as TSimpleServer but add context - * usage support. - */ -type TSimpleServer2 struct { --- End diff -- Why was this removed? --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[GitHub] thrift pull request #1309: Use build tags to support context.
Github user dcelasun commented on a diff in the pull request: https://github.com/apache/thrift/pull/1309#discussion_r127774140 --- Diff: compiler/cpp/src/thrift/generate/t_go_generator.cc --- @@ -3746,4 +3746,4 @@ THRIFT_REGISTER_GENERATOR(go, "Go", "read_write_private\n" " Make read/write methods private, default is public Read/Write\n" \ "use_context\n" - " Make service method receive a context as first argument.\n") + " Make service method receive a context as first argument, only go1.7+ is supported.\n") --- End diff -- Can we support `x/net/context` for go<1.7? --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[jira] [Commented] (THRIFT-4236) Support context in go generated code.
[ https://issues.apache.org/jira/browse/THRIFT-4236?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16090063#comment-16090063 ] ASF GitHub Bot commented on THRIFT-4236: GitHub user taozle opened a pull request: https://github.com/apache/thrift/pull/1309 Use build tags to support context. As the comment in https://issues.apache.org/jira/browse/THRIFT-4236, this PR use build tags to support context in go1.7 above. You can merge this pull request into a Git repository by running: $ git pull https://github.com/taozle/thrift context Alternatively you can review and apply these changes as the patch at: https://github.com/apache/thrift/pull/1309.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #1309 commit 0df5965eb2a35793f19de1b2696e3c4afb6b5132 Author: taozleDate: 2017-07-17T16:40:42Z Use build tags to support context. > Support context in go generated code. > - > > Key: THRIFT-4236 > URL: https://issues.apache.org/jira/browse/THRIFT-4236 > Project: Thrift > Issue Type: Improvement > Components: Go - Compiler, Go - Library >Reporter: taozle >Assignee: taozle > Fix For: 0.11.0 > > > Since context is widely used in go's community, and there is lots of > advantage to use context such as control timeout, carry extra info in one > request etc, so is there any plan for this? i just searched the issues but > didn't find anything about this. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[GitHub] thrift pull request #1309: Use build tags to support context.
GitHub user taozle opened a pull request: https://github.com/apache/thrift/pull/1309 Use build tags to support context. As the comment in https://issues.apache.org/jira/browse/THRIFT-4236, this PR use build tags to support context in go1.7 above. You can merge this pull request into a Git repository by running: $ git pull https://github.com/taozle/thrift context Alternatively you can review and apply these changes as the patch at: https://github.com/apache/thrift/pull/1309.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #1309 commit 0df5965eb2a35793f19de1b2696e3c4afb6b5132 Author: taozleDate: 2017-07-17T16:40:42Z Use build tags to support context. --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[jira] [Resolved] (THRIFT-4239) Latest thrift breaks java build with handleRuntimeExceptions
[ https://issues.apache.org/jira/browse/THRIFT-4239?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mario Emmenlauer resolved THRIFT-4239. -- Resolution: Fixed > Latest thrift breaks java build with handleRuntimeExceptions > > > Key: THRIFT-4239 > URL: https://issues.apache.org/jira/browse/THRIFT-4239 > Project: Thrift > Issue Type: Bug > Components: Java - Compiler >Affects Versions: 0.11.0 > Environment: Ubuntu 16.04 LTS with Oracle Java 1.8 JDK >Reporter: Mario Emmenlauer > > With the latest trunk I can no longer build my Java thrift example. I get an > error that handleRuntimeExceptions does not Override. It seems related to > these new additions in the generated Java code: > {code} > - @Override > - protected boolean handleRuntimeExceptions() { > -return false; > - } > {code} > With thrift 0.10.0 the method handleRuntimeExceptions (and the error) are not > present. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Closed] (THRIFT-4239) Latest thrift breaks java build with handleRuntimeExceptions
[ https://issues.apache.org/jira/browse/THRIFT-4239?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mario Emmenlauer closed THRIFT-4239. Fixed, thanks. > Latest thrift breaks java build with handleRuntimeExceptions > > > Key: THRIFT-4239 > URL: https://issues.apache.org/jira/browse/THRIFT-4239 > Project: Thrift > Issue Type: Bug > Components: Java - Compiler >Affects Versions: 0.11.0 > Environment: Ubuntu 16.04 LTS with Oracle Java 1.8 JDK >Reporter: Mario Emmenlauer > > With the latest trunk I can no longer build my Java thrift example. I get an > error that handleRuntimeExceptions does not Override. It seems related to > these new additions in the generated Java code: > {code} > - @Override > - protected boolean handleRuntimeExceptions() { > -return false; > - } > {code} > With thrift 0.10.0 the method handleRuntimeExceptions (and the error) are not > present. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (THRIFT-4239) Latest thrift breaks java build with handleRuntimeExceptions
[ https://issues.apache.org/jira/browse/THRIFT-4239?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16089776#comment-16089776 ] Mario Emmenlauer commented on THRIFT-4239: -- Dear [~ctubbsii], thanks a lot!!! You are right, this is the issue! Dammit, that was not too easy to find for me, thanks a lot for your help. > Latest thrift breaks java build with handleRuntimeExceptions > > > Key: THRIFT-4239 > URL: https://issues.apache.org/jira/browse/THRIFT-4239 > Project: Thrift > Issue Type: Bug > Components: Java - Compiler >Affects Versions: 0.11.0 > Environment: Ubuntu 16.04 LTS with Oracle Java 1.8 JDK >Reporter: Mario Emmenlauer > > With the latest trunk I can no longer build my Java thrift example. I get an > error that handleRuntimeExceptions does not Override. It seems related to > these new additions in the generated Java code: > {code} > - @Override > - protected boolean handleRuntimeExceptions() { > -return false; > - } > {code} > With thrift 0.10.0 the method handleRuntimeExceptions (and the error) are not > present. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (THRIFT-4252) Cannot shutdown Java server when clients are still connected
[ https://issues.apache.org/jira/browse/THRIFT-4252?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mario Emmenlauer updated THRIFT-4252: - Description: I found issue https://issues.apache.org/jira/browse/THRIFT-2441 and I believe that the same problem still exists in the Java servers, and I'm affected by it. Short summary: I can not shut down the Java server (neither TSimpleServer nor TThreadedServer) while clients are still connected. That is pretty bad, because essentially the clients are not under by control, but they can essentially "block" server maintenance operations by blocking the shutdown. *In more detail:* I have a Java TSimpleServer runnable in a thread running. The main thread eventually asks the server to stop(). But they seem to ignore the request. I checked the code of TSimpleServer.java and I'm under the impression that the innermost loop the server does not poll the variable stopped_ or does it? Looking at https://github.com/apache/thrift/blob/master/lib/java/src/org/apache/thrift/server/TSimpleServer.java from line 76: {code} while (true) { if (eventHandler_ != null) { eventHandler_.processContext(connectionContext, inputTransport, outputTransport); } if(!processor.process(inputProtocol, outputProtocol)) { break; } } {code} I found that this loop is only interrupted if the client disconnects. I tried changing {{while(true)}} for {{while(!stopped_)}} but that did not help. I guess that one of the methods in the loop must be blocking. was: I found issue https://issues.apache.org/jira/browse/THRIFT-2441 and I believe that the same problem still exists in the Java servers, and I'm affected by it. Short summary: I can not shut down the Java server (neither TSimpleServer nor TThreadedServer) while clients are still connected. That is pretty bad, because essentially the clients are not under by control, but they can essentially "block" server maintenance operations by blocking the shutdown. In more detail: I have a Java TSimpleServer runnable in a thread running. The main thread eventually asks the server to stop(). But they seem to ignore the request. I checked the code of TSimpleServer.java and I'm under the impression that the innermost loop the server does not poll the variable stopped_ or does it? Looking at https://github.com/apache/thrift/blob/master/lib/java/src/org/apache/thrift/server/TSimpleServer.java from line 76: {code} while (true) { if (eventHandler_ != null) { eventHandler_.processContext(connectionContext, inputTransport, outputTransport); } if(!processor.process(inputProtocol, outputProtocol)) { break; } } {code} I found that this loop is only interrupted if the client disconnects. I tried changing `while(true)` for `while(!stopped_)` but that did not help. I guess that one of the methods in the loop must be blocking. > Cannot shutdown Java server when clients are still connected > > > Key: THRIFT-4252 > URL: https://issues.apache.org/jira/browse/THRIFT-4252 > Project: Thrift > Issue Type: Bug > Components: Java - Library >Affects Versions: 0.10.0 >Reporter: Mario Emmenlauer > > I found issue https://issues.apache.org/jira/browse/THRIFT-2441 and I believe > that the same problem still exists in the Java servers, and I'm affected by > it. Short summary: I can not shut down the Java server (neither TSimpleServer > nor TThreadedServer) while clients are still connected. That is pretty bad, > because essentially the clients are not under by control, but they can > essentially "block" server maintenance operations by blocking the shutdown. > *In more detail:* I have a Java TSimpleServer runnable in a thread running. > The main thread eventually asks the server to stop(). But they seem to ignore > the request. I checked the code of TSimpleServer.java and I'm under the > impression that the innermost loop the server does not poll the variable > stopped_ or does it? Looking at > https://github.com/apache/thrift/blob/master/lib/java/src/org/apache/thrift/server/TSimpleServer.java > from line 76: > {code} > while (true) { > if (eventHandler_ != null) { > eventHandler_.processContext(connectionContext, inputTransport, > outputTransport); > } > if(!processor.process(inputProtocol, outputProtocol)) { > break; > } > } > {code} > I found that this loop is only interrupted if the client disconnects. I tried > changing {{while(true)}} for {{while(!stopped_)}} but that did not help. I > guess that one of the methods in the loop must be blocking. --
[jira] [Created] (THRIFT-4252) Cannot shutdown Java server when clients are still connected
Mario Emmenlauer created THRIFT-4252: Summary: Cannot shutdown Java server when clients are still connected Key: THRIFT-4252 URL: https://issues.apache.org/jira/browse/THRIFT-4252 Project: Thrift Issue Type: Bug Components: Java - Library Affects Versions: 0.10.0 Reporter: Mario Emmenlauer I found issue https://issues.apache.org/jira/browse/THRIFT-2441 and I believe that the same problem still exists in the Java servers, and I'm affected by it. Short summary: I can not shut down the Java server (neither TSimpleServer nor TThreadedServer) while clients are still connected. That is pretty bad, because essentially the clients are not under by control, but they can essentially "block" server maintenance operations by blocking the shutdown. In more detail: I have a Java TSimpleServer runnable in a thread running. The main thread eventually asks the server to stop(). But they seem to ignore the request. I checked the code of TSimpleServer.java and I'm under the impression that the innermost loop the server does not poll the variable stopped_ or does it? Looking at https://github.com/apache/thrift/blob/master/lib/java/src/org/apache/thrift/server/TSimpleServer.java from line 76: {code} while (true) { if (eventHandler_ != null) { eventHandler_.processContext(connectionContext, inputTransport, outputTransport); } if(!processor.process(inputProtocol, outputProtocol)) { break; } } {code} I found that this loop is only interrupted if the client disconnects. I tried changing `while(true)` for `while(!stopped_)` but that did not help. I guess that one of the methods in the loop must be blocking. -- This message was sent by Atlassian JIRA (v6.4.14#64029)