Peter Nabbefeld <[EMAIL PROTECTED]> writes: [snip] > Just some thoughts (without knowing the source): > - Table creation isn't affected by the issue, while trigger creation > is, so both seem to get the oid from different algorithms. > - I guess, that the original implementation used the oid from the > default schema, while it has been changed later to be stored into and > used from the system tables. > - Thus, it would probably help to (1) add a method like "getOID()" to > the "UserObject" (don't know the class name used in derby, but there > should be an object representing the user); (2) use this method > instead of a direct access to schema or system tables.
Well, actually Derby has something called LanguageConnectionContext. This class has a getDefaultSchema() method that returns a SchemaDescriptor. A SchemaDescriptor has getUUid() method that is an accessor for its oid attribute. I THINK that when creating a trigger, the code needs a "compile schema" and it assumes that it is safe to use the default schema, which it isn't in this case. So I guess you could attack this problem in (at least) two ways: 1) Make the trigger code use a schema that is known to be ok 2) Ensure that the default schema always is valid. > Just a guess, just because it seems to already take some time to fix > the bug. From my point of view, it should be easy for a derby > developer to fix this (but probably that is the cause for it to still > exist ;-) ). Well, I will update DERBY-85 with the info that I have. Perhaps the Derby experts have some ideas about this :) -- dt However, experience shows that for many people and many applications a dose of paranoia is reasonable - Bjarne Stroustrup
