[EMAIL PROTECTED] schrieb:
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 :)
That will at least be a first step - hopefully not the last - to fix a
half-year-old bug ;-)
Regards
Peter
