Mailing-List: contact derby-user-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Derby Discussion" <derby-user@db.apache.org>
Received-SPF: pass (athena.apache.org: domain of
 david.myers.scibearspace@gmail.com designates 209.85.217.172 as permitted
 sender)
Message-ID: <50BCAF6A.9010608@gmail.com>
Date: Mon, 03 Dec 2012 14:55:54 +0100
From: david myers <david.myers.scibearspace@gmail.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
 rv:17.0) Gecko/17.0 Thunderbird/17.0
MIME-Version: 1.0
To: derby-user@db.apache.org
Subject: Re: NullPointerException in Derby 10.9.1.0
References: <50B66527.5040906@gmail.com>
 <wjo8boebi8j6.fsf@khepri41.no.oracle.com>
In-Reply-To: <wjo8boebi8j6.fsf@khepri41.no.oracle.com>
Content-Type: multipart/alternative;
 boundary="------------090709040902030003040607"

This is a multi-part message in MIME format.
--------------090709040902030003040607
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

On 03/12/12 14:12, Knut Anders Hatlen wrote:
> Zorro <hz0885@gmail.com> writes:
>
>> Dear All,
>>
>> When doing in ij a bulk Insert into a table of my Derby database I do
>> get a NullPointerException.
> Hi Harm-Jan,
>
> It looks like you've come across a bug. I managed to reproduce the
> NullPointerException in my environment, so I filed a bug report and
> posted the steps I followed in order to reproduce it there:
> https://issues.apache.org/jira/browse/DERBY-6006
>
> Thanks for reporting the problem,
>
Hi Harm-Jan and Knut,

first off a bit of a long post, but I hope it may be informative...

I've just seen Knut's jira bug ([jira] (DERBY-6006)), and wonder (having 
looked at the stack trace that was posted) if the 'conglomerate' error 
at the top of the stack is related to a problem I experienced.

My problem can be recreated as follows....

 > Create a table in your db (any structure will do)
 > programatically take one of your fields and change its data type 
(from int to float for example).

    When you do this programatically the only way to do it is to...
     > create a new 'temp' field
     > copy the values from the original into the new
     > drop the original table
     > rename the 'temp' field so as you can use your table in your
    previously created routines etc...

 > the problem this creates is that the new 'temp' field, although for 
all intents is the 'same' as the original has a different value in the 
conglomerates tables.

Result:
     If you have use an external process that inserts data into the 
table from a select * the order of the fields has changed, and so the 
insert fails as the original fields have been 'shifted' to the left.

EG: Original table field order.
field1:field2:changeTypeOfThisfield:field3:field4:field5

new field after the modification.

field1:field2:field3:field4:field5:changedTypeOfThisField

Solution:

Programatically capture the names of the fields to ensure they stay in a 
'predefined' order.

The problem seen by Harm-Jan may have an similar solution, the problem 
being of course that it is now neccessary to programatically do the 
insert select (rather then being able to do it directly in ij), which 
seems a bit brutal.

So the reflection for Knut is: Is it possible to that internally the 
engine is creating a temp / shadow table and making a mess of these 
conglomerates during that process, and doing something like I have 
encountered (and how to test if the conglomerates are changing in this way)

If so my problem, which I have been considering calling a 'documentation 
bug' on, may be less benign and require a more involved solution.

Of course I may be off the mark, it was seeing the 'conglomerates error' 
that made me connect the 2 in my mind.

David.


--------------090709040902030003040607
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    <div class="moz-cite-prefix">On 03/12/12 14:12, Knut Anders Hatlen
      wrote:<br>
    </div>
    <blockquote cite="mid:wjo8boebi8j6.fsf@khepri41.no.oracle.com"
      type="cite">
      <pre wrap="">Zorro <a class="moz-txt-link-rfc2396E" href="mailto:hz0885@gmail.com">&lt;hz0885@gmail.com&gt;</a> writes:

</pre>
      <blockquote type="cite">
        <pre wrap="">Dear All,

When doing in ij a bulk Insert into a table of my Derby database I do
get a NullPointerException.
</pre>
      </blockquote>
      <pre wrap="">
Hi Harm-Jan,

It looks like you've come across a bug. I managed to reproduce the
NullPointerException in my environment, so I filed a bug report and
posted the steps I followed in order to reproduce it there:
<a class="moz-txt-link-freetext" href="https://issues.apache.org/jira/browse/DERBY-6006">https://issues.apache.org/jira/browse/DERBY-6006</a>

Thanks for reporting the problem,

</pre>
    </blockquote>
    Hi Harm-Jan and Knut,<br>
    <br>
    first off a bit of a long post, but I hope it may be informative...<br>
    <br>
    I've just seen Knut's jira bug ([jira] (DERBY-6006)), and wonder
    (having looked at the stack trace that was posted) if the
    'conglomerate' error at the top of the stack is related to a problem
    I experienced.<br>
    <br>
    My problem can be recreated as follows....<br>
    <br>
    &gt; Create a table in your db (any structure will do)<br>
    &gt; programatically take one of your fields and change its data
    type (from int to float for example).<br>
    <blockquote>When you do this programatically the only way to do it
      is to...<br>
      &gt; create a new 'temp' field<br>
      &gt; copy the values from the original into the new<br>
      &gt; drop the original table<br>
      &gt; rename the 'temp' field so as you can use your table in your
      previously created routines etc...<br>
    </blockquote>
    &gt; the problem this creates is that the new 'temp' field, although
    for all intents is the 'same' as the original has a different value
    in the conglomerates tables.<br>
    <br>
    Result:<br>
    &nbsp;&nbsp;&nbsp; If you have use an external process that inserts data into the
    table from a select * the order of the fields has changed, and so
    the insert fails as the original fields have been 'shifted' to the
    left.<br>
    <br>
    EG: Original table field order.<br>
    field1:field2:changeTypeOfThisfield:field3:field4:field5<br>
    <br>
    new field after the modification.<br>
    <br>
    field1:field2:field3:field4:field5:changedTypeOfThisField<br>
    <br>
    Solution:<br>
    <br>
    Programatically capture the names of the fields to ensure they stay
    in a 'predefined' order.<br>
    <br>
    The problem seen by Harm-Jan may have an similar solution, the
    problem being of course that it is now neccessary to programatically
    do the insert select (rather then being able to do it directly in
    ij), which seems a bit brutal.<br>
    <br>
    So the reflection for Knut is: Is it possible to that internally the
    engine is creating a temp / shadow table and making a mess of these
    conglomerates during that process, and doing something like I have
    encountered (and how to test if the conglomerates are changing in
    this way)<br>
    <br>
    If so my problem, which I have been considering calling a
    'documentation bug' on, may be less benign and require a more
    involved solution.<br>
    <br>
    Of course I may be off the mark, it was seeing the 'conglomerates
    error' that made me connect the 2 in my mind.<br>
    <br>
    David.<br>
    <br>
    <br>
  </body>
</html>

--------------090709040902030003040607--