[
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.
