ExecuteSQLRecord and timestamps

[Boris Tyukin <bo...@boristyukin.com>]

Hi guys,

we just upgraded to 1.9 and I was excited to start using new
ExecuteSQLRecord processor.

While I was migrating an older flow, that uses ExecuteSQL processor I've
noticed that timestamp/date types are coming as integers not strings like
before.

Also AVRO schema inferred from a database is identical for both processors.
e.g.
{"name":"update_dt_tm","type":["null","string"]}]}

but actual values in flowfiles are very different. e.g.

ExecuteSQL:
2014-12-23 11:04:56.664

but ExecuteSQLRecord:
1419350696664 (it is not from the same record but you get an idea).

I now wonder what happens with other data types...

Note, I used AVROWriter with the infered schema. Pretty much all the
properties were left with default values, including logical AVRO data types
(set to no)

Is this a known issue or I need to submit new JIRA?

Thanks.
Boris

Re: ExecuteSQLRecord and timestamps

[Boris Tyukin <bo...@boristyukin.com>]

ok so we are back to using ExecuteSQL processor...really do not like how
new one handles timestamps and there are might be other differences I do
not know about. I was hoping it would produce the same data as older
processor.

On Thu, Mar 7, 2019 at 2:02 PM Boris Tyukin <bo...@boristyukin.com> wrote:

> Hi guys,
>
> we just upgraded to 1.9 and I was excited to start using new
> ExecuteSQLRecord processor.
>
> While I was migrating an older flow, that uses ExecuteSQL processor I've
> noticed that timestamp/date types are coming as integers not strings like
> before.
>
> Also AVRO schema inferred from a database is identical for both
> processors. e.g.
> {"name":"update_dt_tm","type":["null","string"]}]}
>
> but actual values in flowfiles are very different. e.g.
>
> ExecuteSQL:
> 2014-12-23 11:04:56.664
>
> but ExecuteSQLRecord:
> 1419350696664 (it is not from the same record but you get an idea).
>
> I now wonder what happens with other data types...
>
> Note, I used AVROWriter with the infered schema. Pretty much all the
> properties were left with default values, including logical AVRO data types
> (set to no)
>
> Is this a known issue or I need to submit new JIRA?
>
> Thanks.
> Boris
>
>