Do you have the full stack trace from that exception?

On Wed, May 27, 2020 at 1:13 PM Rion Williams <rionmons...@gmail.com> wrote:

> Correct, Kotlin uses an Int type as opposed to Java’s integer, however in
> this case I had assumed that since the PCollection being constructed and
> used by the DoFn both use the same Kotlin Int type that it would be able to
> bind properly (even when explicitly typing the Create to use the Kotlin
> type).
>
> When doing the same thing with Kotlin Strings, the @Element attribute
> works as expected, so I don’t know if this is an issue purely related to
> underlying type conversions with numeric Kotlin types and what’s the best
> way to handle this? I know using the ProcessContext works just as you’d
> expect, however for simple transforms the @Element approach can be a bit
> easier to grok.
>
> On May 27, 2020, at 3:01 PM, Reuven Lax <re...@google.com> wrote:
>
> 
> I'm assuming that Kotlin has its own type for Int, which is not the same
> as Java's Integer type.
>
> On Fri, May 22, 2020 at 8:19 AM Rion Williams <rionmons...@gmail.com>
> wrote:
>
>> Hi all,
>>
>> I was writing a very simple transform in Kotlin as follows that takes in
>> a series of integers and applies a simply DoFn against them:
>>
>> pipeline
>>             .apply(Create.of(1, 2, 3))
>>             .apply(ParDo.of(object: DoFn<Int, Int>(){
>>                     @ProcessElement
>>                     fun processElement(@Element element: Int){
>>                         // Omitted for brevity
>>                     }
>>                 })
>>             )
>>
>> The issue seems to arise when we use the `@Element` attribute on the
>> element which fails with the following error:
>>
>> Exception in thread "main" java.lang.IllegalArgumentException: Type of
>> @Element must match the DoFn typeCreate.Values/Read(CreateSource).out
>> [PCollection]
>>
>> Basically, it seems that the use of the `@Element` attribute isn't able
>> to properly decode or recognize the Kotlin `Int`, however if we adjust the
>> DoFn to instead use the ProcessContext argument, which is able to resolve
>> the element via `context.element()`.
>>
>> Is there anything that seems wrong here? I'd imagine that this should
>> just "work", or maybe there's some specific configuration that I might be
>> missing as this is the first Kotlin issue that I've encountered when
>> interacting with Beam.
>>
>> I'll be happy to provide any additional details for this if needed.
>>
>> Thanks,
>>
>> Rion
>>
>>

Reply via email to