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.
Comments
I am really curious about the dbc library, I think I should check it out from cvs :-) Is you "select" statement compilable code with your library?
Aside from that, I think some limited form of multi-hop views can be achieved with the current scalac, using view-bounded type parameters. I had once an example, now I cite from my (unreliable) memory:
def view[a <% Value](x: a): SomeThing = new SomeThing {...}
def view(x: Int): Value = new Value {...}
Now, an Int will be seeable as an instance of SometThing.
On the other hand, I think a general multi-hop view mechanism cannot be efficiently implemented. If we take types to be nodes of some graph, and edges to be views between the types, finding whether a type is viewable as another requires to find a path between source and destination (complexity n^2, if memory serves me right). In case of unresolved method calls, all possible paths starting at the type of the receiver have to be checked whether they contain that method name. I think it's about the same complexity, but my graph theory is a bit rusty :-D I also think it would become difficult to predict, as a developer, what will the compiler do behind the scenes. Anyway, it's certainly a topic to be further discussed.
PS. How can one format text inside comments? HTML tags don't seem to work.
Posted by: Iulian | August 8, 2005 09:54 PM