[
https://issues.apache.org/jira/browse/THRIFT-5253?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jens Geyer updated THRIFT-5253:
-------------------------------
Description:
Example:
{code}
struct GetStringResult{
1: string thisIsAString
}
service MyService{
GetStringResult GetString(1:GetStringParameters getStringParams)
}
{code}
This produces two different classes with same Name; one in GetStringResult.cs
is the "correct" class and one in the service class.
When implementing an IAsync handler class something like this is generated:
{code}
public Task<MyService.GetStringResult> GetStringAsync(GetStringParameters
getStringParams, CancellationToken cancellationToken =
default(CancellationToken))
{
}
{code}
So in this case this is the wrong GetStringResult class.
A workaround is to move the result struct into a different thrift file with
different namespace
was:
Example:
struct GetStringResult{
1: string thisIsAString
}
service MyService{
GetStringResult GetString(1:GetStringParameters getStringParams)
}
This produces two different classes with same Name; one in GetStringResult.cs
is the "correct" class and one in the service class.
When implementing an IAsync handler class something like this is generated:
public Task<MyService.GetStringResult> GetStringAsync(GetStringParameters
getStringParams, CancellationToken cancellationToken =
default(CancellationToken))
{
}
So in this case this is the wrong GetStringResult class.
A workaround is to move the result struct into a different thrift file with
different namespace
> using Result in result name generates wrong IAsync interface
> ------------------------------------------------------------
>
> Key: THRIFT-5253
> URL: https://issues.apache.org/jira/browse/THRIFT-5253
> Project: Thrift
> Issue Type: Bug
> Components: netstd - Compiler
> Affects Versions: 0.13.0
> Reporter: Matthias Jüttner
> Priority: Major
>
> Example:
>
> {code}
> struct GetStringResult{
> 1: string thisIsAString
> }
> service MyService{
> GetStringResult GetString(1:GetStringParameters getStringParams)
> }
> {code}
>
> This produces two different classes with same Name; one in GetStringResult.cs
> is the "correct" class and one in the service class.
> When implementing an IAsync handler class something like this is generated:
> {code}
> public Task<MyService.GetStringResult> GetStringAsync(GetStringParameters
> getStringParams, CancellationToken cancellationToken =
> default(CancellationToken))
> {
> }
> {code}
> So in this case this is the wrong GetStringResult class.
> A workaround is to move the result struct into a different thrift file with
> different namespace
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
