[
https://issues.apache.org/jira/browse/OPENJPA-1199?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12748615#action_12748615
]
Pinaki Poddar commented on OPENJPA-1199:
----------------------------------------
The key type you are seeing as Long because of the following @MapKey annotation
you used in mapping Exam.parts
@OneToMany(cascade = { CascadeType.MERGE, CascadeType.PERSIST,
CascadeType.REFRESH })
@MapKey(name = "id")
private SortedMap<Integer, Part> parts = new TreeMap<Integer, Part>();
The annotation tells that parts is stored as a Map whose keys are formed by
"id" field of its value (which is a Part object). Now Part object has an "id"
field and is declared as Long.
That is why the map field Exam.parts has a Long key.
Actually because of the way this mapping is specified, the integer key 99 as
used in exam.addPart(99, part1) will be ignored.
If you remove the @MapKey annotation, then the behavior which I think you
intend (in terms of having your own Integer keys in Exam.parts map field) will
be realized.
> Mapping maps changes statically declared types during runtime without warning
> -----------------------------------------------------------------------------
>
> Key: OPENJPA-1199
> URL: https://issues.apache.org/jira/browse/OPENJPA-1199
> Project: OpenJPA
> Issue Type: Bug
> Affects Versions: 1.2.1
> Environment: Ubuntu 9.04 x86_64 /
> jdk-7-ea-bin-b62-linux-x64-25_jun_2009.bin
> Reporter: Daniel Kulesz
> Attachments: jpatest.zip
>
>
> When using map mapping in OpenJPA, statically declared types in Sets are
> changed to types of attributes they refer to in other Entities during runtime
> without warning. This can lead to (rather unexpected) Class cast exceptions.
> The attached (commented) example code demonstrates the problem.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.