db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Shazin Sadakath <shazin.sadak...@gmail.com>
Subject Re: Regarding Derby Stored Procedures
Date Tue, 08 Sep 2009 17:47:22 GMT
Hi Dag/Rick

Thanks for the very descriptive information on the advantages of Java
Routines. I am a huge fan of derby and I really appreciate the work you guys
have put in to bring derby where it is now.

But I would like to list some cons of Java Routines. Correct me if I am

1. Java Routine is not really stored procedures.
2. A Change in Java Routine code implementation requires recompilation
3. A Change in Java Routine code implementation requires repackaging (Jar)
4. A Change in Java Routine code implementation requires replacing of the
old jar with the new one
using sqlj.replace_jar
5. Requires extensive knowledge of Java. For server database this is a
disadvantage because in the future if you are hoping to support other
languages (PHP, C++, .NET) to access derby server, those developers have to
know Java to create Java Routines.
6. Database servers such as Oracle, Sybase also support Java Routines along
with their own SQL Stored Procedures (SQL/PSM) whereas derby only supports
Java Routines.

I am in no means against derby database. In fact I am a Java Developer
myself and I am currently studying the derby database for academic reasons.


On Tue, Sep 8, 2009 at 6:56 PM, Rick Hillegas <Richard.Hillegas@sun.com>wrote:

> Hi Shazin,
> In addition to what Dag said, I would say this:
> 1) Writing your procedural code in Java (rather than SQL/PSM) makes it
> possible to factor your code so that pieces (like integrity and validation
> logic) can be shared across all tiers of your application. As you tune your
> application, you can move that code up and down the call-stack to the tier
> where you get the best performance. The same code can run in your client, in
> the middle tier, and in the database itself.
> 2) Writing your procedural code in Java (rather than SQL/PSM) gives you
> access to a large ecosystem of development tools, including debuggers. You
> can debug your application in embedded mode--here the same debugger is
> responsible for your procedural code and your client code.
> 3) Writing your procedural code in Java gives your database procedures
> access to all the advantages of the Java language itself, including:
> a) a large ecosystem of off-the shelf freeware
> b) compilers which do half of your debugging for you
> c) powerful exception handling
> The "Java in the Database" presentation (from Apache Con USA 2006) may be
> useful: http://db.apache.org/derby/papers/ApacheCon.html
> Hope this helps,
> -Rick
> Shazin Sadakath wrote:
>> Hi,
>> Recently I have been going through the Wiki
>> http://wiki.apache.org/db-derby/DerbySQLroutines
>> And it states I quote " The advantage of Java procedures is that the same
>> procedure will run on any database that supports the standard, such as
>> Derby, IBM's DB2 and Oracle"
>> Apart from this single advantage there aren't much to registering Java
>> Procedures in derby database, so why doesn't derby database support standard
>> SQL Stored Procedures (Such as Oracle PL/SQL..) without registering public
>> static void methods as Stored Procedure. Any particular reason to this?
>> Thanks in advance,
>> Shazin

View raw message