Problems during accessing double with OData v4

[sbalconi]

Hi all, I've found out an issue during the utilization of OData command to inquire the entities.

In particular I find that for some character such as / or decimal number, I can see data only by using Odata old version (2) while with version 4 it gives an error (attached file)

That is if I use  OData4/Entities/entity_name?$ the system can't compile

but if I use the following sintax it works:

OData/Entities.Entity.name?$

Could you tell me why some special characters generate this problem?

Regards

SB

[rareddy]

OData v4 is strict in checking the precision and scale values of the data for float/single and double types, I think that is why it is failing when it sees the data which does not conform to it.  You can adjust the metadata on this column type to allow the value.

[sbalconi]

Hi Ramesh, I've tried to find out in Teiid Designer a box in which I could set the format of my parameters, without succeeding.

I wonder if there is such a option to set the values and use it to manage special characters (for example ! " £ $ % & * ç - _ à #) or I need to search other solution to handle this issue.

Please help me to digest this compilation diversity between V2 and V4.

Regards

Stefano

[rareddy]

Stefano,

I am not sure I completely understand the issue you are having, my previous suggestion was based on the error text you showed, but you seemed to be asking about special characters? What are you trying to do?

To explain about the URL, A entity has model name, entity name.

In V2, the way we designed the URL to access the entity is http://<host>:<port>/odata/<vdbname>/<modelname>.<entityname>

Where as in V4, the same would look like http://<host>.<port>/odata4/<vdbname>/<modelname>/<entityname> , this is due to differences in schema definition (CSDL file) in the V4 and entity namespace restrictions. so, same URL will not work in both V2 and V4 they will be slightly different. As per usage of "$" symbol in both V2 and V4 is only needed when you need to pass in further query parameters, like $filter, $select or $expand etc. I suggest you read through OData Spec in terms of how form the URL.

HTH

Ramesh..

[sbalconi]

To explian myself better I want to show two more errors which display during my attempt to examine the entities usind OData v4

[rareddy]

I just tested the OData V4, entities with String fields with values that have forward slash "/" in them and I do not see the error you are showing above. What is data type for "DocumentType" and "LookupField" in your $metadata?

[mirco73]

Hi Ramesh,

I think I understand what the problem Stefano found could be:

In case of a string field, if in the metadata definition of a virtual table you define a length smaller then the real data, with an odata4 select the system returns the misleading error "the value xxxx is not valid for property yyyyy". Defining the length in the right way the error is not more displayed

Anyway I 've found another similar issue on a odata4 select:

I've created a virtual table with a new field defined in this way:

select ROUND((BA.PREIS / BA.PEINH), 3) AS UnitPrice from xxxxxx

for the source field are bigdecimal I define UnitPrice as

BigDecimal (13,3)

If I run the qery from JDBC

select * from PurchaseRequisitionEntity where PurchaseRequisitionKey = '300-8000001452-00010' ;

PREIS = 539,568

PEINH = 106

UnitPrice = 5,090.264

And the result is correct. If I run from odata2

/odata/CASALE.1/Entities.PurchaseRequisitionEntity('300-8000001452-00010')?$format=json

"UnitPrice" : "5090.2640000000000000"

As you can see the field is rounded to the 3rd digit but 13 more digits are returned with 0 value.

Anyway odata2 succeeds in returning the result without errors.

With odata4 I get an error:

/odata4/CASALE.1/Entities/PurchaseRequisitionEntity('300-8000001452-00010')?$format=json

{"error":{"code":null,"message":"The value '5090.2640000000000000' is not valid for property 'UnitPrice'."}}

I think that's because the length of the field is greater then the matedata definition.

At the moment the only solution I can imagine is to convert the number to a string in the proper format and the parse it into a number

thanks,

Mirco,

[rareddy]

Olingo framework which used for OData V4 is strict in enforcing the values to conform to the metadata. Here I am still not sure where the extra appended zeros came from? Looks like some lingering issue. Can you log an issue with the above as test case?