You are viewing a plain text version of this content. The canonical link for it is here.
Posted to derby-user@db.apache.org by Pavel Bortnovskiy <pb...@jefferies.com> on 2012/12/27 22:34:27 UTC

number of parameters

Hello:

we have a need to create a java-mapped function which will take 92 parameters, but we are running into Derby's limitation:

Caused by: java.sql.SQLException: The limit for the number of parameters for a procedure has been exceeded. Limit is 90 and number of parameters for procedure CALC_VALUES are 92.

http://db.apache.org/derby/docs/10.8/ref/rrefdbmlimits.html

Can this limit either be increased or worked-around?

Thanks,
Pavel.

Jefferies archives and monitors outgoing and incoming e-mail. The contents of this email, including any attachments, are confidential to the ordinary user of the email address to which it was addressed. If you are not the addressee of this email you may not copy, forward, disclose or otherwise use it or any part of it in any form whatsoever. This email may be produced at the request of regulators or in connection with civil litigation. Jefferies accepts no liability for any errors or omissions arising as a result of transmission. Use by other than intended recipients is prohibited. In the United Kingdom, Jefferies operates as Jefferies International Limited; registered in England: no. 1978621; registered office: Vintners Place, 68 Upper Thames Street, London EC4V 3BJ. Jefferies International Limited is authorised and regulated by the Financial Services Authority.

RE: number of parameters

Posted by Pavel Bortnovskiy <pb...@jefferies.com>.
Thank you, Rick.

-----Original Message-----
From: Rick Hillegas [mailto:rick.hillegas@oracle.com]
Sent: Thursday, January 03, 2013 11:14 AM
To: derby-user@db.apache.org
Subject: Re: number of parameters

On 12/27/12 1:34 PM, Pavel Bortnovskiy wrote:
>
> Hello:
>
> we have a need to create a java-mapped function which will take 92
> parameters, but we are running into Derby's limitation:
>
> Caused by: java.sql.SQLException: The limit for the number of
> parameters for a procedure has been exceeded. Limit is 90 and number
> of parameters for procedure CALC_VALUES are 92.
>
> http://db.apache.org/derby/docs/10.8/ref/rrefdbmlimits.html
>
> Can this limit either be increased or worked-around?
>
> Thanks,
>
> Pavel.
>
>
>
>             Jefferies archives and monitors outgoing and incoming
>             e-mail. The contents of this email, including any
>             attachments, are confidential to the ordinary user of the
>             email address to which it was addressed. If you are not
>             the addressee of this email you may not copy, forward,
>             disclose or otherwise use it or any part of it in any form
>             whatsoever. This email may be produced at the request of
>             regulators or in connection with civil litigation.
>             Jefferies accepts no liability for any errors or omissions
>             arising as a result of transmission. Use by other than
>             intended recipients is prohibited. In the United Kingdom,
>             Jefferies operates as Jefferies International Limited;
>             registered in England: no. 1978621; registered office:
>             Vintners Place, 68 Upper Thames Street, London EC4V 3BJ.
>             Jefferies International Limited is authorised and
>             regulated by the Financial Services Authority.
>
I agree with Knut that the limit is arbitrary and that it ought to be safe to remove this restriction. I have logged
https://issues.apache.org/jira/browse/DERBY-6033 to track this issue.
This is probably a trivial change.

Thanks,
-Rick

Jefferies archives and monitors outgoing and incoming e-mail. The contents of this email, including any attachments, are confidential to the ordinary user of the email address to which it was addressed. If you are not the addressee of this email you may not copy, forward, disclose or otherwise use it or any part of it in any form whatsoever. This email may be produced at the request of regulators or in connection with civil litigation. Jefferies accepts no liability for any errors or omissions arising as a result of transmission. Use by other than intended recipients is prohibited. In the United Kingdom, Jefferies operates as Jefferies International Limited; registered in England: no. 1978621; registered office: Vintners Place, 68 Upper Thames Street, London EC4V 3BJ. Jefferies International Limited is authorised and regulated by the Financial Services Authority.

