CASE ... WHEN branch

[Peter Brant]

Hi Max,

I was just wondering what the status of the CASE ... WHEN branch is.
It's likely we'll need this in the semi-near future. I was planning
on starting it soon and was pleasantly surprised when I saw the
branch.

Thanks,

Pete

[Maxime Lévesque]

Short story : I started this in 2.8.0 and had to use a suboptimal
approach due to a type system bug, so I postponed.

I'll revisit this sooner if you are interested, I can provide you
with some insight, ...first I must gather what I remember ! ;-)

[Peter Brant]

That would be great. Either functions or views in the database itself
are effective workarounds, but we're figuring that will get tiresome
before long.

Pete

2011/4/4 Maxime Lévesque <maxime....@gmail.com>:

[Maxime Lévesque]

Most of the info is here :

 https://github.com/max-l/Squeryl/commit/ce94283fd56bb7f9a322ca46bd9e6486df4cc574#L6L397

Basically what this code tries to do (appart from creation the proper AST which is the easy part)
is to make sure that the return type is correct, for ex.:
in an expression such as :

 caseWhen(<condition1>, <valueExpressionA1>)
 when(<condition2>, <valueExpressionA2>)
 otherwise(<valueExpressionA3>)

If  valueExpressionA1, valueExpressionA2, valueExpressionA3 are respectively
Int, Float and Double, the type of the result needs to be Double,
if it is Int, Float and Option[Float], then the return type will be Option[Float].

Such is the intent of this method :

+  CaseWhenNumericalElement[A](
...
+  def when[B,C](condition: LogicalBoolean, then: NumericalExpression[B])(implicit ev: BinaryAMSOp[A,B] <%< NumericalExpression[C]) = {
+    val bo = new BinaryAMSOp[A,B](this.then, then,"!CaseWhen!") : NumericalExpression[C]
+    new CaseWhenNumericalElement[C](Some(condition), bo, Some(this))
+  } 
 
if there exist an implicit conv. for creating a BinaryAMSOp[A,B] (the intermediate conversion for binary addition multiplication
subtraction, because a chain of case/when behave like a chain of Additions at the type level).

Note that the scheme prohibits mixing numericals with non numericals, which is a conscious decision.

This is the wall that I ran into at the time :

  http://scala-programming-language.1934581.n4.nabble.com/Question-on-lt-lt-can-it-be-done-td2277987.html

ML

[Peter Brant]

Thanks. I do notice that Scala bug #3346 isn't fixed (or isn't marked
as such anyway). :-(

[Peter Brant]

Would UNION (and friends) suffer from the same problem? It just
occurred to me that they seem quite similar.

Pete

[Maxime Lévesque]

Actually, I don't remember having a problem with the UNION, MINUS thing
at the type system level, it's postponement until later was because of a
glitch in mapping the result back, somewhere in the AST... It's been so long,
that it's probably safe to say that the brach is probably good for archeological
purposes...
For the case/when, I had a workaround at the time, ... it was somekind of tradeoff
that made it work, but allowed a few classes of invalid expression to compile.
Now that I see the scala bug unfixed, I'm thinking to go ahead with the workaround,
it can be reverted to a more bullet proof mechanism later.
The only problem is that I need to remember it ;-) I'll be checking this  out tonight.
There is one thing that I haven't explored : could higher kinded types provide a solution ?

ML