Debugging SQL/PSM code can be painful and I suspect that building a
robust SQL/PSM debugger would be expensive. One of the great beauties of
writing dbprocs in Java is that you can debug them client-side before
deploying them on the server. Deploying a java dbproc is an awkward,
but, to my way of thinking, not a prohibitively onerous task. Your
mileage may vary. :)
The case of the java-ignorant developer who wants to write Derby dprocs
is an interesting problem. I don't know how important this group of
developers is. In any case, I would not want to encourage these people
to believe that SQL/PSM is a portable language.
Regards,
-Rick
Daniel John Debrunner wrote:
Rick Hillegas wrote:
Hi Dan,
This is pretty cool. I have to say, though, I would need some heavy
motivation before embarking on implementing SQL/PSM. IMHO, Java is more
expressive, more powerful, and better designed than SQL/PSM. Java is
better defined and less ambiguous. Moreover, I suspect that Java code is
more portable than vendor-specific dialects of SQL/PSM. In short, I
think Java is a superior dbproc language.
I agree, Java is a powerful language that does allow integration of all
manner of things with Derby, such as Java mail, James, lucene, Jython,
Groovey etc. I think however your perspective is that of a Java
developer (and as a Java developer myself I agree with you).
From the point of view of a SQL developer though, it's not the same. In
order to write a simple function I have to:
1) write Java code
2) compile the class
3) put into a jar file
4) install it into Derby
5) create the function
Or if I did the same in SQL, I would have to
1) create the function.
Similar issues exist for multiple statements in a trigger, again Derby
forces them to write Java code. I know folks are interested in using
Derby who know nothing about Java and don't want to know anything about
Java. They just want a quality data server.
I think there is a place for both Java and SQL functions etc., the
developer can pick the right tool for the right job.
Dan.
