db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rick Hillegas <Richard.Hille...@Sun.COM>
Subject Re: SQL functions, procedures and PSM - a possible approach
Date Fri, 07 Oct 2005 16:34:59 GMT
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.
>
>  
>


Mime
View raw message