Re: number of parameters

Posted by Rick Hillegas <ri...@oracle.com>.
On 12/27/12 1:34 PM, Pavel Bortnovskiy wrote:
>
> Hello:
>
> we have a need to create a java-mapped function which will take 92 
> parameters, but we are running into Derby’s limitation:
>
> Caused by: java.sql.SQLException: The limit for the number of 
> parameters for a procedure has been exceeded. Limit is 90 and number 
> of parameters for procedure CALC_VALUES are 92.
>
> http://db.apache.org/derby/docs/10.8/ref/rrefdbmlimits.html
>
> Can this limit either be increased or worked-around?
>
> Thanks,
>
> Pavel.
>
>
>
>             Jefferies archives and monitors outgoing and incoming
>             e-mail. The contents of this email, including any
>             attachments, are confidential to the ordinary user of the
>             email address to which it was addressed. If you are not
>             the addressee of this email you may not copy, forward,
>             disclose or otherwise use it or any part of it in any form
>             whatsoever. This email may be produced at the request of
>             regulators or in connection with civil litigation.
>             Jefferies accepts no liability for any errors or omissions
>             arising as a result of transmission. Use by other than
>             intended recipients is prohibited. In the United Kingdom,
>             Jefferies operates as Jefferies International Limited;
>             registered in England: no. 1978621; registered office:
>             Vintners Place, 68 Upper Thames Street, London EC4V 3BJ.
>             Jefferies International Limited is authorised and
>             regulated by the Financial Services Authority.
>
I agree with Knut that the limit is arbitrary and that it ought to be 
safe to remove this restriction. I have logged 
https://issues.apache.org/jira/browse/DERBY-6033 to track this issue. 
This is probably a trivial change.

Thanks,
-Rick

Re: number of parameters

Posted by Knut Anders Hatlen <kn...@oracle.com>.
Pavel Bortnovskiy <pb...@jefferies.com> writes:

> we have a need to create a java-mapped function which will take 92
> parameters, but we are running into Derby’s limitation:
>
> Caused by: java.sql.SQLException: The limit for the number of
> parameters for a procedure has been exceeded. Limit is 90 and number
> of parameters for procedure CALC_VALUES are 92.
>
> http://db.apache.org/derby/docs/10.8/ref/rrefdbmlimits.html
>
> Can this limit either be increased or worked-around?

Comments in the code suggest that the limit was put in place for
compatibility with DB2. I don't think there is anything in the
architecture that limits the number of parameters to 90, so lifting the
limit might be as simple as changing a constant in Derby and write some
tests to verify that it works.

> [...]
>
> So, we mapped a Java function and then we need to do something like this:
>
> select a,b,c,
>   case
>     when JAVA_FUNCTION(d,e,f) = 0 then COLUMN00
>     when JAVA_FUNCTION(d,e,f) = 1 then COLUMN01
>     when JAVA_FUNCTION(d,e,f) = 2 then COLUMN02
>                 ...
>     when JAVA_FUNCTION(d,e,f) = 88 then COLUMN89
>     else COLUMN89
>  end as col_value
> ...
>
> But such select causes JAVA_FUNCTION to be invoked 90 times.

It would be nice if Derby's SQL compiler could recognize that
JAVA_FUNCTION is called with the same arguments every time and only call
it once. (If it is declared with the DETERMINISTIC keyword, that is.)

Might be possible to work around it with a nested query, though:

  select a,b,c
    case
      when colNum = 0 then COLUMN00
      when colNum = 1 then COLUMN01
      when colNum = 2 then COLUMN02
                  ...
      when colNum = 89 then COLUMN89
      else COLUMN89
    end as col_value
  from (select t.*, JAVA_FUNCTION(d,e,f) from t ... ) as s

