Daniel John Debrunner schrieb:
Peter Nabbefeld wrote:
Andrew McIntyre schrieb:
On Jun 10, 2005, at 2:29 AM, Peter Nabbefeld wrote:
Hello,
what about DERBY-85? It is still open - will it be fixed in 10.1? Or
probably never?
Kind regards
Peter Nabbefeld
It will be fixed when a Derby developer decides to fix it. Are you
volunteering? :-)
Sorry, I don't have any knowledge of the derby source code. From the
comments to my questions (didn't know, that this is a known bug before),
I'd guess that it should be simple to fix it:
- It seems, that the UUID is probably used as the owner-id of the
trigger object.
- Because tables can be created in non-default schemas, while triggers
can not, I guess that there is some duplicate code (which has been fixed
for one case, but not for the other).
- I'd propose to add a method like "getUUID" to the Connection object,
so both implementations (table and trigger) could be replaced just by a
call to Connection.getUUID().
Just my 2 cents ...
The null UUID is most likely is the UUID of the schema itself, not of
its owner.
Is the default schema the owner of the trigger then? Or why is the
default schema needed, if I set a trigger on a table in a non-default
schema?
A schema that is being used but does not exist (has not been
created persistently) has a null UUID.
JDBC Connection's don't have a UUID that represents the identity of the
owner. Derby's engine code is centered around the
LanguageConnectionContext (LCC) and not the JDBC Connection object. The
JDBC object could be seen as just a wrapper on top of LCC. Thus most of
the connection's state that is relevant to the SQL language layer is
held in the LCC.
I cannot find any UUID getter methods neither in LLC nor its superclass,
while from my point of view there should exist some ...
Peter
Dan.
