Convert empty string to None for an Option[String] field

[Dmitry Vorobiov]

Hi,

I would like to build the following functionality:

1) if I have a varchar / text / field in db, and its value is empty string, and its mapped Scala type is Option[String], then convert it to None

2) if I have Some[String] value with empty value  I would like to save is and null to db.

 

Is it possible to change the behaviour of scala_type <-> jdbc_type conversions to have described functionality?

thanks!

[Renato Cavalcanti]

You should really avoid such a thing. You should never have a Some(null). You are just breaking your Option monad.

If you have a null is must be a None, not a Some(null). 

This is probably happening because you are initializing your Option with a null value like in:

val s : Option[String] = Some( someMethodReturningNull() )

You should instead have:

val s : Option[String] = Option( someMethodReturningNull() )

As such, if your method returns a null you'll have a None and you don't have to change anything in slick to make it work.

And, most important, you are not breaking your Option monad.

Cheers,

[Renato Cavalcanti]

Ok, now that a re-read your post I see what you are trying to do. 

You want to represent the total absence with a null, the empty string with a None and a non-empty String with a Some[String].

The type you are looking for is Option[Option[String]]. 

or

case object EmptyString

Option[Either[EmptyString, String]] // if you want to make it more explicit

In any case, you should try to avoid having a Some with a null inside and use types to express your different cases. 

null is an ambiguous way of expressing whatsoever.

[Dmitry Vorobiov]

I want to represent both total absense and empty string with a None, and a non-empty value with Some[String]

Now with empty string I have Some("") value.

[Stefan Zeiger]

It should be possible to extend MappedColumnType and override some methods there to get the desired behavior? But since you're replacing a core type, it might be tricky to use it at just the right places and use the built-in type everywhere else. As long as you only have one implementation for a type, you can just use an implicit. If you add another implementation, you should probably remove the implicit that is imported by default, and pass the types explicitly.

--
Stefan Zeiger
Slick Tech Lead
Typesafe - Build Reactive Apps!
Twitter: @StefanZeiger

[Anthony Homan]

If you are mapping to case classes, then you could change the representation as part of that mapping process.  In other words, in your custom table mapping, the tuple returned by Slick would still be Some(""), but you could convert that to None as part of your case class mapping (instead of just using the standard .tupled method).

[Dmitry Vorobiov]

Thanks, that solution is OK for me!