title: Spark Scala : Check if string isn't null or empty
body: <p>First, due to the three value logic, this isn't just the negation of any valid implementation of a null-or-empty check. </p>
  
  <p>I want to make a function <code>isNotNullish</code> , which is as close as possible to isNotNull but also filters out empty strings. I'm running into some oddities involving how column/column types work, as well as three value logic. So far the best I have is:</p>
  
  <pre><code>def isNotNullish(questionable: Column) : Column = {
    val oddish = questionable === lit("")
    questionable.isNotNull &amp;&amp; (!oddish || oddish.isNull)
  }
  </code></pre>
  
  <p>If that looks strange it's because it is. As far as I can tell, <code>questionable === lit("")</code> will return <code>null</code> for a given row if that row holds either null or (some!) non-string types. In three value logic, <code>true &amp;&amp; null = null</code>, which would cause <code>questionable.isNotNull &amp;&amp; (questionable =!= lit("")</code> to return <code>null</code> in some cases where I'd want it to return <code>true</code>. The <code>questionable.isNotNull &amp;&amp; (!oddish || oddish.isNull)</code> code should never yield null, always true or false. </p>
  
  <p>This almost-not-quite works: for some reason I don't understand, the === comparison is happy to return null for numeric types, but fails for complex types. (Even if what I'm trying to do is impossible or inadvisable, I'd love an explanation for that.)</p>
  
  <p>It might be more responsible to check the schema and simply do a different test for string types than for others, but as far as I can tell that requires the dataframe to be passed as a parameter. I'm trying to avoid that, especially for long sequences of transformations where said parameter might be anonymous.</p>
  
  <p>(Before anyone asks, I know that dealing with null and types in this sloppy a way would be horrible in general scala, but I think it's different in the context of Spark/SQL/huge dataframes of varying schema. The specific case is automatic exploration of sketchy data, so being able to answer questions like "I don't know what the columns are, but tell me how often they hold actual values" is useful.)</p>