You are viewing a plain text version of this content. The canonical link for it is here.
Posted to derby-dev@db.apache.org by "Dag H. Wanvik (JIRA)" <ji...@apache.org> on 2009/12/09 19:40:18 UTC

[jira] Commented: (DERBY-4467) Non Java Stored Routines Using Java Scripting API

    [ https://issues.apache.org/jira/browse/DERBY-4467?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12788220#action_12788220 ] 

Dag H. Wanvik commented on DERBY-4467:
--------------------------------------

Interesting! 
Would you handle any args & results via a string (to be parsed using some convention)? 
We should also consider the security implication of permanently enabling CREATE_PROCEDURE and EXECUTE_PROCEDURE; it would allow a client to register and run arbitrary code on the server modulo any Java security policy in effect on the server.

> Non Java Stored Routines Using Java Scripting API
> -------------------------------------------------
>
>                 Key: DERBY-4467
>                 URL: https://issues.apache.org/jira/browse/DERBY-4467
>             Project: Derby
>          Issue Type: Improvement
>          Components: Network Server
>         Environment: Windows XP, Java 1.6
>            Reporter: Shazin Sadakath
>            Priority: Minor
>         Attachments: DDL.sql, DerbyStoredRoutine.zip, ScreenShot.JPG
>
>
> I have been working on an idea that lets you create Stored Procedures using languages other than Java with a perspective of Apache Derby as a Network Server. I tried this by using Sun Java Scripting API for JRE 1.6+ and Apache BSF http://jakarta.apache.org/bsf/ for JRE 1.4+.
> This has certain advantages when it comes to compiled java stored routines.
> 1. It is dynamic.
> 2. Requires no configuration of classpath.
> 3. Requires no use of SQLJ.INSTALL_JAR and SQLJ.REPLACE_JAR.
> 4. Very easy to maintain
> 5. Allows the use of Sun Java Runtime Library via Object Binding.
> 6. Supports JavaScript, Jython, Dynamic Java and many more scripting languages. https://scripting.dev.java.net/
> 7. No need of introducing a new SQL/PSM grammar to the current SQLParser.
> There are two approaches for this enhancement. 
> 1. Having this as an external utility component such as ij, dblooks
> 2. Having this as a built in feature.
> I have done this in the former method for demonstration purpose.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.