castor

SQLException: Column Index out of range, 5 > 4.

Details

  • Type: Bug Bug
  • Status: Closed Closed
  • Priority: Blocker Blocker
  • Resolution: Fixed
  • Affects Version/s: 1.0.5
  • Fix Version/s: 1.1.1
  • Component/s: JDO
  • Labels:
    None
  • Environment:
    OS: Windows XP Professional
    BD: mySQL 5.1.14
  • Number of attachments :
    5

Description

I'm having a problem when I try to load an object.

I get the error:
GRAVE: A fatal error occurred while loading projectv1a.KnowledgeBase using SQL:
SELECT
knowledgeBase.kbID,instanceList.instanceListID,knowledgeBase.ontologyID,knowledgeBase.relationListID
FROM knowledgeBase LEFT OUTER JOIN instanceList ON
knowledgeBase.kbID=instanceList.knowledgeBaseID WHERE knowledgeBase.kbID=?
java.sql.SQLException: Column Index out of range, 5 > 4.

I have been trying with 3 releases of Castor: 0.9.9, 1.0.3 and the last 1.1M2. In all of them I got the same error.
I have the latest version of mysql-connector(5.0.4).

I want to explain that I donīt do any OQLQuery manually, I execute the method load to load the main object of my aplication and the rest of the
objects are related with the main one. KnowledgeBase is one of this objects. I canīt understand how can I get a SQLException like this.

Attachments

  2. Text File
    patch_1812_20070303.txt
    03/Mar/07 10:02 AM
    5 kB
    Steven Dolg
  3. Text File
    patch-C1812-20070205.txt
    05/Feb/07 3:00 PM
    244 kB
    Ralf Joachim
  4. Text File
    patch-C1812-20070303-02.txt
    03/Mar/07 3:56 PM
    18 kB
    Ralf Joachim

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
azgard added a comment -

I can also confirm this behavior. I have stepped into 1.1M3 and I have found that in my case org.exolab.castor.jdo.engine.SQLStatementLoad.executeStatement() does the wrong step.

On line 334, after the increase of columnIndex, its referenced not the right column-field-bundle. The columnIndex already referenced the next column, but the fieldIndex isnt increased.

if ((i > 0) && !tableName.equals(tableNameOld) && !field.isJoined()) { columnIndex = columnIndex + ids.length; }

Can you give me some feedback?!

Show
azgard added a comment - I can also confirm this behavior. I have stepped into 1.1M3 and I have found that in my case org.exolab.castor.jdo.engine.SQLStatementLoad.executeStatement() does the wrong step. On line 334, after the increase of columnIndex, its referenced not the right column-field-bundle. The columnIndex already referenced the next column, but the fieldIndex isnt increased. if ((i > 0) && !tableName.equals(tableNameOld) && !field.isJoined()) { columnIndex = columnIndex + ids.length; } Can you give me some feedback?!
Hide
Permalink
Ralf Joachim added a comment -

I will try to verify the problem during the next few days. If I am able to find a solution we will include the fix with 1.1 final but I am not able to promis anything yet.

Show
Ralf Joachim added a comment - I will try to verify the problem during the next few days. If I am able to find a solution we will include the fix with 1.1 final but I am not able to promis anything yet.
Hide
Permalink
azgard added a comment -

In my case the entities has the following mapping:

<class name="test.Entity" identity="id">
<map-to table="n_entity" xml="nentity" />
<cache-type type="none" />
<field name="subentity1" type="test.SubEntity1" lazy="true" collection="collection">
<sql many-key="id" read-only="true" dirty="ignore" />
</field>
<field name="subentity2" type="test.SubEntity2" lazy="true">
<sql name="id2" read-only="true" dirty="ignore" />
</field>
....
<field name="id" type="java.math.BigDecimal">
<sql name="id" type="decimal" />
</field>
...
</class>

<class name="test.SubEntity1" identity="id number level" access="read-only">
<map-to table="SubEntity1" xml="SubEntity1" />
<field name="id" type="java.math.BigDecimal">
<sql name="id" type="decimal" />
</field>
<field name="number" type="java.math.BigDecimal">
<sql name="number" type="decimal" />
</field>
<field name="level" type="java.lang.Integer">
<sql name="level" type="integer" />
</field>
...
<field name="entityx" type="test.EntityX">
<sql name="..." read-only="true" dirty="ignore" />
</field>
</class>

If i eliminate the section

