You are viewing a plain text version of this content. The canonical link for it is here.
Posted to derby-dev@db.apache.org by Dy...@Sun.COM on 2005/06/06 14:38:09 UTC
Re: NullPointerException in derby
Peter Nabbefeld <Pe...@gmx.de> writes:
> Hello,
>
> I've got the following NPE:
>
> java.lang.NullPointerException
> at
> org.apache.derby.impl.sql.catalog.SYSSTATEMENTSRowFactory.makeSYSSTATEMENTSrow(Unknown
> Source)
> at
> org.apache.derby.impl.sql.catalog.DataDictionaryImpl.addSPSDescriptor(Unknown
> Source)
> at
> org.apache.derby.impl.sql.execute.CreateTriggerConstantAction.createSPS(Unknown
> Source)
> at
> org.apache.derby.impl.sql.execute.CreateTriggerConstantAction.executeConstantAction(Unknown
> Source)
> at
> org.apache.derby.impl.sql.execute.MiscResultSet.open(Unknown Source)
> at
> org.apache.derby.impl.sql.GenericPreparedStatement.execute(Unknown
> Source)
> at
> org.apache.derby.impl.jdbc.EmbedStatement.executeStatement(Unknown
> Source)
> at org.apache.derby.impl.jdbc.EmbedStatement.execute(Unknown
> Source)
> at org.apache.derby.impl.jdbc.EmbedStatement.execute(Unknown
> Source)
> ...
>
> My SQL statement is:
> CREATE TRIGGER APPBUT_USER.EMRSZDEL AFTER DELETE ON
> APPBUT_USER.EMPLOYERS FOR EACH STATEMENT MODE DB2SQL
> VALUES(APPBUT_USER.TRIGGER_RESIZE('APPBUT_USER','EMPLOYERS'))
>
> Could anybody please tell me, what's wrong with that? I'm using derby
> 10.0.2.2.
Looks like you are experiencing
http://issues.apache.org/jira/browse/DERBY-85
I don't think this has been fixed yet, but if this is your problem you
can work around it by having a non-empty table in the default
schema.
<details>
Looks like the oid for the default schema is null until a row is
inserted in a table in the default schema. This oid is referenced when
creating a trigger, even if that trigger doesn't touch the default schema
</details>
At least that worked for me when trying the example in
DERBY-85:
s.execute("create table itko.t1 (i int)");
// Workaround
s.execute("create table def (i int)");
s.execute("insert into def values (0), (1), (2)");
// Example from DERBY-85
s.execute("create trigger ikto.trig1 after update on itko.t1 for each row mode db2sql select * from sys.systables");
[snip]
--
dt
However, experience shows that for many people and many applications a
dose of paranoia is reasonable - Bjarne Stroustrup
Re: NullPointerException in derby
Posted by Peter Nabbefeld <Pe...@gmx.de>.
I've just begun to use derby, so I don't currently know how to check for
the user of a table. What I'd like to know is: When I'm using a database
without default schema, just creating a schema in a different schema and
inserting a row - who's the owner? Just to make it clear, assume the
username is "user", the schema is "xuser" - will the owner be "user" or
"xuser"?
Regards,
Peter
Dyre.Tjeldvoll@Sun.COM schrieb:
> [...]
>
Re: NullPointerException in derby
Posted by Peter Nabbefeld <Pe...@gmx.de>.
Dyre.Tjeldvoll@Sun.COM schrieb:
> Peter Nabbefeld <Pe...@gmx.de> 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
Re: NullPointerException in derby
Posted by Dy...@Sun.COM.
Peter Nabbefeld <Pe...@gmx.de> 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
Re: NullPointerException in derby
Posted by Peter Nabbefeld <Pe...@gmx.de>.
Peter Nabbefeld schrieb:
> Dyre.Tjeldvoll@Sun.COM schrieb:
>
>> Peter Nabbefeld <Pe...@gmx.de> writes:
>>
>>
>>> Hello,
>>>
>>> I've got the following NPE:
>>>
>>> java.lang.NullPointerException
>>> at
>>> org.apache.derby.impl.sql.catalog.SYSSTATEMENTSRowFactory.makeSYSSTATEMENTSrow(Unknown
>>>
>>> Source)
>>> at
>>> org.apache.derby.impl.sql.catalog.DataDictionaryImpl.addSPSDescriptor(Unknown
>>>
>>> Source)
>>> at
>>> org.apache.derby.impl.sql.execute.CreateTriggerConstantAction.createSPS(Unknown
>>>
>>> Source)
>>> at
>>> org.apache.derby.impl.sql.execute.CreateTriggerConstantAction.executeConstantAction(Unknown
>>>
>>> Source)
>>> at
>>> org.apache.derby.impl.sql.execute.MiscResultSet.open(Unknown Source)
>>> at
>>> org.apache.derby.impl.sql.GenericPreparedStatement.execute(Unknown
>>> Source)
>>> at
>>> org.apache.derby.impl.jdbc.EmbedStatement.executeStatement(Unknown
>>> Source)
>>> at org.apache.derby.impl.jdbc.EmbedStatement.execute(Unknown
>>> Source)
>>> at org.apache.derby.impl.jdbc.EmbedStatement.execute(Unknown
>>> Source)
>>> ...
>>>
>>> My SQL statement is:
>>> CREATE TRIGGER APPBUT_USER.EMRSZDEL AFTER DELETE ON
>>> APPBUT_USER.EMPLOYERS FOR EACH STATEMENT MODE DB2SQL
>>> VALUES(APPBUT_USER.TRIGGER_RESIZE('APPBUT_USER','EMPLOYERS'))
>>>
>>> Could anybody please tell me, what's wrong with that? I'm using derby
>>> 10.0.2.2.
>>
>>
>>
>> Looks like you are experiencing
>> http://issues.apache.org/jira/browse/DERBY-85
>>
>
> Yes, this seems to be the problem - the issue describes exactly, what I
> did :-(
>
>
>> I don't think this has been fixed yet, [...]
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.
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 ;-) ).
Kind regards
Peter Nabbefeld
Re: NullPointerException in derby
Posted by Dy...@Sun.COM.
Peter Nabbefeld <Pe...@gmx.de> writes:
[snip]
> That's bad - it means, that I've to manage data, which I don't
> need. Any idea, when this bug will be fixed?
Well, I have looked at it. That's how I recognized your problem :) But
I'm afraid I'm a Derby novice, so although I have an idea about
what's going on, I can't promise a fix... :(
--
dt
Re: NullPointerException in derby
Posted by Peter Nabbefeld <Pe...@gmx.de>.
Dyre.Tjeldvoll@Sun.COM schrieb:
> Peter Nabbefeld <Pe...@gmx.de> writes:
>
>
>>Hello,
>>
>>I've got the following NPE:
>>
>>java.lang.NullPointerException
>> at
>>org.apache.derby.impl.sql.catalog.SYSSTATEMENTSRowFactory.makeSYSSTATEMENTSrow(Unknown
>>Source)
>> at
>>org.apache.derby.impl.sql.catalog.DataDictionaryImpl.addSPSDescriptor(Unknown
>>Source)
>> at
>>org.apache.derby.impl.sql.execute.CreateTriggerConstantAction.createSPS(Unknown
>>Source)
>> at
>>org.apache.derby.impl.sql.execute.CreateTriggerConstantAction.executeConstantAction(Unknown
>>Source)
>> at
>>org.apache.derby.impl.sql.execute.MiscResultSet.open(Unknown Source)
>> at
>>org.apache.derby.impl.sql.GenericPreparedStatement.execute(Unknown
>>Source)
>> at
>>org.apache.derby.impl.jdbc.EmbedStatement.executeStatement(Unknown
>>Source)
>> at org.apache.derby.impl.jdbc.EmbedStatement.execute(Unknown
>>Source)
>> at org.apache.derby.impl.jdbc.EmbedStatement.execute(Unknown
>>Source)
>> ...
>>
>>My SQL statement is:
>>CREATE TRIGGER APPBUT_USER.EMRSZDEL AFTER DELETE ON
>>APPBUT_USER.EMPLOYERS FOR EACH STATEMENT MODE DB2SQL
>>VALUES(APPBUT_USER.TRIGGER_RESIZE('APPBUT_USER','EMPLOYERS'))
>>
>>Could anybody please tell me, what's wrong with that? I'm using derby
>>10.0.2.2.
>
>
> Looks like you are experiencing
> http://issues.apache.org/jira/browse/DERBY-85
>
Yes, this seems to be the problem - the issue describes exactly, what I
did :-(
> I don't think this has been fixed yet, but if this is your problem you
> can work around it by having a non-empty table in the default
> schema.
>
> <details>
> Looks like the oid for the default schema is null until a row is
> inserted in a table in the default schema. This oid is referenced when
> creating a trigger, even if that trigger doesn't touch the default schema
> </details>
>
> At least that worked for me when trying the example in
> DERBY-85:
>
> s.execute("create table itko.t1 (i int)");
> // Workaround
> s.execute("create table def (i int)");
> s.execute("insert into def values (0), (1), (2)");
>
> // Example from DERBY-85
> s.execute("create trigger ikto.trig1 after update on itko.t1 for each row mode db2sql select * from sys.systables");
>
> [snip]
>
That's bad - it means, that I've to manage data, which I don't need. Any
idea, when this bug will be fixed?
Kind regards
Peter Nabbefeld
Re: NullPointerException in derby
Posted by Peter Nabbefeld <Pe...@gmx.de>.
Dyre.Tjeldvoll@Sun.COM schrieb:
> Peter Nabbefeld <Pe...@gmx.de> writes:
>
>
>>Hello,
>>
>>I've got the following NPE:
>>
>>java.lang.NullPointerException
>> at
>>org.apache.derby.impl.sql.catalog.SYSSTATEMENTSRowFactory.makeSYSSTATEMENTSrow(Unknown
>>Source)
>> at
>>org.apache.derby.impl.sql.catalog.DataDictionaryImpl.addSPSDescriptor(Unknown
>>Source)
>> at
>>org.apache.derby.impl.sql.execute.CreateTriggerConstantAction.createSPS(Unknown
>>Source)
>> at
>>org.apache.derby.impl.sql.execute.CreateTriggerConstantAction.executeConstantAction(Unknown
>>Source)
>> at
>>org.apache.derby.impl.sql.execute.MiscResultSet.open(Unknown Source)
>> at
>>org.apache.derby.impl.sql.GenericPreparedStatement.execute(Unknown
>>Source)
>> at
>>org.apache.derby.impl.jdbc.EmbedStatement.executeStatement(Unknown
>>Source)
>> at org.apache.derby.impl.jdbc.EmbedStatement.execute(Unknown
>>Source)
>> at org.apache.derby.impl.jdbc.EmbedStatement.execute(Unknown
>>Source)
>> ...
>>
>>My SQL statement is:
>>CREATE TRIGGER APPBUT_USER.EMRSZDEL AFTER DELETE ON
>>APPBUT_USER.EMPLOYERS FOR EACH STATEMENT MODE DB2SQL
>>VALUES(APPBUT_USER.TRIGGER_RESIZE('APPBUT_USER','EMPLOYERS'))
>>
>>Could anybody please tell me, what's wrong with that? I'm using derby
>>10.0.2.2.
>
>
> Looks like you are experiencing
> http://issues.apache.org/jira/browse/DERBY-85
>
Yes, this seems to be the problem - the issue describes exactly, what I
did :-(
> I don't think this has been fixed yet, but if this is your problem you
> can work around it by having a non-empty table in the default
> schema.
>
> <details>
> Looks like the oid for the default schema is null until a row is
> inserted in a table in the default schema. This oid is referenced when
> creating a trigger, even if that trigger doesn't touch the default schema
> </details>
>
> At least that worked for me when trying the example in
> DERBY-85:
>
> s.execute("create table itko.t1 (i int)");
> // Workaround
> s.execute("create table def (i int)");
> s.execute("insert into def values (0), (1), (2)");
>
> // Example from DERBY-85
> s.execute("create trigger ikto.trig1 after update on itko.t1 for each row mode db2sql select * from sys.systables");
>
> [snip]
>
That's bad - it means, that I've to manage data, which I don't need. Any
idea, when this bug will be fixed?
Kind regards
Peter Nabbefeld