SITreg
SITreg copied to clipboard
sapmentors
Properties with dots in their names are invalid
Entity set "Events" is based on a type that contains properties that have dots in their names, e.g.: History.CreatedBy, History.CreatedAt. However, the OData specification indicates that dots are not allowed. Would it be a huge job to change these property names into names without dots?
The thing is that I'm using the OLingo client to read the OData service, and the Olingo guys have implemented the specs up to the letter. In https://github.com/apache/olingo-odata2/blob/master/odata2-lib/odata-core/src/main/java/org/apache/olingo/odata2/core/edm/provider/EdmNamedImplProv.java you can see the same regular expression as specified in the OData standard, paragraph 2.2.6 (https://winprotocoldoc.blob.core.windows.net/productionwindowsarchives/MC-CSDL/[MC-CSDL].pdf), which rejects all property names containing invalid characters.
As a quick fix I will base the entity Events on a view that does not expose the History structure. But it seems that this is worth filing a bug on HANA XSODATA as such invalid characters in attributes should be not exposed in the first place.
I've now quickly fixed it by building a custom OLingo version, but I'd rather stick to the standard, as it allows me to upgrade easier when new versions come out. Does xsodata expose these fields with dots because they're also named that way in the database?
It's definitely worth a bug report with the HANA platform folks as non-spec-compliant output potentially breaks consuming systems. Just not sure where to register it. Any clue?
Can you please try against https://hanamdcs0001142741trial.hanatrial.ondemand.com/com/sap/sapmentors/sitreg/odatapublic/service.xsodata/ if it is OK now?
I'm afraid Olingo still doesn't like it, because those fields are still present in the metamodel: https://sapmentorsa5a504e08.hana.ondemand.com/com/sap/sapmentors/sitreg/odatapublic/service.xsodata/$metadata
Please check the URL. I haven't implemented it yet on production. Please test against my dev system.
I can pass this along to development but I doubt you will see a change. This would alter the columns in existing services breaking applications in productive use. I would imagine the response will be what you already found - that there is a workaround by using a view and choosing any names you want.
Sorry @gregorwolf, I'm now using the right URL and it works like a charm. Let me know when you push this to production?
@I809764 I think it's quite important that this is changed as output currently doesn't follow the specs, which may break consuming systems. When it does, I can speak from experience when I say that it may lead to quite a lengthy debugging session to find the cause if this happens. In case a dot is used, it may be an idea to encode it into something that is allowed in the OData export, or perhaps give a warning that those fields may not work (similar to e.g. geo-fields)?
Done with the production changes @jpenninkhof. I think we keep the issue open until we hear back from @I809764.