yup, it doesnt really solve the underlying issue. we fixed it internally by having our own typeclass that produces encoders and that does check the contents of the products, but we did this by simply supporting Tuple1 - Tuple22 and Option explicitly, and not supporting Product, since we dont have a need for case classes
if case classes extended ProductN (which they will i think in scala 2.12?) then we could drop Product and support Product1 - Product22 and Option explicitly while checking the classes they contain. that would be the cleanest. On Wed, Oct 26, 2016 at 2:33 PM, Ryan Blue <rb...@netflix.com> wrote: > Isn't the problem that Option is a Product and the class it contains isn't > checked? Adding support for Set fixes the example, but the problem would > happen with any class there isn't an encoder for, right? > > On Wed, Oct 26, 2016 at 11:18 AM, Michael Armbrust <mich...@databricks.com > > wrote: > >> Hmm, that is unfortunate. Maybe the best solution is to add support for >> sets? I don't think that would be super hard. >> >> On Tue, Oct 25, 2016 at 8:52 PM, Koert Kuipers <ko...@tresata.com> wrote: >> >>> i am trying to use encoders as a typeclass where if it fails to find an >>> ExpressionEncoder it falls back to KryoEncoder. >>> >>> the issue seems to be that ExpressionEncoder claims a little more than >>> it can handle here: >>> implicit def newProductEncoder[T <: Product : TypeTag]: Encoder[T] = >>> Encoders.product[T] >>> >>> this "claims" to handle for example Option[Set[Int]], but it really >>> cannot handle Set so it leads to a runtime exception. >>> >>> would it be useful to make this a little more specific? i guess the >>> challenge is going to be case classes which unfortunately dont extend >>> Product1, Product2, etc. >>> >> >> > > > -- > Ryan Blue > Software Engineer > Netflix >
