Roman Rokytskyy escreveu:

>> Our output parameters (of stored procedures) are different from others
>> DBMS. So I think we may use something (ResultSet, for example) different.
>>
>
> Sorry, it must be supported as well.
>
> Like it or not, the SQL/J is supported by Oracle, IBM and Sybase at
> least, so there is no other options. The ResultSet is somewhat different
> and as extension should be supported too.
>

Ok.

>
>> In Oracle, you (always, AFAIK) need to specify the parameter types and
>> return type. You can specify types as "int" or "java.lang.Integer".
>>
>> In the implementation I'm doing, if types are not passed, it
>> automatically maps INTEGER to java.lang.Integer.
>>
>
> Correct.
>
>
>> IMO, we should never
>> transform NULL to 0.
>>
>
> It will happen automatically when you use "int" not "java.lang.Integer"
> in method declaration and pass null into Java reflection call. So NULL
> should always be passed as null and if developers on the other end are
> clever enough, they will use java.lang.Integer to be notified about NULLs.
>

It's ugly, but to use "int" (instead of java.lang.Integer) one will need
to explicit specify it, so he will (must) be aware of this.

And do you have something related to triggers? AFAIK, support for Java
triggers in Oracle is inexistent. One need to write a PL/SQL trigger
that calls an external procedure. This design limits everything good an
external trigger may do, like working with all fields (old and new) from
the table.


Adriano