You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@olingo.apache.org by Frédéric SOUCHU <Fr...@ingenico.com> on 2015/05/20 17:36:11 UTC
null values
The whole point of moving away from XML/SOAP is to be much more flexible in term of data contract.
Odata does (or should) provide the best of both worlds:
- Metadata for contract freaks
- JSON for easy integration with 'modern' tools
Is there anything in the specs that say null values must be produced?
For sparse tables/large tables, that's also bandwidth used for nothing.
If the standard is not explicit about it, I'll create a story.
Regards,
Frederic
From: Amend, Christian [mailto:christian.amend@sap.com]
Sent: 20 May 2015 16:21
To: user@olingo.apache.org
Subject: RE: DateTimeOffset in Olingo
Hi,
for your previous issue please refer to my last mail. Any feedback on how you see this would be appreciated.
As for hiding null properties: The specification does not talk about a feature like that so we did not implement this. I also don`t know if it would be wise to exclude null properties when sending a response from the server to a generic client as the client then would not know about the properties at all if it doesn`t have access to the metadata. For custom clients which know the metadata this might be another story. There you could open a feature request in our JIRA.
Technically you can achieve this behavior by specifying a selected list of properties at the SerializerOptions you pass to the entity serializer. This might not be convenient as of now but it would achieve the required effect.
Best Regards,
Christian
From: Anil G [mailto:gvnanils@gmail.com]
Sent: Mittwoch, 20. Mai 2015 16:11
To: user@olingo.apache.org<ma...@olingo.apache.org>
Subject: Re: DateTimeOffset in Olingo
Agreed :)
On a side note, do you know how I can hide "null" values/make serializer ignore nulls in my json response. Nullable = true is not helping. The response json is full of 'null' values which could be simply hidden!
On Wed, May 20, 2015 at 7:35 PM, Frédéric SOUCHU <Fr...@ingenico.com>> wrote:
Same question and findings I got a couple of month ago – see:
http://mail-archives.apache.org/mod_mbox/olingo-user/201503.mbox/%3C4C79C9168A5B9543AA23E3C669025A625035A38B@COSNADEXC13.usr.ingenico.loc%3E
It should be filled as a bug IMHO.
From: Anil G [mailto:gvnanils@gmail.com<ma...@gmail.com>]
Sent: 20 May 2015 15:53
To: user@olingo.apache.org<ma...@olingo.apache.org>
Subject: Re: DateTimeOffset in Olingo
Thanks Fred.
Spec says that is optional. So it should work even if I do not define Precision. But it fails. The below code in EdmDateTimeOffset class throws the exception. Even if I had defined a precision of 2, it failed because the digits value came out as 3 for my data set (probably because I am debugging?)
But why throw IllegalArgumentException when Precision < digits?
/* 257 */ int digits = milliseconds % 10 == 0 ? 2 : milliseconds % 100 == 0 ? 1 : milliseconds % 1000 == 0 ? 0 : 3;
/* 258 */ if (digits > 0) {
/* 259 */ if ((precision == null) || (precision.intValue() < digits)) {
/* 260 */ throw new IllegalArgumentException();
/* */ }
On Wed, May 20, 2015 at 7:18 PM, Frédéric SOUCHU <Fr...@ingenico.com>> wrote:
Correct, it must be defined in the EDM.
From: Anil G [mailto:gvnanils@gmail.com<ma...@gmail.com>]
Sent: 20 May 2015 15:41
To: user@olingo.apache.org<ma...@olingo.apache.org>
Subject: Re: DateTimeOffset in Olingo
as i debug the code, it looks like the precision is mandatory and probably comes from metadata!
will come back with my findings.
On Wed, May 20, 2015 at 6:52 PM, Anil G <gv...@gmail.com>> wrote:
Hi Frederic,
Thanks for a quick response.
I don't see a setPrecision() method in Property class? I am using Beta03 in OData V4.
On Wed, May 20, 2015 at 6:45 PM, Frédéric SOUCHU <Fr...@ingenico.com>> wrote:
You need to specify a 'precision', ex:
new Property()
.setName("OrderDate") // any datetime/timestamp field
.setType(EdmPrimitiveTypeKind.DateTimeOffset.getFullQualifiedName())
.setPrecision(2)
It should really be optional (as per OData spec)…
Frederic
From: Anil G [mailto:gvnanils@gmail.com<ma...@gmail.com>]
Sent: 20 May 2015 15:10
To: user@olingo.apache.org<ma...@olingo.apache.org>
Subject: DateTimeOffset in Olingo
Hi,
I have a DateTimeOffset property defined for my type. But when I am serializing data, it fails with the following Error Message
• message: "Wrong value for property!"
I tried writing data in string (ISO 8601 format), date, calendar but all fails.
Is this a bug or am I doing something wrong? I saw the source code but could not find any serialization logic for Date/Time fields.
Thanks & Regards
Anil
RE: null values
Posted by "Amend, Christian" <ch...@sap.com>.
Hi Alex,
nice to hear you are using the android OData client ☺
If you find any bugs please open a JIRA ticket here: https://issues.apache.org/jira/browse/OLINGO/?selectedTab=com.atlassian.jira.jira-projects-plugin:summary-panel
We are currently focusing on the server side implementation but any input on features or bugs from outside the core team is highly appreciated.
Of course if you find the time and can contribute a patch for a Bugfix we would be very thankful and it would speed up the time until you can consume a better released version of the Olingo client.
Thanks & Best Regards,
Christian
From: Alex Maiereanu [mailto:alex.maiereanu@3sstudio.com]
Sent: Donnerstag, 21. Mai 2015 15:05
To: user@olingo.apache.org
Subject: Re: null values
In my company, we are using olingo java for an android app. I don't think that odata is not suitable for mobile apps, but the olingo client, together with the proxy classes, still have a long road ahead. There are still a lot of bugs
Salutari din Brasov / Greetings from Brasov
[Image removed by sender.]
Alex-Paul Maiereanu
+40 761 684 212
www.3sstudio.com<http://www.3sstudio.com/>
[Image removed by sender.]Facebook<https://www.facebook.com/smartsocialsoftware> [Image removed by sender.] Twitter<https://twitter.com/SmartSocialSoft> [Image removed by sender.] Google+<https://plus.google.com/101299629750815349588/posts>
On Thu, May 21, 2015 at 3:59 PM, Amend, Christian <ch...@sap.com>> wrote:
Hi Anil and Frédéric,
I did not say that the idea of leaving null values is bad. Quite the contrary I like the idea a lot.
The reason we do not have this is that we did not have this requirement on our radar and it is not explicitly stated within the specification as far as I know. So we could implement a flag for the serializer to omit null values. But maybe the specification could introduce an OData prefer header which indicates that this behavior was used to construct the payload. WDYT?
@Anil: Do you know why there is the opinion that OData should not be used for mobile apps? Maybe this is feedback the OASIS OData community is not aware of and thus could not react.
Best Regards,
Christian
From: Anil G [mailto:gvnanils@gmail.com<ma...@gmail.com>]
Sent: Mittwoch, 20. Mai 2015 18:44
To: user@olingo.apache.org<ma...@olingo.apache.org>
Subject: Re: null values
I have heard experts saying OData is NO NO for Mobile apps, an idea which I did not appreciate much. But filling "null"s in responses for nothing will only make them right.
Christian, specifying the excludable properties doesn't help much because in an entity collection response, different instances can have different null properties.
I have been promoting v4 in our company because OData V4 is presumably light weight because of better json format (compared to v2/v3).
But I can't buy "null" properties being there for nothing. And I can't sell v4 if that's what spec says.
IMHO "null"s should be shown only if client asks for it. Not by default.
Thanks & Regards
Anil
On Wed, May 20, 2015 at 9:06 PM, Frédéric SOUCHU <Fr...@ingenico.com>> wrote:
The whole point of moving away from XML/SOAP is to be much more flexible in term of data contract.
Odata does (or should) provide the best of both worlds:
- Metadata for contract freaks
- JSON for easy integration with 'modern' tools
Is there anything in the specs that say null values must be produced?
For sparse tables/large tables, that's also bandwidth used for nothing.
If the standard is not explicit about it, I'll create a story.
Regards,
Frederic
From: Amend, Christian [mailto:christian.amend@sap.com<ma...@sap.com>]
Sent: 20 May 2015 16:21
To: user@olingo.apache.org<ma...@olingo.apache.org>
Subject: RE: DateTimeOffset in Olingo
Hi,
for your previous issue please refer to my last mail. Any feedback on how you see this would be appreciated.
As for hiding null properties: The specification does not talk about a feature like that so we did not implement this. I also don`t know if it would be wise to exclude null properties when sending a response from the server to a generic client as the client then would not know about the properties at all if it doesn`t have access to the metadata. For custom clients which know the metadata this might be another story. There you could open a feature request in our JIRA.
Technically you can achieve this behavior by specifying a selected list of properties at the SerializerOptions you pass to the entity serializer. This might not be convenient as of now but it would achieve the required effect.
Best Regards,
Christian
From: Anil G [mailto:gvnanils@gmail.com]
Sent: Mittwoch, 20. Mai 2015 16:11
To: user@olingo.apache.org<ma...@olingo.apache.org>
Subject: Re: DateTimeOffset in Olingo
Agreed :)
On a side note, do you know how I can hide "null" values/make serializer ignore nulls in my json response. Nullable = true is not helping. The response json is full of 'null' values which could be simply hidden!
On Wed, May 20, 2015 at 7:35 PM, Frédéric SOUCHU <Fr...@ingenico.com>> wrote:
Same question and findings I got a couple of month ago – see:
http://mail-archives.apache.org/mod_mbox/olingo-user/201503.mbox/%3C4C79C9168A5B9543AA23E3C669025A625035A38B@COSNADEXC13.usr.ingenico.loc%3E
It should be filled as a bug IMHO.
From: Anil G [mailto:gvnanils@gmail.com<ma...@gmail.com>]
Sent: 20 May 2015 15:53
To: user@olingo.apache.org<ma...@olingo.apache.org>
Subject: Re: DateTimeOffset in Olingo
Thanks Fred.
Spec says that is optional. So it should work even if I do not define Precision. But it fails. The below code in EdmDateTimeOffset class throws the exception. Even if I had defined a precision of 2, it failed because the digits value came out as 3 for my data set (probably because I am debugging?)
But why throw IllegalArgumentException when Precision < digits?
/* 257 */ int digits = milliseconds % 10 == 0 ? 2 : milliseconds % 100 == 0 ? 1 : milliseconds % 1000 == 0 ? 0 : 3;
/* 258 */ if (digits > 0) {
/* 259 */ if ((precision == null) || (precision.intValue() < digits)) {
/* 260 */ throw new IllegalArgumentException();
/* */ }
On Wed, May 20, 2015 at 7:18 PM, Frédéric SOUCHU <Fr...@ingenico.com>> wrote:
Correct, it must be defined in the EDM.
From: Anil G [mailto:gvnanils@gmail.com<ma...@gmail.com>]
Sent: 20 May 2015 15:41
To: user@olingo.apache.org<ma...@olingo.apache.org>
Subject: Re: DateTimeOffset in Olingo
as i debug the code, it looks like the precision is mandatory and probably comes from metadata!
will come back with my findings.
On Wed, May 20, 2015 at 6:52 PM, Anil G <gv...@gmail.com>> wrote:
Hi Frederic,
Thanks for a quick response.
I don't see a setPrecision() method in Property class? I am using Beta03 in OData V4.
On Wed, May 20, 2015 at 6:45 PM, Frédéric SOUCHU <Fr...@ingenico.com>> wrote:
You need to specify a 'precision', ex:
new Property()
.setName("OrderDate") // any datetime/timestamp field
.setType(EdmPrimitiveTypeKind.DateTimeOffset.getFullQualifiedName())
.setPrecision(2)
It should really be optional (as per OData spec)…
Frederic
From: Anil G [mailto:gvnanils@gmail.com<ma...@gmail.com>]
Sent: 20 May 2015 15:10
To: user@olingo.apache.org<ma...@olingo.apache.org>
Subject: DateTimeOffset in Olingo
Hi,
I have a DateTimeOffset property defined for my type. But when I am serializing data, it fails with the following Error Message
• message: "Wrong value for property!"
I tried writing data in string (ISO 8601 format), date, calendar but all fails.
Is this a bug or am I doing something wrong? I saw the source code but could not find any serialization logic for Date/Time fields.
Thanks & Regards
Anil
RE: null values
Posted by "Handl, Ralf" <ra...@sap.com>.
I’ve created issue https://issues.oasis-open.org/browse/ODATA-818 to keep track of this.
Thanks for addressing this!
--Ralf
From: Anil G [mailto:gvnanils@gmail.com]
Sent: Montag, 25. Mai 2015 08:16
To: user@olingo.apache.org
Subject: Re: null values
@Christian,
would like to know your comments on the above. :)
On Thu, May 21, 2015 at 11:02 PM, Anil G <gv...@gmail.com>> wrote:
@Christian,
Below are some of the arguments I have heard and my analysis on their views. Note that I don't share the same views as them :)
1. My mobile service doesn't have a strict $metadata or its dynamic and change anytime.
2. Many people still presume that OData responses are very verbose. (Unaware of refinements in V4)
3. Simple REST APIs are easy to consume from mobile apps rather than understanding and adhering to OData.
On Thu, May 21, 2015 at 6:35 PM, Alex Maiereanu <al...@3sstudio.com>> wrote:
In my company, we are using olingo java for an android app. I don't think that odata is not suitable for mobile apps, but the olingo client, together with the proxy classes, still have a long road ahead. There are still a lot of bugs
Salutari din Brasov / Greetings from Brasov
[http://www.3sstudio.com/email-signatures/email-signature-icon.png]
Alex-Paul Maiereanu
+40 761 684 212
www.3sstudio.com<http://www.3sstudio.com/>
[http://www.3sstudio.com/email-signatures/email-signature-facebook.png]Facebook<https://www.facebook.com/smartsocialsoftware> [http://www.3sstudio.com/email-signatures/email-signature-twitter.png] Twitter<https://twitter.com/SmartSocialSoft> [http://www.3sstudio.com/email-signatures/email-signature-google.png] Google+<https://plus.google.com/101299629750815349588/posts>
On Thu, May 21, 2015 at 3:59 PM, Amend, Christian <ch...@sap.com>> wrote:
Hi Anil and Frédéric,
I did not say that the idea of leaving null values is bad. Quite the contrary I like the idea a lot.
The reason we do not have this is that we did not have this requirement on our radar and it is not explicitly stated within the specification as far as I know. So we could implement a flag for the serializer to omit null values. But maybe the specification could introduce an OData prefer header which indicates that this behavior was used to construct the payload. WDYT?
@Anil: Do you know why there is the opinion that OData should not be used for mobile apps? Maybe this is feedback the OASIS OData community is not aware of and thus could not react.
Best Regards,
Christian
From: Anil G [mailto:gvnanils@gmail.com<ma...@gmail.com>]
Sent: Mittwoch, 20. Mai 2015 18:44
To: user@olingo.apache.org<ma...@olingo.apache.org>
Subject: Re: null values
I have heard experts saying OData is NO NO for Mobile apps, an idea which I did not appreciate much. But filling "null"s in responses for nothing will only make them right.
Christian, specifying the excludable properties doesn't help much because in an entity collection response, different instances can have different null properties.
I have been promoting v4 in our company because OData V4 is presumably light weight because of better json format (compared to v2/v3).
But I can't buy "null" properties being there for nothing. And I can't sell v4 if that's what spec says.
IMHO "null"s should be shown only if client asks for it. Not by default.
Thanks & Regards
Anil
On Wed, May 20, 2015 at 9:06 PM, Frédéric SOUCHU <Fr...@ingenico.com>> wrote:
The whole point of moving away from XML/SOAP is to be much more flexible in term of data contract.
Odata does (or should) provide the best of both worlds:
- Metadata for contract freaks
- JSON for easy integration with 'modern' tools
Is there anything in the specs that say null values must be produced?
For sparse tables/large tables, that's also bandwidth used for nothing.
If the standard is not explicit about it, I'll create a story.
Regards,
Frederic
From: Amend, Christian [mailto:christian.amend@sap.com<ma...@sap.com>]
Sent: 20 May 2015 16:21
To: user@olingo.apache.org<ma...@olingo.apache.org>
Subject: RE: DateTimeOffset in Olingo
Hi,
for your previous issue please refer to my last mail. Any feedback on how you see this would be appreciated.
As for hiding null properties: The specification does not talk about a feature like that so we did not implement this. I also don`t know if it would be wise to exclude null properties when sending a response from the server to a generic client as the client then would not know about the properties at all if it doesn`t have access to the metadata. For custom clients which know the metadata this might be another story. There you could open a feature request in our JIRA.
Technically you can achieve this behavior by specifying a selected list of properties at the SerializerOptions you pass to the entity serializer. This might not be convenient as of now but it would achieve the required effect.
Best Regards,
Christian
From: Anil G [mailto:gvnanils@gmail.com]
Sent: Mittwoch, 20. Mai 2015 16:11
To: user@olingo.apache.org<ma...@olingo.apache.org>
Subject: Re: DateTimeOffset in Olingo
Agreed :)
On a side note, do you know how I can hide "null" values/make serializer ignore nulls in my json response. Nullable = true is not helping. The response json is full of 'null' values which could be simply hidden!
On Wed, May 20, 2015 at 7:35 PM, Frédéric SOUCHU <Fr...@ingenico.com>> wrote:
Same question and findings I got a couple of month ago – see:
http://mail-archives.apache.org/mod_mbox/olingo-user/201503.mbox/%3C4C79C9168A5B9543AA23E3C669025A625035A38B@COSNADEXC13.usr.ingenico.loc%3E
It should be filled as a bug IMHO.
From: Anil G [mailto:gvnanils@gmail.com<ma...@gmail.com>]
Sent: 20 May 2015 15:53
To: user@olingo.apache.org<ma...@olingo.apache.org>
Subject: Re: DateTimeOffset in Olingo
Thanks Fred.
Spec says that is optional. So it should work even if I do not define Precision. But it fails. The below code in EdmDateTimeOffset class throws the exception. Even if I had defined a precision of 2, it failed because the digits value came out as 3 for my data set (probably because I am debugging?)
But why throw IllegalArgumentException when Precision < digits?
/* 257 */ int digits = milliseconds % 10 == 0 ? 2 : milliseconds % 100 == 0 ? 1 : milliseconds % 1000 == 0 ? 0 : 3;
/* 258 */ if (digits > 0) {
/* 259 */ if ((precision == null) || (precision.intValue() < digits)) {
/* 260 */ throw new IllegalArgumentException();
/* */ }
On Wed, May 20, 2015 at 7:18 PM, Frédéric SOUCHU <Fr...@ingenico.com>> wrote:
Correct, it must be defined in the EDM.
From: Anil G [mailto:gvnanils@gmail.com<ma...@gmail.com>]
Sent: 20 May 2015 15:41
To: user@olingo.apache.org<ma...@olingo.apache.org>
Subject: Re: DateTimeOffset in Olingo
as i debug the code, it looks like the precision is mandatory and probably comes from metadata!
will come back with my findings.
On Wed, May 20, 2015 at 6:52 PM, Anil G <gv...@gmail.com>> wrote:
Hi Frederic,
Thanks for a quick response.
I don't see a setPrecision() method in Property class? I am using Beta03 in OData V4.
On Wed, May 20, 2015 at 6:45 PM, Frédéric SOUCHU <Fr...@ingenico.com>> wrote:
You need to specify a 'precision', ex:
new Property()
.setName("OrderDate") // any datetime/timestamp field
.setType(EdmPrimitiveTypeKind.DateTimeOffset.getFullQualifiedName())
.setPrecision(2)
It should really be optional (as per OData spec)…
Frederic
From: Anil G [mailto:gvnanils@gmail.com<ma...@gmail.com>]
Sent: 20 May 2015 15:10
To: user@olingo.apache.org<ma...@olingo.apache.org>
Subject: DateTimeOffset in Olingo
Hi,
I have a DateTimeOffset property defined for my type. But when I am serializing data, it fails with the following Error Message
• message: "Wrong value for property!"
I tried writing data in string (ISO 8601 format), date, calendar but all fails.
Is this a bug or am I doing something wrong? I saw the source code but could not find any serialization logic for Date/Time fields.
Thanks & Regards
Anil
RE: null values
Posted by "Amend, Christian" <ch...@sap.com>.
Hi Anil,
Sorry for my late reply. I think these are valid points. Yet in my opinion Odata should not be used for all use cases just because it is there. In some cases a dynamic metadata document with very small payloads can be easier achieved by using a custom rest based service.
OData in my opinion shines where you need a standardized way of accessing data. This could be the case if you don`t have access to the service and just want to consume it. Or if you can write a generic client which then can consume multiple services. This would not be possible in my opinion if there is no hard contract on which you can base your implementation.
So in my opinion both OData and custom rest services can be viable depending on your needs.
Best Regards,
Christian
From: Anil G [mailto:gvnanils@gmail.com]
Sent: Montag, 25. Mai 2015 08:16
To: user@olingo.apache.org
Subject: Re: null values
@Christian,
would like to know your comments on the above. :)
On Thu, May 21, 2015 at 11:02 PM, Anil G <gv...@gmail.com>> wrote:
@Christian,
Below are some of the arguments I have heard and my analysis on their views. Note that I don't share the same views as them :)
1. My mobile service doesn't have a strict $metadata or its dynamic and change anytime.
2. Many people still presume that OData responses are very verbose. (Unaware of refinements in V4)
3. Simple REST APIs are easy to consume from mobile apps rather than understanding and adhering to OData.
On Thu, May 21, 2015 at 6:35 PM, Alex Maiereanu <al...@3sstudio.com>> wrote:
In my company, we are using olingo java for an android app. I don't think that odata is not suitable for mobile apps, but the olingo client, together with the proxy classes, still have a long road ahead. There are still a lot of bugs
Salutari din Brasov / Greetings from Brasov
[Image removed by sender.]
Alex-Paul Maiereanu
+40 761 684 212
www.3sstudio.com<http://www.3sstudio.com/>
[Image removed by sender.]Facebook<https://www.facebook.com/smartsocialsoftware> [Image removed by sender.] Twitter<https://twitter.com/SmartSocialSoft> [Image removed by sender.] Google+<https://plus.google.com/101299629750815349588/posts>
On Thu, May 21, 2015 at 3:59 PM, Amend, Christian <ch...@sap.com>> wrote:
Hi Anil and Frédéric,
I did not say that the idea of leaving null values is bad. Quite the contrary I like the idea a lot.
The reason we do not have this is that we did not have this requirement on our radar and it is not explicitly stated within the specification as far as I know. So we could implement a flag for the serializer to omit null values. But maybe the specification could introduce an OData prefer header which indicates that this behavior was used to construct the payload. WDYT?
@Anil: Do you know why there is the opinion that OData should not be used for mobile apps? Maybe this is feedback the OASIS OData community is not aware of and thus could not react.
Best Regards,
Christian
From: Anil G [mailto:gvnanils@gmail.com<ma...@gmail.com>]
Sent: Mittwoch, 20. Mai 2015 18:44
To: user@olingo.apache.org<ma...@olingo.apache.org>
Subject: Re: null values
I have heard experts saying OData is NO NO for Mobile apps, an idea which I did not appreciate much. But filling "null"s in responses for nothing will only make them right.
Christian, specifying the excludable properties doesn't help much because in an entity collection response, different instances can have different null properties.
I have been promoting v4 in our company because OData V4 is presumably light weight because of better json format (compared to v2/v3).
But I can't buy "null" properties being there for nothing. And I can't sell v4 if that's what spec says.
IMHO "null"s should be shown only if client asks for it. Not by default.
Thanks & Regards
Anil
On Wed, May 20, 2015 at 9:06 PM, Frédéric SOUCHU <Fr...@ingenico.com>> wrote:
The whole point of moving away from XML/SOAP is to be much more flexible in term of data contract.
Odata does (or should) provide the best of both worlds:
- Metadata for contract freaks
- JSON for easy integration with 'modern' tools
Is there anything in the specs that say null values must be produced?
For sparse tables/large tables, that's also bandwidth used for nothing.
If the standard is not explicit about it, I'll create a story.
Regards,
Frederic
From: Amend, Christian [mailto:christian.amend@sap.com<ma...@sap.com>]
Sent: 20 May 2015 16:21
To: user@olingo.apache.org<ma...@olingo.apache.org>
Subject: RE: DateTimeOffset in Olingo
Hi,
for your previous issue please refer to my last mail. Any feedback on how you see this would be appreciated.
As for hiding null properties: The specification does not talk about a feature like that so we did not implement this. I also don`t know if it would be wise to exclude null properties when sending a response from the server to a generic client as the client then would not know about the properties at all if it doesn`t have access to the metadata. For custom clients which know the metadata this might be another story. There you could open a feature request in our JIRA.
Technically you can achieve this behavior by specifying a selected list of properties at the SerializerOptions you pass to the entity serializer. This might not be convenient as of now but it would achieve the required effect.
Best Regards,
Christian
From: Anil G [mailto:gvnanils@gmail.com]
Sent: Mittwoch, 20. Mai 2015 16:11
To: user@olingo.apache.org<ma...@olingo.apache.org>
Subject: Re: DateTimeOffset in Olingo
Agreed :)
On a side note, do you know how I can hide "null" values/make serializer ignore nulls in my json response. Nullable = true is not helping. The response json is full of 'null' values which could be simply hidden!
On Wed, May 20, 2015 at 7:35 PM, Frédéric SOUCHU <Fr...@ingenico.com>> wrote:
Same question and findings I got a couple of month ago – see:
http://mail-archives.apache.org/mod_mbox/olingo-user/201503.mbox/%3C4C79C9168A5B9543AA23E3C669025A625035A38B@COSNADEXC13.usr.ingenico.loc%3E
It should be filled as a bug IMHO.
From: Anil G [mailto:gvnanils@gmail.com<ma...@gmail.com>]
Sent: 20 May 2015 15:53
To: user@olingo.apache.org<ma...@olingo.apache.org>
Subject: Re: DateTimeOffset in Olingo
Thanks Fred.
Spec says that is optional. So it should work even if I do not define Precision. But it fails. The below code in EdmDateTimeOffset class throws the exception. Even if I had defined a precision of 2, it failed because the digits value came out as 3 for my data set (probably because I am debugging?)
But why throw IllegalArgumentException when Precision < digits?
/* 257 */ int digits = milliseconds % 10 == 0 ? 2 : milliseconds % 100 == 0 ? 1 : milliseconds % 1000 == 0 ? 0 : 3;
/* 258 */ if (digits > 0) {
/* 259 */ if ((precision == null) || (precision.intValue() < digits)) {
/* 260 */ throw new IllegalArgumentException();
/* */ }
On Wed, May 20, 2015 at 7:18 PM, Frédéric SOUCHU <Fr...@ingenico.com>> wrote:
Correct, it must be defined in the EDM.
From: Anil G [mailto:gvnanils@gmail.com<ma...@gmail.com>]
Sent: 20 May 2015 15:41
To: user@olingo.apache.org<ma...@olingo.apache.org>
Subject: Re: DateTimeOffset in Olingo
as i debug the code, it looks like the precision is mandatory and probably comes from metadata!
will come back with my findings.
On Wed, May 20, 2015 at 6:52 PM, Anil G <gv...@gmail.com>> wrote:
Hi Frederic,
Thanks for a quick response.
I don't see a setPrecision() method in Property class? I am using Beta03 in OData V4.
On Wed, May 20, 2015 at 6:45 PM, Frédéric SOUCHU <Fr...@ingenico.com>> wrote:
You need to specify a 'precision', ex:
new Property()
.setName("OrderDate") // any datetime/timestamp field
.setType(EdmPrimitiveTypeKind.DateTimeOffset.getFullQualifiedName())
.setPrecision(2)
It should really be optional (as per OData spec)…
Frederic
From: Anil G [mailto:gvnanils@gmail.com<ma...@gmail.com>]
Sent: 20 May 2015 15:10
To: user@olingo.apache.org<ma...@olingo.apache.org>
Subject: DateTimeOffset in Olingo
Hi,
I have a DateTimeOffset property defined for my type. But when I am serializing data, it fails with the following Error Message
• message: "Wrong value for property!"
I tried writing data in string (ISO 8601 format), date, calendar but all fails.
Is this a bug or am I doing something wrong? I saw the source code but could not find any serialization logic for Date/Time fields.
Thanks & Regards
Anil
Re: null values
Posted by Anil G <gv...@gmail.com>.
@Christian,
would like to know your comments on the above. :)
On Thu, May 21, 2015 at 11:02 PM, Anil G <gv...@gmail.com> wrote:
> @Christian,
>
> Below are some of the arguments I have heard and my analysis on their
> views. Note that I don't share the same views as them :)
>
> 1. My mobile service doesn't have a strict $metadata or its dynamic and
> change anytime.
>
> 2. Many people still presume that OData responses are very verbose.
> (Unaware of refinements in V4)
>
> 3. Simple REST APIs are easy to consume from mobile apps rather than
> understanding and adhering to OData.
>
>
>
>
>
>
>
> On Thu, May 21, 2015 at 6:35 PM, Alex Maiereanu <
> alex.maiereanu@3sstudio.com> wrote:
>
>> In my company, we are using olingo java for an android app. I don't
>> think that odata is not suitable for mobile apps, but the olingo client,
>> together with the proxy classes, still have a long road ahead. There are
>> still a lot of bugs
>>
>> Salutari din Brasov / Greetings from Brasov
>>
>> Alex-Paul Maiereanu
>>
>> +40 761 684 212
>>
>> www.3sstudio.com
>>
>> Facebook <https://www.facebook.com/smartsocialsoftware> Twitter
>> <https://twitter.com/SmartSocialSoft> Google+
>> <https://plus.google.com/101299629750815349588/posts>
>>
>> On Thu, May 21, 2015 at 3:59 PM, Amend, Christian <
>> christian.amend@sap.com> wrote:
>>
>>> Hi Anil and Frédéric,
>>>
>>> I did not say that the idea of leaving null values is bad. Quite the
>>> contrary I like the idea a lot.
>>>
>>> The reason we do not have this is that we did not have this requirement
>>> on our radar and it is not explicitly stated within the specification as
>>> far as I know. So we could implement a flag for the serializer to omit null
>>> values. But maybe the specification could introduce an OData prefer header
>>> which indicates that this behavior was used to construct the payload. WDYT?
>>>
>>> @Anil: Do you know why there is the opinion that OData should not be
>>> used for mobile apps? Maybe this is feedback the OASIS OData community is
>>> not aware of and thus could not react.
>>>
>>> Best Regards,
>>> Christian
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> *From:* Anil G [mailto:gvnanils@gmail.com]
>>> *Sent:* Mittwoch, 20. Mai 2015 18:44
>>> *To:* user@olingo.apache.org
>>> *Subject:* Re: null values
>>>
>>>
>>>
>>> I have heard experts saying OData is NO NO for Mobile apps, an idea
>>> which I did not appreciate much. But filling "null"s in responses for
>>> nothing will only make them right.
>>>
>>>
>>>
>>> Christian, specifying the excludable properties doesn't help much
>>> because in an entity collection response, different instances can have
>>> different null properties.
>>>
>>>
>>>
>>> I have been promoting v4 in our company because OData V4 is presumably
>>> light weight because of better json format (compared to v2/v3).
>>>
>>> But I can't buy "null" properties being there for nothing. And I can't
>>> sell v4 if that's what spec says.
>>>
>>>
>>>
>>> IMHO "null"s should be shown only if client asks for it. Not by default.
>>>
>>>
>>>
>>> Thanks & Regards
>>>
>>> Anil
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> On Wed, May 20, 2015 at 9:06 PM, Frédéric SOUCHU <
>>> Frederic.SOUCHU@ingenico.com> wrote:
>>>
>>> The whole point of moving away from XML/SOAP is to be much more flexible
>>> in term of data contract.
>>>
>>> Odata does (or should) provide the best of both worlds:
>>>
>>> - Metadata for contract freaks
>>>
>>> - JSON for easy integration with 'modern' tools
>>>
>>>
>>>
>>> Is there anything in the specs that say null values must be produced?
>>>
>>> For sparse tables/large tables, that's also bandwidth used for nothing.
>>>
>>>
>>>
>>> If the standard is not explicit about it, I'll create a story.
>>>
>>>
>>>
>>> Regards,
>>>
>>> Frederic
>>>
>>>
>>>
>>> *From:* Amend, Christian [mailto:christian.amend@sap.com]
>>> *Sent:* 20 May 2015 16:21
>>> *To:* user@olingo.apache.org
>>> *Subject:* RE: DateTimeOffset in Olingo
>>>
>>>
>>>
>>> Hi,
>>>
>>>
>>>
>>> for your previous issue please refer to my last mail. Any feedback on
>>> how you see this would be appreciated.
>>>
>>>
>>>
>>> As for hiding null properties: The specification does not talk about a
>>> feature like that so we did not implement this. I also don`t know if it
>>> would be wise to exclude null properties when sending a response from the
>>> server to a generic client as the client then would not know about the
>>> properties at all if it doesn`t have access to the metadata. For custom
>>> clients which know the metadata this might be another story. There you
>>> could open a feature request in our JIRA.
>>>
>>>
>>>
>>> Technically you can achieve this behavior by specifying a selected list
>>> of properties at the SerializerOptions you pass to the entity serializer.
>>> This might not be convenient as of now but it would achieve the required
>>> effect.
>>>
>>>
>>>
>>> Best Regards,
>>>
>>> Christian
>>>
>>>
>>>
>>> *From:* Anil G [mailto:gvnanils@gmail.com <gv...@gmail.com>]
>>> *Sent:* Mittwoch, 20. Mai 2015 16:11
>>> *To:* user@olingo.apache.org
>>> *Subject:* Re: DateTimeOffset in Olingo
>>>
>>>
>>>
>>> Agreed :)
>>>
>>>
>>>
>>> On a side note, do you know how I can hide "null" values/make serializer
>>> ignore nulls in my json response. Nullable = true is not helping. The
>>> response json is full of 'null' values which could be simply hidden!
>>>
>>>
>>>
>>> On Wed, May 20, 2015 at 7:35 PM, Frédéric SOUCHU <
>>> Frederic.SOUCHU@ingenico.com> wrote:
>>>
>>> Same question and findings I got a couple of month ago – see:
>>>
>>>
>>> http://mail-archives.apache.org/mod_mbox/olingo-user/201503.mbox/%3C4C79C9168A5B9543AA23E3C669025A625035A38B@COSNADEXC13.usr.ingenico.loc%3E
>>>
>>>
>>>
>>> It should be filled as a bug IMHO.
>>>
>>>
>>>
>>> *From:* Anil G [mailto:gvnanils@gmail.com]
>>> *Sent:* 20 May 2015 15:53
>>>
>>>
>>> *To:* user@olingo.apache.org
>>> *Subject:* Re: DateTimeOffset in Olingo
>>>
>>>
>>>
>>> Thanks Fred.
>>>
>>>
>>>
>>> Spec says that is optional. So it should work even if I do not define
>>> Precision. But it fails. The below code in EdmDateTimeOffset class throws
>>> the exception. Even if I had defined a precision of 2, it failed because
>>> the digits value came out as 3 for my data set (probably because I am
>>> debugging?)
>>>
>>>
>>>
>>> But why throw IllegalArgumentException when Precision < digits?
>>>
>>>
>>>
>>> /* 257 */ *int* digits = milliseconds % 10 == 0 ? 2 : milliseconds
>>> % 100 == 0 ? 1 : milliseconds % 1000 == 0 ? 0 : 3;
>>>
>>> /* 258 */ *if* (digits > 0) {
>>>
>>> /* 259 */ *if* ((precision == *null*) || (precision.intValue() <
>>> digits)) {
>>>
>>> */* 260 */ throw new IllegalArgumentException();*
>>>
>>> /* */ }
>>>
>>>
>>>
>>>
>>>
>>> On Wed, May 20, 2015 at 7:18 PM, Frédéric SOUCHU <
>>> Frederic.SOUCHU@ingenico.com> wrote:
>>>
>>> Correct, it must be defined in the EDM.
>>>
>>>
>>>
>>> *From:* Anil G [mailto:gvnanils@gmail.com]
>>> *Sent:* 20 May 2015 15:41
>>> *To:* user@olingo.apache.org
>>> *Subject:* Re: DateTimeOffset in Olingo
>>>
>>>
>>>
>>> as i debug the code, it looks like the precision is mandatory and
>>> probably comes from metadata!
>>>
>>> will come back with my findings.
>>>
>>>
>>>
>>> On Wed, May 20, 2015 at 6:52 PM, Anil G <gv...@gmail.com> wrote:
>>>
>>> Hi Frederic,
>>>
>>>
>>>
>>> Thanks for a quick response.
>>>
>>> I don't see a setPrecision() method in Property class? I am using Beta03
>>> in OData V4.
>>>
>>>
>>>
>>>
>>>
>>> On Wed, May 20, 2015 at 6:45 PM, Frédéric SOUCHU <
>>> Frederic.SOUCHU@ingenico.com> wrote:
>>>
>>> You need to specify a 'precision', ex:
>>>
>>>
>>>
>>> new Property()
>>>
>>> .setName("OrderDate") // any datetime/timestamp field
>>>
>>> .setType(EdmPrimitiveTypeKind.DateTimeOffset.getFullQualifiedName())
>>>
>>> .setPrecision(2)
>>>
>>>
>>>
>>> It should really be optional (as per OData spec)…
>>>
>>>
>>>
>>> Frederic
>>>
>>>
>>>
>>> *From:* Anil G [mailto:gvnanils@gmail.com]
>>> *Sent:* 20 May 2015 15:10
>>> *To:* user@olingo.apache.org
>>> *Subject:* DateTimeOffset in Olingo
>>>
>>>
>>>
>>> Hi,
>>>
>>>
>>>
>>> I have a DateTimeOffset property defined for my type. But when I am
>>> serializing data, it fails with the following Error Message
>>>
>>> · *message*: "Wrong value for property!"
>>>
>>>
>>>
>>> I tried writing data in string (ISO 8601 format), date, calendar but all
>>> fails.
>>>
>>>
>>>
>>> Is this a bug or am I doing something wrong? I saw the source code but
>>> could not find any serialization logic for Date/Time fields.
>>>
>>>
>>>
>>> Thanks & Regards
>>>
>>> Anil
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>
>>
>
Re: null values
Posted by Anil G <gv...@gmail.com>.
@Christian,
Below are some of the arguments I have heard and my analysis on their
views. Note that I don't share the same views as them :)
1. My mobile service doesn't have a strict $metadata or its dynamic and
change anytime.
2. Many people still presume that OData responses are very verbose.
(Unaware of refinements in V4)
3. Simple REST APIs are easy to consume from mobile apps rather than
understanding and adhering to OData.
On Thu, May 21, 2015 at 6:35 PM, Alex Maiereanu <alex.maiereanu@3sstudio.com
> wrote:
> In my company, we are using olingo java for an android app. I don't think
> that odata is not suitable for mobile apps, but the olingo client, together
> with the proxy classes, still have a long road ahead. There are still a lot
> of bugs
>
> Salutari din Brasov / Greetings from Brasov
>
> Alex-Paul Maiereanu
>
> +40 761 684 212
>
> www.3sstudio.com
>
> Facebook <https://www.facebook.com/smartsocialsoftware> Twitter
> <https://twitter.com/SmartSocialSoft> Google+
> <https://plus.google.com/101299629750815349588/posts>
>
> On Thu, May 21, 2015 at 3:59 PM, Amend, Christian <christian.amend@sap.com
> > wrote:
>
>> Hi Anil and Frédéric,
>>
>> I did not say that the idea of leaving null values is bad. Quite the
>> contrary I like the idea a lot.
>>
>> The reason we do not have this is that we did not have this requirement
>> on our radar and it is not explicitly stated within the specification as
>> far as I know. So we could implement a flag for the serializer to omit null
>> values. But maybe the specification could introduce an OData prefer header
>> which indicates that this behavior was used to construct the payload. WDYT?
>>
>> @Anil: Do you know why there is the opinion that OData should not be used
>> for mobile apps? Maybe this is feedback the OASIS OData community is not
>> aware of and thus could not react.
>>
>> Best Regards,
>> Christian
>>
>>
>>
>>
>>
>>
>>
>> *From:* Anil G [mailto:gvnanils@gmail.com]
>> *Sent:* Mittwoch, 20. Mai 2015 18:44
>> *To:* user@olingo.apache.org
>> *Subject:* Re: null values
>>
>>
>>
>> I have heard experts saying OData is NO NO for Mobile apps, an idea which
>> I did not appreciate much. But filling "null"s in responses for nothing
>> will only make them right.
>>
>>
>>
>> Christian, specifying the excludable properties doesn't help much because
>> in an entity collection response, different instances can have different
>> null properties.
>>
>>
>>
>> I have been promoting v4 in our company because OData V4 is presumably
>> light weight because of better json format (compared to v2/v3).
>>
>> But I can't buy "null" properties being there for nothing. And I can't
>> sell v4 if that's what spec says.
>>
>>
>>
>> IMHO "null"s should be shown only if client asks for it. Not by default.
>>
>>
>>
>> Thanks & Regards
>>
>> Anil
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> On Wed, May 20, 2015 at 9:06 PM, Frédéric SOUCHU <
>> Frederic.SOUCHU@ingenico.com> wrote:
>>
>> The whole point of moving away from XML/SOAP is to be much more flexible
>> in term of data contract.
>>
>> Odata does (or should) provide the best of both worlds:
>>
>> - Metadata for contract freaks
>>
>> - JSON for easy integration with 'modern' tools
>>
>>
>>
>> Is there anything in the specs that say null values must be produced?
>>
>> For sparse tables/large tables, that's also bandwidth used for nothing.
>>
>>
>>
>> If the standard is not explicit about it, I'll create a story.
>>
>>
>>
>> Regards,
>>
>> Frederic
>>
>>
>>
>> *From:* Amend, Christian [mailto:christian.amend@sap.com]
>> *Sent:* 20 May 2015 16:21
>> *To:* user@olingo.apache.org
>> *Subject:* RE: DateTimeOffset in Olingo
>>
>>
>>
>> Hi,
>>
>>
>>
>> for your previous issue please refer to my last mail. Any feedback on how
>> you see this would be appreciated.
>>
>>
>>
>> As for hiding null properties: The specification does not talk about a
>> feature like that so we did not implement this. I also don`t know if it
>> would be wise to exclude null properties when sending a response from the
>> server to a generic client as the client then would not know about the
>> properties at all if it doesn`t have access to the metadata. For custom
>> clients which know the metadata this might be another story. There you
>> could open a feature request in our JIRA.
>>
>>
>>
>> Technically you can achieve this behavior by specifying a selected list
>> of properties at the SerializerOptions you pass to the entity serializer.
>> This might not be convenient as of now but it would achieve the required
>> effect.
>>
>>
>>
>> Best Regards,
>>
>> Christian
>>
>>
>>
>> *From:* Anil G [mailto:gvnanils@gmail.com <gv...@gmail.com>]
>> *Sent:* Mittwoch, 20. Mai 2015 16:11
>> *To:* user@olingo.apache.org
>> *Subject:* Re: DateTimeOffset in Olingo
>>
>>
>>
>> Agreed :)
>>
>>
>>
>> On a side note, do you know how I can hide "null" values/make serializer
>> ignore nulls in my json response. Nullable = true is not helping. The
>> response json is full of 'null' values which could be simply hidden!
>>
>>
>>
>> On Wed, May 20, 2015 at 7:35 PM, Frédéric SOUCHU <
>> Frederic.SOUCHU@ingenico.com> wrote:
>>
>> Same question and findings I got a couple of month ago – see:
>>
>>
>> http://mail-archives.apache.org/mod_mbox/olingo-user/201503.mbox/%3C4C79C9168A5B9543AA23E3C669025A625035A38B@COSNADEXC13.usr.ingenico.loc%3E
>>
>>
>>
>> It should be filled as a bug IMHO.
>>
>>
>>
>> *From:* Anil G [mailto:gvnanils@gmail.com]
>> *Sent:* 20 May 2015 15:53
>>
>>
>> *To:* user@olingo.apache.org
>> *Subject:* Re: DateTimeOffset in Olingo
>>
>>
>>
>> Thanks Fred.
>>
>>
>>
>> Spec says that is optional. So it should work even if I do not define
>> Precision. But it fails. The below code in EdmDateTimeOffset class throws
>> the exception. Even if I had defined a precision of 2, it failed because
>> the digits value came out as 3 for my data set (probably because I am
>> debugging?)
>>
>>
>>
>> But why throw IllegalArgumentException when Precision < digits?
>>
>>
>>
>> /* 257 */ *int* digits = milliseconds % 10 == 0 ? 2 : milliseconds %
>> 100 == 0 ? 1 : milliseconds % 1000 == 0 ? 0 : 3;
>>
>> /* 258 */ *if* (digits > 0) {
>>
>> /* 259 */ *if* ((precision == *null*) || (precision.intValue() <
>> digits)) {
>>
>> */* 260 */ throw new IllegalArgumentException();*
>>
>> /* */ }
>>
>>
>>
>>
>>
>> On Wed, May 20, 2015 at 7:18 PM, Frédéric SOUCHU <
>> Frederic.SOUCHU@ingenico.com> wrote:
>>
>> Correct, it must be defined in the EDM.
>>
>>
>>
>> *From:* Anil G [mailto:gvnanils@gmail.com]
>> *Sent:* 20 May 2015 15:41
>> *To:* user@olingo.apache.org
>> *Subject:* Re: DateTimeOffset in Olingo
>>
>>
>>
>> as i debug the code, it looks like the precision is mandatory and
>> probably comes from metadata!
>>
>> will come back with my findings.
>>
>>
>>
>> On Wed, May 20, 2015 at 6:52 PM, Anil G <gv...@gmail.com> wrote:
>>
>> Hi Frederic,
>>
>>
>>
>> Thanks for a quick response.
>>
>> I don't see a setPrecision() method in Property class? I am using Beta03
>> in OData V4.
>>
>>
>>
>>
>>
>> On Wed, May 20, 2015 at 6:45 PM, Frédéric SOUCHU <
>> Frederic.SOUCHU@ingenico.com> wrote:
>>
>> You need to specify a 'precision', ex:
>>
>>
>>
>> new Property()
>>
>> .setName("OrderDate") // any datetime/timestamp field
>>
>> .setType(EdmPrimitiveTypeKind.DateTimeOffset.getFullQualifiedName())
>>
>> .setPrecision(2)
>>
>>
>>
>> It should really be optional (as per OData spec)…
>>
>>
>>
>> Frederic
>>
>>
>>
>> *From:* Anil G [mailto:gvnanils@gmail.com]
>> *Sent:* 20 May 2015 15:10
>> *To:* user@olingo.apache.org
>> *Subject:* DateTimeOffset in Olingo
>>
>>
>>
>> Hi,
>>
>>
>>
>> I have a DateTimeOffset property defined for my type. But when I am
>> serializing data, it fails with the following Error Message
>>
>> · *message*: "Wrong value for property!"
>>
>>
>>
>> I tried writing data in string (ISO 8601 format), date, calendar but all
>> fails.
>>
>>
>>
>> Is this a bug or am I doing something wrong? I saw the source code but
>> could not find any serialization logic for Date/Time fields.
>>
>>
>>
>> Thanks & Regards
>>
>> Anil
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>
>
Re: null values
Posted by Alex Maiereanu <al...@3sstudio.com>.
In my company, we are using olingo java for an android app. I don't think
that odata is not suitable for mobile apps, but the olingo client, together
with the proxy classes, still have a long road ahead. There are still a lot
of bugs
Salutari din Brasov / Greetings from Brasov
Alex-Paul Maiereanu
+40 761 684 212
www.3sstudio.com
Facebook <https://www.facebook.com/smartsocialsoftware> Twitter
<https://twitter.com/SmartSocialSoft> Google+
<https://plus.google.com/101299629750815349588/posts>
On Thu, May 21, 2015 at 3:59 PM, Amend, Christian <ch...@sap.com>
wrote:
> Hi Anil and Frédéric,
>
> I did not say that the idea of leaving null values is bad. Quite the
> contrary I like the idea a lot.
>
> The reason we do not have this is that we did not have this requirement on
> our radar and it is not explicitly stated within the specification as far
> as I know. So we could implement a flag for the serializer to omit null
> values. But maybe the specification could introduce an OData prefer header
> which indicates that this behavior was used to construct the payload. WDYT?
>
> @Anil: Do you know why there is the opinion that OData should not be used
> for mobile apps? Maybe this is feedback the OASIS OData community is not
> aware of and thus could not react.
>
> Best Regards,
> Christian
>
>
>
>
>
>
>
> *From:* Anil G [mailto:gvnanils@gmail.com]
> *Sent:* Mittwoch, 20. Mai 2015 18:44
> *To:* user@olingo.apache.org
> *Subject:* Re: null values
>
>
>
> I have heard experts saying OData is NO NO for Mobile apps, an idea which
> I did not appreciate much. But filling "null"s in responses for nothing
> will only make them right.
>
>
>
> Christian, specifying the excludable properties doesn't help much because
> in an entity collection response, different instances can have different
> null properties.
>
>
>
> I have been promoting v4 in our company because OData V4 is presumably
> light weight because of better json format (compared to v2/v3).
>
> But I can't buy "null" properties being there for nothing. And I can't
> sell v4 if that's what spec says.
>
>
>
> IMHO "null"s should be shown only if client asks for it. Not by default.
>
>
>
> Thanks & Regards
>
> Anil
>
>
>
>
>
>
>
>
>
> On Wed, May 20, 2015 at 9:06 PM, Frédéric SOUCHU <
> Frederic.SOUCHU@ingenico.com> wrote:
>
> The whole point of moving away from XML/SOAP is to be much more flexible
> in term of data contract.
>
> Odata does (or should) provide the best of both worlds:
>
> - Metadata for contract freaks
>
> - JSON for easy integration with 'modern' tools
>
>
>
> Is there anything in the specs that say null values must be produced?
>
> For sparse tables/large tables, that's also bandwidth used for nothing.
>
>
>
> If the standard is not explicit about it, I'll create a story.
>
>
>
> Regards,
>
> Frederic
>
>
>
> *From:* Amend, Christian [mailto:christian.amend@sap.com]
> *Sent:* 20 May 2015 16:21
> *To:* user@olingo.apache.org
> *Subject:* RE: DateTimeOffset in Olingo
>
>
>
> Hi,
>
>
>
> for your previous issue please refer to my last mail. Any feedback on how
> you see this would be appreciated.
>
>
>
> As for hiding null properties: The specification does not talk about a
> feature like that so we did not implement this. I also don`t know if it
> would be wise to exclude null properties when sending a response from the
> server to a generic client as the client then would not know about the
> properties at all if it doesn`t have access to the metadata. For custom
> clients which know the metadata this might be another story. There you
> could open a feature request in our JIRA.
>
>
>
> Technically you can achieve this behavior by specifying a selected list of
> properties at the SerializerOptions you pass to the entity serializer. This
> might not be convenient as of now but it would achieve the required effect.
>
>
>
> Best Regards,
>
> Christian
>
>
>
> *From:* Anil G [mailto:gvnanils@gmail.com <gv...@gmail.com>]
> *Sent:* Mittwoch, 20. Mai 2015 16:11
> *To:* user@olingo.apache.org
> *Subject:* Re: DateTimeOffset in Olingo
>
>
>
> Agreed :)
>
>
>
> On a side note, do you know how I can hide "null" values/make serializer
> ignore nulls in my json response. Nullable = true is not helping. The
> response json is full of 'null' values which could be simply hidden!
>
>
>
> On Wed, May 20, 2015 at 7:35 PM, Frédéric SOUCHU <
> Frederic.SOUCHU@ingenico.com> wrote:
>
> Same question and findings I got a couple of month ago – see:
>
>
> http://mail-archives.apache.org/mod_mbox/olingo-user/201503.mbox/%3C4C79C9168A5B9543AA23E3C669025A625035A38B@COSNADEXC13.usr.ingenico.loc%3E
>
>
>
> It should be filled as a bug IMHO.
>
>
>
> *From:* Anil G [mailto:gvnanils@gmail.com]
> *Sent:* 20 May 2015 15:53
>
>
> *To:* user@olingo.apache.org
> *Subject:* Re: DateTimeOffset in Olingo
>
>
>
> Thanks Fred.
>
>
>
> Spec says that is optional. So it should work even if I do not define
> Precision. But it fails. The below code in EdmDateTimeOffset class throws
> the exception. Even if I had defined a precision of 2, it failed because
> the digits value came out as 3 for my data set (probably because I am
> debugging?)
>
>
>
> But why throw IllegalArgumentException when Precision < digits?
>
>
>
> /* 257 */ *int* digits = milliseconds % 10 == 0 ? 2 : milliseconds %
> 100 == 0 ? 1 : milliseconds % 1000 == 0 ? 0 : 3;
>
> /* 258 */ *if* (digits > 0) {
>
> /* 259 */ *if* ((precision == *null*) || (precision.intValue() <
> digits)) {
>
> */* 260 */ throw new IllegalArgumentException();*
>
> /* */ }
>
>
>
>
>
> On Wed, May 20, 2015 at 7:18 PM, Frédéric SOUCHU <
> Frederic.SOUCHU@ingenico.com> wrote:
>
> Correct, it must be defined in the EDM.
>
>
>
> *From:* Anil G [mailto:gvnanils@gmail.com]
> *Sent:* 20 May 2015 15:41
> *To:* user@olingo.apache.org
> *Subject:* Re: DateTimeOffset in Olingo
>
>
>
> as i debug the code, it looks like the precision is mandatory and probably
> comes from metadata!
>
> will come back with my findings.
>
>
>
> On Wed, May 20, 2015 at 6:52 PM, Anil G <gv...@gmail.com> wrote:
>
> Hi Frederic,
>
>
>
> Thanks for a quick response.
>
> I don't see a setPrecision() method in Property class? I am using Beta03
> in OData V4.
>
>
>
>
>
> On Wed, May 20, 2015 at 6:45 PM, Frédéric SOUCHU <
> Frederic.SOUCHU@ingenico.com> wrote:
>
> You need to specify a 'precision', ex:
>
>
>
> new Property()
>
> .setName("OrderDate") // any datetime/timestamp field
>
> .setType(EdmPrimitiveTypeKind.DateTimeOffset.getFullQualifiedName())
>
> .setPrecision(2)
>
>
>
> It should really be optional (as per OData spec)…
>
>
>
> Frederic
>
>
>
> *From:* Anil G [mailto:gvnanils@gmail.com]
> *Sent:* 20 May 2015 15:10
> *To:* user@olingo.apache.org
> *Subject:* DateTimeOffset in Olingo
>
>
>
> Hi,
>
>
>
> I have a DateTimeOffset property defined for my type. But when I am
> serializing data, it fails with the following Error Message
>
> · *message*: "Wrong value for property!"
>
>
>
> I tried writing data in string (ISO 8601 format), date, calendar but all
> fails.
>
>
>
> Is this a bug or am I doing something wrong? I saw the source code but
> could not find any serialization logic for Date/Time fields.
>
>
>
> Thanks & Regards
>
> Anil
>
>
>
>
>
>
>
>
>
>
>
RE: null values
Posted by "Amend, Christian" <ch...@sap.com>.
Hi Anil and Frédéric,
I did not say that the idea of leaving null values is bad. Quite the contrary I like the idea a lot.
The reason we do not have this is that we did not have this requirement on our radar and it is not explicitly stated within the specification as far as I know. So we could implement a flag for the serializer to omit null values. But maybe the specification could introduce an OData prefer header which indicates that this behavior was used to construct the payload. WDYT?
@Anil: Do you know why there is the opinion that OData should not be used for mobile apps? Maybe this is feedback the OASIS OData community is not aware of and thus could not react.
Best Regards,
Christian
From: Anil G [mailto:gvnanils@gmail.com]
Sent: Mittwoch, 20. Mai 2015 18:44
To: user@olingo.apache.org
Subject: Re: null values
I have heard experts saying OData is NO NO for Mobile apps, an idea which I did not appreciate much. But filling "null"s in responses for nothing will only make them right.
Christian, specifying the excludable properties doesn't help much because in an entity collection response, different instances can have different null properties.
I have been promoting v4 in our company because OData V4 is presumably light weight because of better json format (compared to v2/v3).
But I can't buy "null" properties being there for nothing. And I can't sell v4 if that's what spec says.
IMHO "null"s should be shown only if client asks for it. Not by default.
Thanks & Regards
Anil
On Wed, May 20, 2015 at 9:06 PM, Frédéric SOUCHU <Fr...@ingenico.com>> wrote:
The whole point of moving away from XML/SOAP is to be much more flexible in term of data contract.
Odata does (or should) provide the best of both worlds:
- Metadata for contract freaks
- JSON for easy integration with 'modern' tools
Is there anything in the specs that say null values must be produced?
For sparse tables/large tables, that's also bandwidth used for nothing.
If the standard is not explicit about it, I'll create a story.
Regards,
Frederic
From: Amend, Christian [mailto:christian.amend@sap.com<ma...@sap.com>]
Sent: 20 May 2015 16:21
To: user@olingo.apache.org<ma...@olingo.apache.org>
Subject: RE: DateTimeOffset in Olingo
Hi,
for your previous issue please refer to my last mail. Any feedback on how you see this would be appreciated.
As for hiding null properties: The specification does not talk about a feature like that so we did not implement this. I also don`t know if it would be wise to exclude null properties when sending a response from the server to a generic client as the client then would not know about the properties at all if it doesn`t have access to the metadata. For custom clients which know the metadata this might be another story. There you could open a feature request in our JIRA.
Technically you can achieve this behavior by specifying a selected list of properties at the SerializerOptions you pass to the entity serializer. This might not be convenient as of now but it would achieve the required effect.
Best Regards,
Christian
From: Anil G [mailto:gvnanils@gmail.com]
Sent: Mittwoch, 20. Mai 2015 16:11
To: user@olingo.apache.org<ma...@olingo.apache.org>
Subject: Re: DateTimeOffset in Olingo
Agreed :)
On a side note, do you know how I can hide "null" values/make serializer ignore nulls in my json response. Nullable = true is not helping. The response json is full of 'null' values which could be simply hidden!
On Wed, May 20, 2015 at 7:35 PM, Frédéric SOUCHU <Fr...@ingenico.com>> wrote:
Same question and findings I got a couple of month ago – see:
http://mail-archives.apache.org/mod_mbox/olingo-user/201503.mbox/%3C4C79C9168A5B9543AA23E3C669025A625035A38B@COSNADEXC13.usr.ingenico.loc%3E
It should be filled as a bug IMHO.
From: Anil G [mailto:gvnanils@gmail.com<ma...@gmail.com>]
Sent: 20 May 2015 15:53
To: user@olingo.apache.org<ma...@olingo.apache.org>
Subject: Re: DateTimeOffset in Olingo
Thanks Fred.
Spec says that is optional. So it should work even if I do not define Precision. But it fails. The below code in EdmDateTimeOffset class throws the exception. Even if I had defined a precision of 2, it failed because the digits value came out as 3 for my data set (probably because I am debugging?)
But why throw IllegalArgumentException when Precision < digits?
/* 257 */ int digits = milliseconds % 10 == 0 ? 2 : milliseconds % 100 == 0 ? 1 : milliseconds % 1000 == 0 ? 0 : 3;
/* 258 */ if (digits > 0) {
/* 259 */ if ((precision == null) || (precision.intValue() < digits)) {
/* 260 */ throw new IllegalArgumentException();
/* */ }
On Wed, May 20, 2015 at 7:18 PM, Frédéric SOUCHU <Fr...@ingenico.com>> wrote:
Correct, it must be defined in the EDM.
From: Anil G [mailto:gvnanils@gmail.com<ma...@gmail.com>]
Sent: 20 May 2015 15:41
To: user@olingo.apache.org<ma...@olingo.apache.org>
Subject: Re: DateTimeOffset in Olingo
as i debug the code, it looks like the precision is mandatory and probably comes from metadata!
will come back with my findings.
On Wed, May 20, 2015 at 6:52 PM, Anil G <gv...@gmail.com>> wrote:
Hi Frederic,
Thanks for a quick response.
I don't see a setPrecision() method in Property class? I am using Beta03 in OData V4.
On Wed, May 20, 2015 at 6:45 PM, Frédéric SOUCHU <Fr...@ingenico.com>> wrote:
You need to specify a 'precision', ex:
new Property()
.setName("OrderDate") // any datetime/timestamp field
.setType(EdmPrimitiveTypeKind.DateTimeOffset.getFullQualifiedName())
.setPrecision(2)
It should really be optional (as per OData spec)…
Frederic
From: Anil G [mailto:gvnanils@gmail.com<ma...@gmail.com>]
Sent: 20 May 2015 15:10
To: user@olingo.apache.org<ma...@olingo.apache.org>
Subject: DateTimeOffset in Olingo
Hi,
I have a DateTimeOffset property defined for my type. But when I am serializing data, it fails with the following Error Message
• message: "Wrong value for property!"
I tried writing data in string (ISO 8601 format), date, calendar but all fails.
Is this a bug or am I doing something wrong? I saw the source code but could not find any serialization logic for Date/Time fields.
Thanks & Regards
Anil
Re: null values
Posted by Anil G <gv...@gmail.com>.
I have heard experts saying OData is NO NO for Mobile apps, an idea which I
did not appreciate much. But filling "null"s in responses for nothing will
only make them right.
Christian, specifying the excludable properties doesn't help much because
in an entity collection response, different instances can have different
null properties.
I have been promoting v4 in our company because OData V4 is presumably
light weight because of better json format (compared to v2/v3).
But I can't buy "null" properties being there for nothing. And I can't sell
v4 if that's what spec says.
IMHO "null"s should be shown only if client asks for it. Not by default.
Thanks & Regards
Anil
On Wed, May 20, 2015 at 9:06 PM, Frédéric SOUCHU <
Frederic.SOUCHU@ingenico.com> wrote:
> The whole point of moving away from XML/SOAP is to be much more flexible
> in term of data contract.
>
> Odata does (or should) provide the best of both worlds:
>
> - Metadata for contract freaks
>
> - JSON for easy integration with 'modern' tools
>
>
>
> Is there anything in the specs that say null values must be produced?
>
> For sparse tables/large tables, that's also bandwidth used for nothing.
>
>
>
> If the standard is not explicit about it, I'll create a story.
>
>
>
> Regards,
>
> Frederic
>
>
>
> *From:* Amend, Christian [mailto:christian.amend@sap.com]
> *Sent:* 20 May 2015 16:21
> *To:* user@olingo.apache.org
> *Subject:* RE: DateTimeOffset in Olingo
>
>
>
> Hi,
>
>
>
> for your previous issue please refer to my last mail. Any feedback on how
> you see this would be appreciated.
>
>
>
> As for hiding null properties: The specification does not talk about a
> feature like that so we did not implement this. I also don`t know if it
> would be wise to exclude null properties when sending a response from the
> server to a generic client as the client then would not know about the
> properties at all if it doesn`t have access to the metadata. For custom
> clients which know the metadata this might be another story. There you
> could open a feature request in our JIRA.
>
>
>
> Technically you can achieve this behavior by specifying a selected list of
> properties at the SerializerOptions you pass to the entity serializer. This
> might not be convenient as of now but it would achieve the required effect.
>
>
>
> Best Regards,
>
> Christian
>
>
>
> *From:* Anil G [mailto:gvnanils@gmail.com <gv...@gmail.com>]
> *Sent:* Mittwoch, 20. Mai 2015 16:11
> *To:* user@olingo.apache.org
> *Subject:* Re: DateTimeOffset in Olingo
>
>
>
> Agreed :)
>
>
>
> On a side note, do you know how I can hide "null" values/make serializer
> ignore nulls in my json response. Nullable = true is not helping. The
> response json is full of 'null' values which could be simply hidden!
>
>
>
> On Wed, May 20, 2015 at 7:35 PM, Frédéric SOUCHU <
> Frederic.SOUCHU@ingenico.com> wrote:
>
> Same question and findings I got a couple of month ago – see:
>
>
> http://mail-archives.apache.org/mod_mbox/olingo-user/201503.mbox/%3C4C79C9168A5B9543AA23E3C669025A625035A38B@COSNADEXC13.usr.ingenico.loc%3E
>
>
>
> It should be filled as a bug IMHO.
>
>
>
> *From:* Anil G [mailto:gvnanils@gmail.com]
> *Sent:* 20 May 2015 15:53
>
>
> *To:* user@olingo.apache.org
> *Subject:* Re: DateTimeOffset in Olingo
>
>
>
> Thanks Fred.
>
>
>
> Spec says that is optional. So it should work even if I do not define
> Precision. But it fails. The below code in EdmDateTimeOffset class throws
> the exception. Even if I had defined a precision of 2, it failed because
> the digits value came out as 3 for my data set (probably because I am
> debugging?)
>
>
>
> But why throw IllegalArgumentException when Precision < digits?
>
>
>
> /* 257 */ *int* digits = milliseconds % 10 == 0 ? 2 : milliseconds %
> 100 == 0 ? 1 : milliseconds % 1000 == 0 ? 0 : 3;
>
> /* 258 */ *if* (digits > 0) {
>
> /* 259 */ *if* ((precision == *null*) || (precision.intValue() <
> digits)) {
>
> */* 260 */ throw new IllegalArgumentException();*
>
> /* */ }
>
>
>
>
>
> On Wed, May 20, 2015 at 7:18 PM, Frédéric SOUCHU <
> Frederic.SOUCHU@ingenico.com> wrote:
>
> Correct, it must be defined in the EDM.
>
>
>
> *From:* Anil G [mailto:gvnanils@gmail.com]
> *Sent:* 20 May 2015 15:41
> *To:* user@olingo.apache.org
> *Subject:* Re: DateTimeOffset in Olingo
>
>
>
> as i debug the code, it looks like the precision is mandatory and probably
> comes from metadata!
>
> will come back with my findings.
>
>
>
> On Wed, May 20, 2015 at 6:52 PM, Anil G <gv...@gmail.com> wrote:
>
> Hi Frederic,
>
>
>
> Thanks for a quick response.
>
> I don't see a setPrecision() method in Property class? I am using Beta03
> in OData V4.
>
>
>
>
>
> On Wed, May 20, 2015 at 6:45 PM, Frédéric SOUCHU <
> Frederic.SOUCHU@ingenico.com> wrote:
>
> You need to specify a 'precision', ex:
>
>
>
> new Property()
>
> .setName("OrderDate") // any datetime/timestamp field
>
> .setType(EdmPrimitiveTypeKind.DateTimeOffset.getFullQualifiedName())
>
> .setPrecision(2)
>
>
>
> It should really be optional (as per OData spec)…
>
>
>
> Frederic
>
>
>
> *From:* Anil G [mailto:gvnanils@gmail.com]
> *Sent:* 20 May 2015 15:10
> *To:* user@olingo.apache.org
> *Subject:* DateTimeOffset in Olingo
>
>
>
> Hi,
>
>
>
> I have a DateTimeOffset property defined for my type. But when I am
> serializing data, it fails with the following Error Message
>
> · *message*: "Wrong value for property!"
>
>
>
> I tried writing data in string (ISO 8601 format), date, calendar but all
> fails.
>
>
>
> Is this a bug or am I doing something wrong? I saw the source code but
> could not find any serialization logic for Date/Time fields.
>
>
>
> Thanks & Regards
>
> Anil
>
>
>
>
>
>
>
>
>