db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dyre.Tjeldv...@Sun.COM
Subject Re: NullPointerException in derby
Date Tue, 07 Jun 2005 13:17:58 GMT
Peter Nabbefeld <Peter.Nabbefeld@gmx.de> writes:
> 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 :)


However, experience shows that for many people and many applications a
dose of paranoia is reasonable - Bjarne Stroustrup

View raw message