db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel John Debrunner <...@debrunners.com>
Subject Re: 10.1 branch created / please review open 10.1 JIRA issues
Date Sat, 11 Jun 2005 14:53:01 GMT
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. 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.

Dan.



Mime
View raw message