Peter Eisentraut wrote:
Andrew Dunstan wrote:
Will we need to address this TODO item:
. Add capability to create and call PROCEDURES
before proceding to do PL/Java? It would add to the usefulness
greatly, I should think. I'm not sure how hard it would be.
This should be relatively easy
Andrew Dunstan wrote:
> Will we need to address this TODO item:
>
> . Add capability to create and call PROCEDURES
>
> before proceding to do PL/Java? It would add to the usefulness
> greatly, I should think. I'm not sure how hard it would be.
This should be relatively easy if you omit OUT param
I'm working on a pl/java project and have come quite far with it. Triggers
and Functions are both callable, there's support for complex types etc. I
have a project on GBorg (pljava) where I'll post all source in a CVS
repository in a matter of days (the code is ready but my ISP have a router
proble
Joe Conway said:
> Andrew Dunstan wrote:
>> AFAIK it is not available except for $$$. It looks like the relevant
>> standards are parts 1 and 2 of the SQLJ standard (Part 0 covers
>> embedded SQL).
>>
>
> For working drafts try:
>
> http://www.wiscorp.com/sql/sql_2003_standard.zip
> (5WD-13-JRT-200
Dave Cramer said:
> Can you explain what you mean by this?
>
> On Fri, 2004-01-02 at 20:21, Andrew Dunstan wrote:
>> Will we need to address this TODO item:
>>
>> . Add capability to create and call PROCEDURES
>>
>> before proceding to do PL/Java? It would add to the usefulness
>> greatly, I sho
Barry,
Ok, so if we drop this limitation then we leave it up to the architect
to manage the caching problem themselves.
The class loader issue is interesting, this would mean that each object
static or otherwise would not be able to overwrite others data.
--dc--
On Wed, 2003-12-31 at 19:34, Barr
Can you explain what you mean by this?
Dave
On Fri, 2004-01-02 at 20:21, Andrew Dunstan wrote:
> Will we need to address this TODO item:
>
> . Add capability to create and call PROCEDURES
>
> before proceding to do PL/Java? It would add to the usefulness greatly,
> I should think. I'm not sur
Andrew Dunstan wrote:
AFAIK it is not available except for $$$. It looks like the relevant
standards are parts 1 and 2 of the SQLJ standard (Part 0 covers embedded
SQL).
For working drafts try:
http://www.wiscorp.com/sql/sql_2003_standard.zip
(5WD-13-JRT-2003-09.pdf)
http://www.wiscorp.com/sql/sql
Will we need to address this TODO item:
. Add capability to create and call PROCEDURES
before proceding to do PL/Java? It would add to the usefulness greatly,
I should think. I'm not sure how hard it would be.
cheers
andrew
---(end of broadcast)-
Dave Cramer wrote:
Barry,
Ok, so if we drop this limitation then we leave it up to the architect
to manage the caching problem themselves.
Maybe I don't understand enough about Java, but isn't this limitation
(only static methods callable) exactly what avoids having to deal with
the call->insta
Dave Cramer said:
> Where is the standard, I for one would be interested in seeing it?
>
AFAIK it is not available except for $$$. It looks like the relevant
standards are parts 1 and 2 of the SQLJ standard (Part 0 covers embedded
SQL).
cheers
andrew
---(end of broadca
Where is the standard, I for one would be interested in seeing it?
Dave
On Fri, 2004-01-02 at 01:09, Andrew Dunstan wrote:
> Jan Wieck wrote:
>
> > The basic question is the definition of the lifetime of an object and
> > it's identificaition when doing nested calls in this context. In the
> >
Jan Wieck wrote:
The basic question is the definition of the lifetime of an object and
it's identificaition when doing nested calls in this context. In the
OO world, ideally a real world object is translated into one instance
of a class. And complex structures are trees of instances, possibly
Barry,
This appears in principal to be very close to a servlet container. I'm
wondering if we could just use something like jetty as the basis for the
work?
It has already defined class loading per the servlet spec. It is already
setup to handle multiple requests, and load balancing, etc.
Dave
Barry,
Ok, so if we drop this limitation then we leave it up to the architect
to manage the caching problem themselves.
The class loader issue is interesting, this would mean that each object
static or otherwise would not be able to overwrite others data.
--dc--
On Wed, 2003-12-31 at 19:34, Barr
Jan,
In Oracle a call from sql into java (be it trigger, stored procedure or
function), is required to be a call to a static method. Thus in Oracle
all the work is left for the programmer to manage object instances and
operate on the correct ones. While I don't like this limitation in
Oracle
Jan Wieck wrote:
> As an example, if a PL/Java trigger on the order header executes an SPI
> query on the order lines, a trigger on the order line (also in PL/Java)
> might now want to call a method on it's parent object (the order header
> that is waiting for the SPI result set). This should NO
I have included the JDBC mailing list since I guess most Java developers
are around here, but not necessarily on Hackers.
Dave Cramer and I where discussing a few issues about the PL/Java
implementation last night and would like to get more input and
suggestions on the matter.
The basic questi
18 matches
Mail list logo
