How to update a WCF OData service-based entity without System.DateTime format exception?

[Izochrone]

Hi,

I just started to use odata4j on Android, and I managed to read data from a WCF-based Odata data source.

I'd like to change one of the entity's single String property, but I (surprisingly) get a message about this:

"Caused by: org.odata4j.exceptions.BadRequestException: Error processing request stream. Error encountered in converting the value from request payload for property 'BDate' to type 'System.DateTime', which is the property's expected type. See inner exception for more detail.'"

  ODataConsumer c = ODataJerseyConsumer.newBuilder(ListActivity.url)
.setFormatType(FormatType.ATOM).build();
ODataJerseyConsumer.dump.all(true);
  OEntity ent = c.getEntity(entitySetName, localObject.ID).execute();
System.out.println("Actual key - " + ent.getEntityKey());
System.out
  .println("objType - " + ent.getProperty("BDate").getClass());
System.out
  .println("objValue - " + ent.getProperty("BDate").getValue());
c.updateEntity(ent)
  .properties(OProperties.string("Name", localObject.Name + "2")).execute();

The object class for the problematic DateTime object is org.odata4j.core.OProperties$Impl, and it's value: 1994-11-03T00:00:00.000

I don't understand why it tries to update that value (I just want to update the Name), too, and if does, why throws exception (I simply try to put back the object I just read from the data source).

Can you help me?

[John Spurlock]

More interesting would be to look at the property's edm type.  ent.getProperty("BDate").getType()

I suspect you are trying to update a datetime property with a string value.  Use OProperties.datetime to create Edm.DateTime property values.  OProperties.string will create property values of type Edm.String

[Izochrone]

The Type is :  EdmSimpleType[Edm.DateTime]

What is it supposed to be? And why does it want to update that field, too?

[John Spurlock]

updateEntity updates all properties.  mergeEntity updates individual properties.  

Can you set ODataConsumer.dump.all(true) before running this, then send me the request/response trail?

Also which version of odata4j are you using?

[Izochrone]

I'm using odata4j 0.7.0.

I tried to use mergeEntity, and it was working :)

I am glad, you replied so soon, it is appreciated.

I didn't know, that updateEntity updates each property but it is still strange that unchanged properties can't be saved.

My project does this:

Reads from the server (WCF Odata source)

Displays the list of the result

Lets pick anyone from the list, show some of its details (no all, it has over 50 properties)

The changed values should be stored (I am thinking to store it on the phone first then do a mass-save - it is not implemented yet)

Saves the changed values back to server 

Do you still need the save's response trail?

[John Spurlock]

Yes I'd like to track down the cause of the updateEntity problem.  As you say, that should work just as well.

That error is coming from the WCF server, if you wouldn't mind sending me the request/response trace from the updateEntity scenario, it would help us debug to see if it's something we have to workaround or is a bug on our end.

[Izochrone]

Yes, I send it, but only for you, as it contains sensitive data (I changed them but doesn't want to send it publicly)

There is a bonus question :)

The main table has a side table and they are connected via a connector table (their PKs are stored there). Is it possible to load the side table's data when I read the main data (unfortunately there are no FKs)?

[John Spurlock]

If the relationship is defined in the model, you can use $expand (OQueryRequest#expand in the odata4j consumer api).

[John Spurlock]

GET response: <d:DateProp m:type="Edm.DateTime">1994-11-03T00:00:00</d:DateProp>

Internal representation: 1994-11-03T00:00:00.000

PUT request <d:DateProp m:type="Edm.DateTime">1994-11-03T00:00</d:DateProp>    <-- note the lack of seconds

The PUT request value is valid according to the spec [1].  The server should accept it.  Which version of WCF is providing the server implementation?

[1] http://www.odata.org/media/30002/OData%20Atom%20Format.html#primitivetypesinatom

On Sun, Nov 11, 2012 at 9:51 AM, Izochrone <izoc...@gmail.com> wrote:

[Izochrone]

I can't access the server directly, so I just assume it uses either .Net 4.0 or .Net 4.5.

Does it help?

[John Spurlock]

I was able to repro using WCF DS 5.1.0 locally.  Looks like this a bug in all versions of WCF DS - we may need to provide a workaround in odata4j.

See: http://social.msdn.microsoft.com/Forums/en/adodotnetdataservices/thread/3fb03949-1828-476b-b7dd-6d0dbfa5e9ac

[Izochrone]

I don't know if Microsoft is aware of that problem. Probably it'd be wise to let them know :)

[John Spurlock]

Did you happen to notice the last comment on that product forum thread?

[Izochrone]

I just did :)

I hope, they will fix this. 

Thanks for your work, it helped me a lot.

[John Spurlock]

No problem, thanks for reporting it - as it sounds like we'll need to take some action on the odata4j side in the meantime.

[Philipp Sebastian Thun]

I agree; we should introduce some kind of workaround for odata4j. But I do not think that it would be a good idea to simply remove the stripping of zeros for all use cases as the same code is shared for the server part as well and I actually would like to keep the odata4j producer side to be compliant to the specification. Any ideas for a workaround?

[John Spurlock]

Philipp, can you give a pointer to the spec where it says zeros should be stripped?

[Philipp Sebastian Thun]

The OData specification (V2) defines "Common Serialization Rules for XML-Based Formats" (section 2.2.6.1). For Edm.DateTime there is a reference to another section: "See dateTimeLiteral in the Literal Form of Entity Data Model Primitive Types table in Abstract Type System (section 2.2.2)."

Section 2.2.2 (Abstract Type System) provides the following specification (as ABNF grammar rule): dateTimeLiteral = year "-" month "-" day "T" hour ":" minute [":" second ["." nanoSeconds]]

[John Spurlock]

Right, so we're technically valid - but is there a place that recommends stripping off zero values?  In my opinion, the ABNF alone does not constitute a recommendation to do this.

If not, we may need to at least keep the seconds place to be compatible with WCF DS.

This is important, as it breaks a very simple consumer scenario (update an entity just retrieved that happens to have a datetime property).  We should consider cherry-picking a fix branching off 0.7 for a 0.7.1 release.

[Philipp Sebastian Thun]

I did not find any recommendation on doing so. To not break this simple use case, we should proceed as you suggested.