DBC Mark 1
ScalaDBC Mark 1 is now finished. I have added it to the webapp CVS server. It is tested, but not very thoroughly. Sébastien N. will hopefully start testing it in a real-life application as soon as he comes back from vacation. Please, read the extended entry for some comments about why a Mark 2 version will be needed.
There are two things that ScalaDBC does not as well as what it ought to be doing. I believe both have to do with the expressiveness of Scala, but to be totally honest, I am not quite sure: Scala is complex and there might be a satisfying solution for these problems that I did not find.
- Static type checking is not good enough. When declaring a query, there is implicit type information attached. For example, the query
select fields ("a" of boolean, "b" of varchar) from "table"gives information about what type fields "a" and "b" have ("boolean" and "varchar" are instances of classes that define the native Scala type for this field as type members). However, the query in the above code does not contain the type information in a form exploitable by the compiler. It would need to be given as type parameters, but the number of fields, and therefore of types, is arbitrary, and Scala does not support classes with an arbitrary number of type parameters. Tuple or Function classes try to simulate it by declaring multiple such classes (Tuple1, Tuple2, etc.) but with a relation, the number of fields can be quite large and declaring, say, 100 classes for all different sizes would be very impractical. Martin proposed it might be an idea to support a mechanism to generate on request a relation (or tuple or function) of the right size, but this is not planned and would not be trivial to do. This problem of type safety will also be true for ScalaDALL, so this remains very much an open problem. - Automatic type conversions using views is not broad enough. Bug #449 (or a variant of it) prevents the conversion of all the required values. In particular, it is not possible to view a value of type integer (SQL) as a value of type long (Scala) for example, even though it would be perfectly legal. I hope it will be possible to improve this in NSC with the new view system (based on "implicit"). Another sad thing is that views are only one level deep. Of course, multi-level views would be quite a different problem altogether: Cyclicality for one thing would probably be very difficult to manage, and I am not even sure the problem is solvable. It would also make development very unpredictable, but quite a bit more powerful. In practice, this means that if a field is a value, and a value an int, for example, a field is not an int except if this is made explicit by adding a direct view from one to the other.