> [...]
>
> So, I was able to properly define and create the UDT and the function, but have trouble invoking it.
> What I’m attempting to do is:
>
> select a,b,c,
>   JAVA_FUNCTION(d,e,f,USER_DEFINED_TYPE(COLUMN00, ... , COLUMN89)) as col_value
>   ...
>
> But doing so causes the following error:
>
> java.sql.SQLSyntaxErrorException: 'USER_DEFINED_TYPE' is not recognized as a function or procedure.

A user defined type cannot be called as a function. To create instances
of the UDT using SQL, you'd have to create another function that returns
objects of that type. Something like this:

    public static MyUDT create(int col00, ... , int col89) {
        return new MyUDT(col00, ... , col89);
    }

    create function create_object(col00 int, ... , col89 int)
           returns my_udt
           language java parameter style java external name ...

And call that new function in the query:

    select a,b,c,
      JAVA_FUNCTION(d,e,f,CREATE_OBJECT(COLUMN00, ... , COLUMN89)) as col_value
      ...

You may also be interested in DERBY-3069 (support for vararg functions)
planned for Derby 10.10, which may provide another way to work around
the limitation.

Hope this helps,

-- 
Knut Anders

RE: number of parameters

Posted by kosurusekhar <ko...@gmail.com>.
Hi Pavel,

I understand that you need to pass 92 parameters for you store proc.

Recently i implemented with 86 parameters with help of UDT.

I registered an UDT in derby like this.

Create type MyType
External Name 'yourpackage.MyUDTClassName' Language java
-- This is Java class you need to create with those 92 parameters as local
properties.
your UDT external java class should be implement either Serializable or
Externalizer. 
And also you need to provide serialversionUID if you implement Serializable.

Mainly this UDT java class should be derby classpath before you testing jdbc
client.

Then write the Store proc like this.

create procedure MySP(IN myt MyType)
parameter style java
language java
external name 'yourpackage.yourClass.spMethod'

As part of your store proc we need to write one public static method where
we mentioned in above store proc should be like this.

public static void spMethod(MyUDTClassName myudt) throws SQLException {
   // implement your sp logic here. all 92 parameters is now available with
the method parameter.
}

As per Derby semantics the method which we will write logic for store proc
also should be derby classpath.

To test this store procedure you need to write a JDBC client which as
follows:

// Create connection.
MyUDTClassName myu = new MyUDTClassName(); // Object for my UDT class and
set all 92 parameters.
CallableStatement cs = connection.prepareCall("{call MySP(?)}");
cs.setObject(1, myu);
cs.execute();

My self i tested above things in Network Server Mode. 

Hope this will help you.


Regards
Sekhar.







--
View this message in context: http://apache-database.10148.n7.nabble.com/number-of-parameters-tp126108p126209.html
Sent from the Apache Derby Users mailing list archive at Nabble.com.

RE: number of parameters

Posted by Pavel Bortnovskiy <pb...@jefferies.com>.
Thank you, Sekhar, et al.

I've done so: created a proper User Defined Java class (implementing Externalizable), created the type in Derby, mapped the function, but it still doesn't seem to work.

Here is what I'm trying to achieve (names such as JAVA_FUNCTION and USER_DEFINED_TYPE are symbolic):