<field name="subentity1" type="test.SubEntity1" lazy="true" collection="collection">
<sql many-key="id" read-only="true" dirty="ignore" />
</field>

all works fine. I think its a problem with the multi column compound primary keys!?

Hope this helps.

Show
azgard added a comment - In my case the entities has the following mapping:
<class name="test.Entity" identity="id"> <map-to table="n_entity" xml="nentity" /> <cache-type type="none" /> <field name="subentity1" type="test.SubEntity1" lazy="true" collection="collection"> <sql many-key="id" read-only="true" dirty="ignore" /> </field> <field name="subentity2" type="test.SubEntity2" lazy="true"> <sql name="id2" read-only="true" dirty="ignore" /> </field> .... <field name="id" type="java.math.BigDecimal"> <sql name="id" type="decimal" /> </field> ... </class>
<class name="test.SubEntity1" identity="id number level" access="read-only"> <map-to table="SubEntity1" xml="SubEntity1" /> <field name="id" type="java.math.BigDecimal"> <sql name="id" type="decimal" /> </field> <field name="number" type="java.math.BigDecimal"> <sql name="number" type="decimal" /> </field> <field name="level" type="java.lang.Integer"> <sql name="level" type="integer" /> </field> ... <field name="entityx" type="test.EntityX"> <sql name="..." read-only="true" dirty="ignore" /> </field> </class>
If i eliminate the section
<field name="subentity1" type="test.SubEntity1" lazy="true" collection="collection"> <sql many-key="id" read-only="true" dirty="ignore" /> </field>
all works fine. I think its a problem with the multi column compound primary keys!? Hope this helps.
Hide
Permalink
Ralf Joachim added a comment -

Azgard, can you please attach a simple test case for me to replay the problem. The test of Igarki seams to be a bit more complicated and as he does not use multiple column primary keys his problem may also be related to something different. Please take a look at http://castor.codehaus.org/how-to-submit-a-bug.html about how to submit a bug report.

Show
Ralf Joachim added a comment - Azgard, can you please attach a simple test case for me to replay the problem. The test of Igarki seams to be a bit more complicated and as he does not use multiple column primary keys his problem may also be related to something different. Please take a look at http://castor.codehaus.org/how-to-submit-a-bug.html about how to submit a bug report.
Hide
Permalink
azgard added a comment -

I have submitted a simple testcase that will show you the bug. I have my entities pitted and only simple properties are now included.

I have found the possible change is between version 0.9.9.1 and 1.0M1. When you diff the SQLEngine.java with this two versions you can see the problem.

Plese let me know how I can help. I need urgently a patch!

Show
azgard added a comment - I have submitted a simple testcase that will show you the bug. I have my entities pitted and only simple properties are now included. I have found the possible change is between version 0.9.9.1 and 1.0M1. When you diff the SQLEngine.java with this two versions you can see the problem. Plese let me know how I can help. I need urgently a patch!
Hide
Permalink
azgard added a comment -

Yet another comment: The TestCase will run with 0.9.9.1 and from version 1.0M1 the test will fail.

Hope this helps.

Show
azgard added a comment - Yet another comment: The TestCase will run with 0.9.9.1 and from version 1.0M1 the test will fail. Hope this helps.
Hide
Permalink
azgard added a comment -

Did you had to spend some time to try my test case?

Show
azgard added a comment - Did you had to spend some time to try my test case?
Hide
Permalink
Ralf Joachim added a comment -

Thanks for your test case azgard but I had no time to take a look at it yet. Will try to do so at the weekend.

Show
Ralf Joachim added a comment - Thanks for your test case azgard but I had no time to take a look at it yet. Will try to do so at the weekend.
Hide
Permalink
Ralf Joachim added a comment -

Azgard, I was able to replay your problem. While I could not fix the problem yet, I was able to find a workaround for the time being. I will need some more time to find a fix for this bug and also to see if the problem of Igarki is also caused by this bug.

The problem seams to be the location of the field mapping for plausifehler in DM1Tewe. If the collection mapping for plausifehler is the first none identity field mapping you will get the Column Index out of range error. If you change sequence of the field mappings and put e.g. the one for arztnr first, there will be no error reported with your test case.

Original mapping with error:

