Mailing-List: contact dev-help@openjpa.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@openjpa.apache.org
Message-ID: <74359584.263311268648007124.JavaMail.jira@brutus.apache.org>
Date: Mon, 15 Mar 2010 10:13:27 +0000 (UTC)
From: "Krzysztof (JIRA)" <jira@apache.org>
To: dev@openjpa.apache.org
Subject: [jira] Updated: (OPENJPA-1572) ApplicationIdTool generated ID
 classes do not cater for embedded composite IDs
In-Reply-To: <553342108.263291268647887164.JavaMail.jira@brutus.apache.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


     [ https://issues.apache.org/jira/browse/OPENJPA-1572?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Krzysztof updated OPENJPA-1572:
-------------------------------

    Description: 

Having ClassB identified by the composite identity of the classA which has a 'simple types' composite identity, i.e.:

class ClassA 
{ 
 @Id 
 int x; 
 @Id 
 int y; 

} 
class ClassB 
{ 
 @Id 
 ClassA cA; 
 @Id 
 int b; 
} 

Generated ClassBId.fromstring with ApplicationIdTool passes only part of the string representation of ClassA id to classA string constructor as nexttoken is not aware of the composition of the ID and always extracts a single token which will result in the null exception.

CLassBId { 
... 
        private void fromString(String str) { 
            Tokenizer toke = new Tokenizer(str); 
            str = toke.nextToken(); 
            if ("null".equals(str)) 
                b = null; 
            else 
                b = str; 
            str = toke.nextToken(); 
            if ("null".equals(str)) 
                cA = null; 
            else 
                cA = new classA.classAId(str); 
        } 
so, obviously for classB with a string representation like 0::1::2 only "1" is passed to the constructor using ClassA.toString which results in wrong initialization. 
I have not been using detachement/attachment and have been wondering if this inconsistency may have other impact during an object lifecycle. 

The solution would be to pass full remaining part of the string and return the last position for subsequent tokens extraction somehow. 
Not sure about priority, so setting to Major as a simple unit test would fail on toString/fromString combo.

  was:

Having ClassB identified by the composite identity of the classA which has a 'simple types' composite identity, i.e.:

class ClassA 
{ 
 @Id 
 int x; 
 @Id 
 int y; 

} 
class ClassB 
{ 
 @Id 
 ClassA cA; 
 @Id 
 int b; 
} 

Generated ClassBId.fromstring  passes only part of the string representation of ClassA id to classA string constructor as nexttoken is not aware of the composition of the ID and always extracts a single token which will result in the null exception.

CLassBId { 
... 
        private void fromString(String str) { 
            Tokenizer toke = new Tokenizer(str); 
            str = toke.nextToken(); 
            if ("null".equals(str)) 
                b = null; 
            else 
                b = str; 
            str = toke.nextToken(); 
            if ("null".equals(str)) 
                cA = null; 
            else 
                cA = new classA.classAId(str); 
        } 
so, obviously for classB with a string representation like 0::1::2 only "1" is passed to the constructor using ClassA.toString which results in wrong initialization. 
I have not been using detachement/attachment and have been wondering if this inconsistency may have other impact during an object lifecycle. 

The solution would be to pass full remaining part of the string and return the last position for subsequent tokens extraction somehow. 


> ApplicationIdTool generated ID classes do not cater for embedded composite IDs
> ------------------------------------------------------------------------------
>
>                 Key: OPENJPA-1572
>                 URL: https://issues.apache.org/jira/browse/OPENJPA-1572
>             Project: OpenJPA
>          Issue Type: Bug
>          Components: tooling
>    Affects Versions: 2.0.0-beta2
>            Reporter: Krzysztof
>
> Having ClassB identified by the composite identity of the classA which has a 'simple types' composite identity, i.e.:
> class ClassA 
> { 
>  @Id 
>  int x; 
>  @Id 
>  int y; 
> } 
> class ClassB 
> { 
>  @Id 
>  ClassA cA; 
>  @Id 
>  int b; 
> } 
> Generated ClassBId.fromstring with ApplicationIdTool passes only part of the string representation of ClassA id to classA string constructor as nexttoken is not aware of the composition of the ID and always extracts a single token which will result in the null exception.
> CLassBId { 
> ... 
>         private void fromString(String str) { 
>             Tokenizer toke = new Tokenizer(str); 
>             str = toke.nextToken(); 
>             if ("null".equals(str)) 
>                 b = null; 
>             else 
>                 b = str; 
>             str = toke.nextToken(); 
>             if ("null".equals(str)) 
>                 cA = null; 
>             else 
>                 cA = new classA.classAId(str); 
>         } 
> so, obviously for classB with a string representation like 0::1::2 only "1" is passed to the constructor using ClassA.toString which results in wrong initialization. 
> I have not been using detachement/attachment and have been wondering if this inconsistency may have other impact during an object lifecycle. 
> The solution would be to pass full remaining part of the string and return the last position for subsequent tokens extraction somehow. 
> Not sure about priority, so setting to Major as a simple unit test would fail on toString/fromString combo.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.