db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Nabbefeld <Peter.Nabbef...@gmx.de>
Subject Re: 10.1 branch created / please review open 10.1 JIRA issues
Date Sat, 11 Jun 2005 17:53:29 GMT
Daniel John Debrunner schrieb:
> Peter Nabbefeld wrote:
>>Andrew McIntyre schrieb:
>>>On Jun 10, 2005, at 2:29 AM, Peter Nabbefeld wrote:
>>>>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 

> 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 ...


> Dan.

View raw message