Re: Public API access to UDTs

2021-02-03 Thread Sean Owen
I opened https://github.com/apache/spark/pull/31461 to track the discussion further. It narrowly proposes making a few types public. On Mon, Feb 1, 2021 at 8:52 AM Fitch, Simeon wrote: > 🙇 > > On Mon, Feb 1, 2021 at 9:38 AM Sean Owen wrote: > >> I'm not hearing any objection to making it public

Re: Public API access to UDTs

2021-02-01 Thread Fitch, Simeon
🙇 On Mon, Feb 1, 2021 at 9:38 AM Sean Owen wrote: > I'm not hearing any objection to making it public as a @DeveloperApi ? > anyone object to a PR on that? > > On Fri, Jan 29, 2021 at 8:46 AM Sean Owen wrote: > >> I'm also interested: are there problems with opening up this API beyond >> needin

Re: Public API access to UDTs

2021-02-01 Thread Sean Owen
I'm not hearing any objection to making it public as a @DeveloperApi ? anyone object to a PR on that? On Fri, Jan 29, 2021 at 8:46 AM Sean Owen wrote: > I'm also interested: are there problems with opening up this API beyond > needing to freeze it and keep it stable? it's pretty stable. > As @De

Re: Public API access to UDTs

2021-01-29 Thread Fitch, Simeon
On Fri, Jan 29, 2021 at 9:46 AM Sean Owen wrote: > Are there implications for storing UDTs in particular engines or formats? > I've found UDTs I/O to Parquet without problem. They work fine with PySpark with implementation of mirror classes. Without properly constructed mirror classe they show

Re: Public API access to UDTs

2021-01-29 Thread Sean Owen
I'm also interested: are there problems with opening up this API beyond needing to freeze it and keep it stable? it's pretty stable. As @DeveloperApi at least? Are there implications for storing UDTs in particular engines or formats? Just making it public for developers, even with a 'use at your ow