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.
