he.org/jira/browse/SPARK-32694 to
>> track this. Welcome to comment on the JIRA.
>>
>> On Wed, Aug 19, 2020 at 7:08 AM Wenchen Fan wrote:
>>
>>> Currently we can't. This is something we should improve, by either
>>> pushing down the cast to the data source, or s
ing a perhaps meaningless comparison between a date
>>> and a non-date string.
>>>
>>> I think we should seriously consider whether in cases like this we
>>> should attempt to cast the literal rather than casting the
>>> source column.
>>>
>>> Please let me know if anyone has thoughts on this, or has some previous
>>> Jiras I could dig into if it's been discussed before,
>>> Russ
>>>
>>
--
Bart Samwel
bart.sam...@databricks.com
would have to choose
where to spend our complexity budget, there are other types that would come
first on my list based on how common the use case is. I'd first go for
DATETIME (logical timestamps) before I'd go for TIME by itself.
>
> Maxim Gekk
>
> Software Engineer
&g
> (2020-07-01, 10:00, Morning TV show)
> (2020-08-02, 19:00, Soccer game)
>
> So, you can join your day schedule with the fact table and find out which
> TV shows you can watch when you are at home.
>
> Maxim Gekk
>
> Software Engineer
>
> Databricks, Inc.
>
>
>
. We could add our
> use-case of compatibility with Parquet's TimeType as a use-case for a new
> Spark TimeType.
>
> Would it be helpful to collect/document these TimeType use-cases to gauge
> interest? We could add a new story or comment in the Spark JIRA or a page
> on the Apache
engine does not support reading
> Parquet files with TimeType columns.
>
> We are wondering if anyone on the mailing list could shed some more light
> on this: are there are architectural/datatype limitations in Spark that are
> resulting in this error, or is TimeType support for Parquet files something
> that hasn't been implemented yet due to lack of resources/interest?
>
>
> Thanks,
> Rylan
>
--
Bart Samwel
bart.sam...@databricks.com