<class name="jdo.bug1812.DM1Tewe" identity="barcode">
<map-to table="bug1812_tewe" xml="" />
<cache-type type="none" />
<field name="plausifehler" type="jdo.bug1812.Plausifehler" lazy="true" collection="collection">
<sql many-key="barcode" read-only="true" dirty="ignore" />
</field>
<field name="dmtyp1" type="java.lang.Boolean">
<sql name="dmtyp1" type="integer" />
</field>
<field name="dmtyp2" type="java.lang.Boolean">
<sql name="dmtyp2" type="integer" />
</field>
<field name="arztnr" type="java.lang.Long">
<sql name="arzt" type="bigint" />
</field>
<field name="barcode" type="java.math.BigDecimal">
<sql name="barcode" type="decimal" />
</field>
</class>

Changed mapping without failure:

<class name="jdo.bug1812.DM1Tewe" identity="barcode">
<map-to table="bug1812_tewe" xml="" />
<cache-type type="none" />
<field name="arztnr" type="java.lang.Long">
<sql name="arzt" type="bigint" />
</field>
<field name="plausifehler" type="jdo.bug1812.Plausifehler" lazy="true" collection="collection">
<sql many-key="barcode" read-only="true" dirty="ignore" />
</field>
<field name="dmtyp1" type="java.lang.Boolean">
<sql name="dmtyp1" type="integer" />
</field>
<field name="dmtyp2" type="java.lang.Boolean">
<sql name="dmtyp2" type="integer" />
</field>
<field name="barcode" type="java.math.BigDecimal">
<sql name="barcode" type="decimal" />
</field>
</class>

Having said that I wonder myself that this mapping works at all as there are 2 constructs that are not supported:

1. Castor does not support foreign keys being part of primary keys.

At class Plausifehler you have declared barcode, fehlernr and vorgang as multiple column primary key, but barcode is also the foreign key to DM1Tewe class.

2. Normaly the foreign key column should have the type of the class it refers to.

In class Plausifehler the field barcode is a foreign key to DM1Tewe class. Normaly the mapping of barcode field in Plausifehler class should look like:

<field name="barcode" type="jdo.bug1812.DM1Tewe">
<sql name="barcode"/>
</field>

While the combination of this 2 mapping failures seam to cause no problems with this test case I would wonder if it will work under all situations. And if it does with current release this may change in the futur as this is not intended.

Show
Ralf Joachim added a comment - Azgard, I was able to replay your problem. While I could not fix the problem yet, I was able to find a workaround for the time being. I will need some more time to find a fix for this bug and also to see if the problem of Igarki is also caused by this bug. The problem seams to be the location of the field mapping for plausifehler in DM1Tewe. If the collection mapping for plausifehler is the first none identity field mapping you will get the Column Index out of range error. If you change sequence of the field mappings and put e.g. the one for arztnr first, there will be no error reported with your test case. Original mapping with error: <class name="jdo.bug1812.DM1Tewe" identity="barcode"> <map-to table="bug1812_tewe" xml="" /> <cache-type type="none" /> <field name="plausifehler" type="jdo.bug1812.Plausifehler" lazy="true" collection="collection"> <sql many-key="barcode" read-only="true" dirty="ignore" /> </field> <field name="dmtyp1" type="java.lang.Boolean"> <sql name="dmtyp1" type="integer" /> </field> <field name="dmtyp2" type="java.lang.Boolean"> <sql name="dmtyp2" type="integer" /> </field> <field name="arztnr" type="java.lang.Long"> <sql name="arzt" type="bigint" /> </field> <field name="barcode" type="java.math.BigDecimal"> <sql name="barcode" type="decimal" /> </field> </class> Changed mapping without failure: <class name="jdo.bug1812.DM1Tewe" identity="barcode"> <map-to table="bug1812_tewe" xml="" /> <cache-type type="none" /> <field name="arztnr" type="java.lang.Long"> <sql name="arzt" type="bigint" /> </field> <field name="plausifehler" type="jdo.bug1812.Plausifehler" lazy="true" collection="collection"> <sql many-key="barcode" read-only="true" dirty="ignore" /> </field> <field name="dmtyp1" type="java.lang.Boolean"> <sql name="dmtyp1" type="integer" /> </field> <field name="dmtyp2" type="java.lang.Boolean"> <sql name="dmtyp2" type="integer" /> </field> <field name="barcode" type="java.math.BigDecimal"> <sql name="barcode" type="decimal" /> </field> </class> Having said that I wonder myself that this mapping works at all as there are 2 constructs that are not supported: 1. Castor does not support foreign keys being part of primary keys. At class Plausifehler you have declared barcode, fehlernr and vorgang as multiple column primary key, but barcode is also the foreign key to DM1Tewe class. 2. Normaly the foreign key column should have the type of the class it refers to. In class Plausifehler the field barcode is a foreign key to DM1Tewe class. Normaly the mapping of barcode field in Plausifehler class should look like: <field name="barcode" type="jdo.bug1812.DM1Tewe"> <sql name="barcode"/> </field> While the combination of this 2 mapping failures seam to cause no problems with this test case I would wonder if it will work under all situations. And if it does with current release this may change in the futur as this is not intended.
Hide
Permalink
Ralf Joachim added a comment -

