Dynamo NULL type handling about scanamo HOT 5 CLOSED

I think that if you have a custom DynamoFormat for Option in scope, that should be able to override the default behaviour to deal with this case. e.g.

import com.gu.scanamo._
import cats.data.Xor
import com.amazonaws.services.dynamodbv2.model.AttributeValue
import com.gu.scanamo.error.DynamoReadError

implicit def nullOptionFormat[T](implicit f: DynamoFormat[T]) = new DynamoFormat[Option[T]]{
  def read(av: AttributeValue): Xor[DynamoReadError, Option[T]] = {
    Option(av).filter(!_.isNULL).map(f.read(_).map(Some(_)))
       .getOrElse(Xor.right(Option.empty[T]))
  }
  def write(t: Option[T]): AttributeValue = t.map(f.write).getOrElse(new AttributeValue().withNULL(true))
}

then

scala>DynamoFormat[Option[String]].write(Option.empty[String])
res0: com.amazonaws.services.dynamodbv2.model.AttributeValue = {NULL: true,}

Does that deal adequately with your case?

from scanamo.

There's also probably a case for adding that filter on read to the default, but I don't particularly like the idea of things not being symmetric by default.

from scanamo.

@philwills You could add that behavior to the read side (to accommodate other systems that use explicit NULL) but leave write the same. Still not symmetric, but it's a less dramatic change.

from scanamo.

For the record, I had the same problem when upgrading from an ancient version of Scanamo (serves me right for being an early adopter). Pre-0.3, Scanamo used to encode None as an explicit NULL.

Here is the change.

from scanamo.

Closed by #65

from scanamo.