Re: Possibility of supporting TIME or other standard types

[Okumin]

Hi Stamatis,

Thanks for your reply and +1. Anyway, I also guess there is no semantic
reason not to support the type.
I created a ticket and may try to work on it when I have a chance.
https://issues.apache.org/jira/browse/HIVE-27587

Please let me know if anyone else knows any difficulties or historical
reasons why we are not supporting it.

Regards,
Okumin


On Wed, Aug 9, 2023 at 5:50 PM Stamatis Zampetakis 
wrote:

> Hello Okumin,
>
> As you mentioned the TIME datatype is part of the SQL standard and it
> is also supported by many popular DBMS so it definitely makes sense to
> add it to Hive.
> I guess it was not implemented already cause users were able to store
> times using other existing types so it never became a must have.
>
> +1 on adding TIME data type support in Hive.
>
> Best,
> Stamatis
>
> On Fri, Aug 4, 2023 at 12:19 PM Okumin  wrote:
> >
> > Hi everyone,
> >
> > I happened to find some people struggling to store values of the TIME
> type
> > in a Hive table from another query engine. A viable option is to use
> > Iceberg or another format instead of Hive native tables since Hive
> doesn't
> > directly support the type. I agree that it could be one of the right
> > options in this era.
> >
> > On the other hand, I also think it is a valid request to support TIME
> since
> > it is one of the types defined in the SQL standard. I expect it is not a
> > bad offer also for Hive users if they can process Iceberg's TIME as
> Hive's
> > TIME, not STRING or other alternatives. I'd like to hear if we have any
> > reasons not to support it easily.
> >
> > I see there is a related ticket but looks like we have not developed TIME
> > yet.
> > https://issues.apache.org/jira/browse/HIVE-1269
> >
> > Regards,
> > Okumin
>

Update on PowerMock elimination

[Zsolt Miskolczi]

I wanted to put this issue to the community in case you have any additional
thoughts, ideas or doubts about it.

Hi there, I dug deeper into the topic and have found some interesting maven
dependency issues that will lead to some surprising pull requests so I
wanted to update you about this:
The goal is to not to do one huge, big bang change that modifies all the
modules but do it on a module by module basis.

*Short version: *
Based on my current knowledge, we need those steps to make the changes. It
seems I cannot possibly do the upgrade in one single module without
upgrading mockito from 3.4.4 to 4x (preferably 4.11.0) and mockto 4.11.0 is
incompatible with powermock.

*- remove mockito-core dependency from root pom.xml and instead of that,
introduce it in all the modules one-by-one where it is currently used (I'll
explain the reason in details later)*
- upgrade mockito from 3.4.4 to 4.11.0 in a module that we are currently
working on
- remove powermock from the module that we are currently working on
- do it for all modules
- re-introduce mockito in the root pom.xml again

*Explanation: *

So Hive currently uses mockito-core 3.4.4 and PowerMock 2.0.2.
During the review, Zoltan Haindrich  noticed
an issue that leads to the conclusion we need to be able to do constructor
mocking
Constructor mocking is not supported in mockito 3.4.4 but it is supported
in 4.x release line
I tried to upgrade mockito as a preparation step but actually 4.x release
contains a huge cleanup and they removed obsolete methods from mockito. And
of course, PowerMock uses those obsolete methods and of course, they didn't
update powermock.
I tried to upgrade mockito only in the hive-exec module first and found it
still fails as mockito-core picks up the original 3.4.4 version as a
transitive dependency from its parent pom.

So the end conclusion was that I can do the powermock -> mockito change
only in one way if I don't want to do one huge, big bang change that
affects all the modules: remove the dependency from the root pom.xml.


Any feedback is appreciated

Thank you,
Zsolt Miskolczi

Re: Possibility of supporting TIME or other standard types

[Stamatis Zampetakis]

Hello Okumin,

As you mentioned the TIME datatype is part of the SQL standard and it
is also supported by many popular DBMS so it definitely makes sense to
add it to Hive.
I guess it was not implemented already cause users were able to store
times using other existing types so it never became a must have.

+1 on adding TIME data type support in Hive.

Best,
Stamatis

On Fri, Aug 4, 2023 at 12:19 PM Okumin  wrote:
>
> Hi everyone,
>
> I happened to find some people struggling to store values of the TIME type
> in a Hive table from another query engine. A viable option is to use
> Iceberg or another format instead of Hive native tables since Hive doesn't
> directly support the type. I agree that it could be one of the right
> options in this era.
>
> On the other hand, I also think it is a valid request to support TIME since
> it is one of the types defined in the SQL standard. I expect it is not a
> bad offer also for Hive users if they can process Iceberg's TIME as Hive's
> TIME, not STRING or other alternatives. I'd like to hear if we have any
> reasons not to support it easily.
>
> I see there is a related ticket but looks like we have not developed TIME
> yet.
> https://issues.apache.org/jira/browse/HIVE-1269
>
> Regards,
> Okumin