Igarki, reviewing your mapping it seams you are using the same construct (collection field is first none identity field) at following classes:

  • CurrentOntologies
  • OntologyLibrary
  • CurrentKBs
  • KnowledgeBaseLibrary
  • OntologyRelationList
  • KnowledgeBase
  • RelationList
Show
Ralf Joachim added a comment - Igarki, reviewing your mapping it seams you are using the same construct (collection field is first none identity field) at following classes:
  • CurrentOntologies
  • OntologyLibrary
  • CurrentKBs
  • KnowledgeBaseLibrary
  • OntologyRelationList
  • KnowledgeBase
  • RelationList
Hide
Permalink
Ralf Joachim added a comment -

Patch including 3 test cases.

1. package jdo.bug1812a contains test from Igarki. Having said that this one is quite complicated and I did not get it to work.

2. package jdo.bug1812b contains the original test case from azgard.

3. package jdo.bug1812c contains the testcase from azgard simplified as much as possible to reproduce the problem. With the current mapping you will get the failure: Column Index out of range, 4 > 3. If you exchange the field mappings of 'entities' and 'number' of Entity1 the failure will disapear.

If you comment line 339 of SQLStatementLoad the problem will also disapear but then our test suite will fail. My wild guess is that the if condition around that line is wrong or does not cover all situations.

Show
Ralf Joachim added a comment - Patch including 3 test cases. 1. package jdo.bug1812a contains test from Igarki. Having said that this one is quite complicated and I did not get it to work. 2. package jdo.bug1812b contains the original test case from azgard. 3. package jdo.bug1812c contains the testcase from azgard simplified as much as possible to reproduce the problem. With the current mapping you will get the failure: Column Index out of range, 4 > 3. If you exchange the field mappings of 'entities' and 'number' of Entity1 the failure will disapear. If you comment line 339 of SQLStatementLoad the problem will also disapear but then our test suite will fail. My wild guess is that the if condition around that line is wrong or does not cover all situations.
Hide
Permalink
Steven Dolg added a comment -

I have been able to create a patch that fixes the test cases 2 and 3.
Test case 1 fails for some reason - but I do not believe this is because of the issue itself. My assumption is that this test case needs some prerequisites I do not know.

However the JDO test suite still finished without errors/failures when I used it with MySQL.

Show
Steven Dolg added a comment - I have been able to create a patch that fixes the test cases 2 and 3. Test case 1 fails for some reason - but I do not believe this is because of the issue itself. My assumption is that this test case needs some prerequisites I do not know. However the JDO test suite still finished without errors/failures when I used it with MySQL.
Hide
Permalink
Werner Guttmann added a comment -

Steven, what mySQL and JDBC driver versions are you actually using ?

Show
Werner Guttmann added a comment - Steven, what mySQL and JDBC driver versions are you actually using ?
Hide
Permalink
Steven Dolg added a comment -

I'm using MySQL 4.1.11.
For the JDBC Driver both 3.1.12 and 5.0.4 worked without any problems...

Show
Steven Dolg added a comment - I'm using MySQL 4.1.11. For the JDBC Driver both 3.1.12 and 5.0.4 worked without any problems...
Hide
Permalink
Ralf Joachim added a comment -

As far as I understand the problem it isn't specific to a database system or version. I'll start review now and integrate 3. test case into ctf.

Show
Ralf Joachim added a comment - As far as I understand the problem it isn't specific to a database system or version. I'll start review now and integrate 3. test case into ctf.
Hide
Permalink
Ralf Joachim added a comment -

Very good work Steven.

Show
Ralf Joachim added a comment - Very good work Steven.
Hide
Permalink
Ralf Joachim added a comment -

Final patch including test case.

Show
Ralf Joachim added a comment - Final patch including test case.

People

Vote (1)
Watch (1)

Dates

  • Created:
    Updated:
    Resolved:
Atlassian JIRA (v4.4.3#663-r165197) | Report a problem
Powered by a free Atlassian JIRA open source license for Codehaus. Try JIRA - bug tracking software for your team.