Hey everyone,
I'm not sure if we already had a discussion about it but as we are currently adding new types like the Either type, I would like to discuss it again. I think especially for business or scientific applications it makes sense to support the BigInteger and BigDecimal types natively. In my opinion they are as important as Date or Void and should be added as BasicTypes. I need them for the SQL prototype (FLINK-2099) but I think people working with the Table API or Java/Scala API would also benefit from it. What do you think? Regards, Timo |
I agree that they are important.
They are currently generic types and handled by Kryo, which has (AFAIK) proper serializers for them. Are there more benefits of native support (other than more compact serialization) that you are thinking of? On Wed, Nov 18, 2015 at 5:55 PM, Timo Walther <[hidden email]> wrote: > Hey everyone, > > I'm not sure if we already had a discussion about it but as we are > currently adding new types like the Either type, I would like to discuss it > again. I think especially for business or scientific applications it makes > sense to support the BigInteger and BigDecimal types natively. In my > opinion they are as important as Date or Void and should be added as > BasicTypes. I need them for the SQL prototype (FLINK-2099) but I think > people working with the Table API or Java/Scala API would also benefit from > it. > > What do you think? > > Regards, > Timo > |
I could image that some applications also want to group or join by a
BigInteger or sort by BigDecimal. All DBMS support this types by default. I'm not from the industry but there is a need for that I think. On 18.11.2015 18:21, Stephan Ewen wrote: > I agree that they are important. > > They are currently generic types and handled by Kryo, which has (AFAIK) > proper serializers for them. Are there more benefits of native support > (other than more compact serialization) that you are thinking of? > > On Wed, Nov 18, 2015 at 5:55 PM, Timo Walther <[hidden email]> wrote: > >> Hey everyone, >> >> I'm not sure if we already had a discussion about it but as we are >> currently adding new types like the Either type, I would like to discuss it >> again. I think especially for business or scientific applications it makes >> sense to support the BigInteger and BigDecimal types natively. In my >> opinion they are as important as Date or Void and should be added as >> BasicTypes. I need them for the SQL prototype (FLINK-2099) but I think >> people working with the Table API or Java/Scala API would also benefit from >> it. >> >> What do you think? >> >> Regards, >> Timo >> |
Ah, support as an efficient key types is a fair argument, yes!
On Thu, Nov 19, 2015 at 2:30 PM, Timo Walther <[hidden email]> wrote: > I could image that some applications also want to group or join by a > BigInteger or sort by BigDecimal. All DBMS support this types by default. > I'm not from the industry but there is a need for that I think. > > > On 18.11.2015 18:21, Stephan Ewen wrote: > >> I agree that they are important. >> >> They are currently generic types and handled by Kryo, which has (AFAIK) >> proper serializers for them. Are there more benefits of native support >> (other than more compact serialization) that you are thinking of? >> >> On Wed, Nov 18, 2015 at 5:55 PM, Timo Walther <[hidden email]> wrote: >> >> Hey everyone, >>> >>> I'm not sure if we already had a discussion about it but as we are >>> currently adding new types like the Either type, I would like to discuss >>> it >>> again. I think especially for business or scientific applications it >>> makes >>> sense to support the BigInteger and BigDecimal types natively. In my >>> opinion they are as important as Date or Void and should be added as >>> BasicTypes. I need them for the SQL prototype (FLINK-2099) but I think >>> people working with the Table API or Java/Scala API would also benefit >>> from >>> it. >>> >>> What do you think? >>> >>> Regards, >>> Timo >>> >>> > |
Free forum by Nabble | Edit this page |