[
https://issues.apache.org/jira/browse/OLINGO-45?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13807740#comment-13807740
]
Georgi commented on OLINGO-45:
------------------------------
As far as I can judge the problem occurs when trying to set a relation to an
Entity with multiplicity 1.
Here's the sample POST request (I'm using X-HTTP-METHOD to tunnel non standard
merge):
curl "<path>/Services(7)" -H "Origin: http://localhost:8080"; -H
"Accept-Encoding: gzip,deflate,sdch" -H "Accept-Language: en-US,en;q=0.8" -H
"Connection: keep-alive" -H "Pragma: no-cache" -H "MaxDataServiceVersion: 2.0"
-H "Host: localhost:8080" -H "X-HTTP-METHOD: MERGE" -H "User-Agent: Mozilla/5.0
(Windows NT 6.1; WOW64) AppleWebKit/537.35 (KHTML, like Gecko)
Chrome/27.0.1448.0 Safari/537.35" -H "Content-Type:
application/json;odata=verbose" -H "Accept: application/atomsvc+xml;q=0.8,
application/json;odata=verbose;q=0.5, */*;q=0.1" -H "Cache-Control: no-cache"
-H "Referer: <path>" -H "DataServiceVersion: 2.0" -H "DNT: 1" --data-binary
"{\"serviceId\":7,\"member\":{\"__metadata\":{\"uri\":\"Members(6)\"}}}"
Here, the entities are Service and Member. A Member has 0..* 'services' and a
Service has 1 Member, bound by the property 'member'. The serviceId property is
the key of the Service entity.
In terms of JPA, the Service class declares:
@ManyToOne(cascade = CascadeType.ALL, fetch=FetchType.EAGER)
@JoinColumn(name = "MEMBER_ID", referencedColumnName = "MEMBER_ID")
private Member member;
So for the navigation property member, the switch edmTyped.getType().getKind()
passes through NAVIGATION and ends in the ENTITY case, with the structural type
<schemaname>.Member, correct modifier - setMember and entity set Members.
However, oDataEntryProperties map has the following entries:
{member=ODataEntryImpl [data={}, entryMetadata=EntryMetadataImpl [id=null,
etag=null, uri=Members(6), associationUris={}], mediaMetadata=MediaMetadataImpl
[sourceLink=null, etag=null, contentType=null, editLink=null],
expandSelectTree=org.apache.olingo.odata2.core.uri.ExpandSelectTreeNodeImpl@52c43db8,
containsInlineEntry=false], serviceId=7}
, and when oDataEntryProperties.get(propertyName) is invoked with propertyName
"member", we get the ODataEntryImpl entry instead of the expected by the code
List<ODataEntry>.
As for how come I need such an update: I'm using JayData as OData client
library and its NoBatch plugin due to the lack of support for $batch. JayData
sends an update through the dependency relations as soon as some node changes.
NoBatch takes care to split these into separate ordered requests. What I did
was an update of a property of the Member entity and that lead to update to all
downstream, related entities like Service.
> ClassCastException on Entity update
> -----------------------------------
>
> Key: OLINGO-45
> URL: https://issues.apache.org/jira/browse/OLINGO-45
> Project: Olingo
> Issue Type: Bug
> Components: odata2-jpa
> Affects Versions: 1.0.0, 1.1.0
> Reporter: Georgi
> Assignee: Chandan V.A
>
> You might want to doublecheck the logic in
> org.apache.olingo.odata2.processor.core.jpa.access.data.JPAEntity:write(final
> Map<String, Object> oDataEntryProperties, final boolean isCreate)
> On line 141 there's an explicit cast to List<ODataEntry>. However I found out
> that during update, when the property is a 1:1..0 relation to another Entity,
> the returned type is ODataEntry. And that causes the ClassCastException.
> I managed to solve this for me with a simple if/else block:
> List<ODataEntry> relatedEntries = null;
> if(oDataEntryProperties.get(propertyName) instanceof ODataEntry){
> relatedEntries = new ArrayList<ODataEntry>();
>
> relatedEntries.add((ODataEntry)oDataEntryProperties.get(propertyName));
> } else {
> relatedEntries =
> (List<ODataEntry>)oDataEntryProperties.get(propertyName);
> }
> The code is from the 1.1.0-SNAPSHOT master branch HEAD.
> I hope that helps.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