We have a fairly large SQL with an insanely large case statement.
One of the tables used in the SQL has many columns, 90 of which encode some specific data, such as timeseries (for simplicity, let's call them Column00 - Column89).

So, we mapped a Java function and then we need to do something like this:

select a,b,c,
  case
    when JAVA_FUNCTION(d,e,f) = 0 then COLUMN00
    when JAVA_FUNCTION(d,e,f) = 1 then COLUMN01
    when JAVA_FUNCTION(d,e,f) = 2 then COLUMN02
                ...
    when JAVA_FUNCTION(d,e,f) = 88 then COLUMN89
    else COLUMN89
 end as col_value
...


But such select causes JAVA_FUNCTION to be invoked 90 times.
So, we tried to simplify this by having a JAVA_FUNCTION which takes the params:

select a,b,c
  JAVA_FUNCTION(d,e,f,COLUMN00,..,COLUMN89) as col_value
 ...

So, that the switch happens in Java, but that's when we ran into the "number of arguments" limit of 90.

As per your suggestion, I created a UDT which takes 90 parameters and assigns them to the internal array.
Then an inner function calculates an index into that array based on (d,e,f) and returns the value without resorting to a switch.

So, I was able to properly define and create the UDT and the function, but have trouble invoking it.
What I’m attempting to do is:

select a,b,c,
  JAVA_FUNCTION(d,e,f,USER_DEFINED_TYPE(COLUMN00, ... , COLUMN89)) as col_value
  ...

But doing so causes the following error:

java.sql.SQLSyntaxErrorException: 'USER_DEFINED_TYPE' is not recognized as a function or procedure.
        at org.apache.derby.impl.jdbc.SQLExceptionFactory40.getSQLException(Unknown Source)
        at org.apache.derby.impl.jdbc.Util.generateCsSQLException(Unknown Source)
        at org.apache.derby.impl.jdbc.TransactionResourceImpl.wrapInSQLException(Unknown Source)
        at org.apache.derby.impl.jdbc.TransactionResourceImpl.handleException(Unknown Source)
        at org.apache.derby.impl.jdbc.EmbedConnection.handleException(Unknown Source)
        at org.apache.derby.impl.jdbc.ConnectionChild.handleException(Unknown Source)
        at org.apache.derby.impl.jdbc.EmbedPreparedStatement.<init>(Unknown Source)
        at org.apache.derby.impl.jdbc.EmbedPreparedStatement20.<init>(Unknown Source)
        at org.apache.derby.impl.jdbc.EmbedPreparedStatement30.<init>(Unknown Source)
        at org.apache.derby.impl.jdbc.EmbedPreparedStatement40.<init>(Unknown Source)
        at org.apache.derby.jdbc.Driver40.newEmbedPreparedStatement(Unknown Source)
        at org.apache.derby.impl.jdbc.EmbedConnection.prepareStatement(Unknown Source)
        at org.apache.derby.impl.jdbc.EmbedConnection.prepareStatement(Unknown Source)
Caused by: ERROR 42Y03: 'USER_DEFINED_TYPE' is not recognized as a function or procedure.
        at org.apache.derby.iapi.error.StandardException.newException(Unknown Source)
        at org.apache.derby.impl.sql.compile.StaticMethodCallNode.bindExpression(Unknown Source)
        at org.apache.derby.impl.sql.compile.JavaToSQLValueNode.bindExpression(Unknown Source)
        at org.apache.derby.impl.sql.compile.SQLToJavaValueNode.bindExpression(Unknown Source)
        at org.apache.derby.impl.sql.compile.MethodCallNode.bindParameters(Unknown Source)
        at org.apache.derby.impl.sql.compile.StaticMethodCallNode.bindExpression(Unknown Source)
        at org.apache.derby.impl.sql.compile.JavaToSQLValueNode.bindExpression(Unknown Source)
        at org.apache.derby.impl.sql.compile.ResultColumn.bindExpression(Unknown Source)
        at org.apache.derby.impl.sql.compile.ResultColumnList.bindExpressions(Unknown Source)
        at org.apache.derby.impl.sql.compile.SelectNode.bindExpressions(Unknown Source)
        at org.apache.derby.impl.sql.compile.TableOperatorNode.bindExpressions(Unknown Source)
        at org.apache.derby.impl.sql.compile.UnionNode.bindExpressions(Unknown Source)
        at org.apache.derby.impl.sql.compile.TableOperatorNode.bindExpressions(Unknown Source)
        at org.apache.derby.impl.sql.compile.UnionNode.bindExpressions(Unknown Source)
        at org.apache.derby.impl.sql.compile.DMLStatementNode.bindExpressions(Unknown Source)
        at org.apache.derby.impl.sql.compile.DMLStatementNode.bind(Unknown Source)
        at org.apache.derby.impl.sql.compile.CursorNode.bindStatement(Unknown Source)
        at org.apache.derby.impl.sql.GenericStatement.prepMinion(Unknown Source)
        at org.apache.derby.impl.sql.GenericStatement.prepare(Unknown Source)
        at org.apache.derby.impl.sql.conn.GenericLanguageConnectionContext.prepareInternalStatement(Unknown Source)


What am I doing incorrectly?

Thanks,


-----Original Message-----
From: Sekhar [mailto:kosurusekhar@gmail.com]
Sent: Friday, December 28, 2012 1:22 AM
To: derby-user@db.apache.org
Subject: Re: number of parameters


Pavel Bortnovskiy <pb...@...> writes:

>
>
>
> Hello:
>
> we have a need to create a java-mapped function which will take 92
parameters, but we are running into Derby’s limitation:
>
> Caused by: java.sql.SQLException: The limit for the number of
> parameters for
a procedure has been exceeded. Limit is 90 and number of parameters for procedure
>  CALC_VALUES are 92.
>
> http://db.apache.org/derby/docs/10.8/ref/rrefdbmlimits.html
>
> Can this limit either be increased or worked-around?
>
> Thanks,
> Pavel.
>
>
>
Hi Pavel

The best solution is rather than passing 92 method parameters we can create User Defined Type in Derby. An UDT will point to external java class where we can have all parameters as properties. now you can use this class as a single parameter.


Regards
Sekhar.





Jefferies archives and monitors outgoing and incoming e-mail. The contents of this email, including any attachments, are confidential to the ordinary user of the email address to which it was addressed. If you are not the addressee of this email you may not copy, forward, disclose or otherwise use it or any part of it in any form whatsoever. This email may be produced at the request of regulators or in connection with civil litigation. Jefferies accepts no liability for any errors or omissions arising as a result of transmission. Use by other than intended recipients is prohibited. In the United Kingdom, Jefferies operates as Jefferies International Limited; registered in England: no. 1978621; registered office: Vintners Place, 68 Upper Thames Street, London EC4V 3BJ. Jefferies International Limited is authorised and regulated by the Financial Services Authority.

Re: number of parameters

Posted by Sekhar <ko...@gmail.com>.
Pavel Bortnovskiy <pb...@...> writes:

> 
> 
> 
> Hello:
>  
> we have a need to create a java-mapped function which will take 92 
parameters, but we are running into Derby’s limitation:
>  
> Caused by: java.sql.SQLException: The limit for the number of parameters for 
a procedure has been exceeded. Limit is 90 and number of parameters for 
procedure
>  CALC_VALUES are 92.
>  
> http://db.apache.org/derby/docs/10.8/ref/rrefdbmlimits.html
>  
> Can this limit either be increased or worked-around?
>  
> Thanks,
> Pavel.
> 
> 
> 
> Jefferies archives and monitors outgoing and incoming e-mail. The contents of 
this email, including any attachments, are confidential to the ordinary user of 
the email address to which it was addressed. If you are not the addressee of 
this email you may not
>  copy, forward, disclose or otherwise use it or any part of it in any form 
whatsoever. This email may be produced at the request of regulators or in 
connection with civil litigation. Jefferies accepts no liability for any errors 
or omissions arising as a result
>  of transmission. Use by other than intended recipients is prohibited. In the 
United Kingdom, Jefferies operates as Jefferies International Limited; 
registered in England: no. 1978621; registered office: Vintners Place, 68 Upper 
Thames Street, London EC4V 3BJ.
>  Jefferies International Limited is authorised and regulated by the Financial 
Services Authority.
> 
> 
Hi Pavel

The best solution is rather than passing 92 method parameters we can create 
User Defined Type in Derby. An UDT will point to external java class where we 
can have all parameters as properties. now you can use this class as a single 
parameter. 


Regards
Sekhar.