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 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 of
different classes. As an example, a sales order consists of the order
header and a variable number of order lines. Therefore, per order we
have one OH instance and several OL's. So far so good. Naturally, one
Java object instance would correspond to one row in a database.
If we now implement a stored procedure in PL/Java, that means that a
pg_proc entry corresponds to a specific method of a specific class (its
signature). But there is no obvious relationship between functions and
tables or other objects. Because of that it is not implicitly clear if
an incoming call to a method is meant for an existing instance or if a
new one should be created.
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 NOT result in
another OH instance being created for the same logical OH.
Probably it is not possible to map these things automatically while
keeping the system flexible enough to be usefull. But is it feasable to
require the programmer to provide glue code for every procedure that
does all these things? How does Oracle attack this problem?
Jan
--
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#================================================== JanWieck@Yahoo.com #
