Repository navigation
AttributeError in PyOData v1.11.0 When Executing CustomerCollection Query #262
Description
After updating to PyOData version 1.11.0, I encountered a significant issue with a previously functional query. The purpose of the query is to retrieve a list of customers using the CustomerCollection.get_entities() method, with additional parameters for counting, filtering, ordering, and limiting the number of results.
Issue Details:
The following Python code, which worked flawlessly in version 1.10.1, started throwing an AttributeError in version 1.11.0:
customers = accountService.entity_sets.CustomerCollection.get_entities().count(inline=True).filter("LifeCycleStatusCode eq '2'").custom("$orderby", "LastChangeDateTime desc").custom("$top", "8").execute()
Error Message:
The error message received is as follows:
[ERROR] AttributeError: 'str' object has no attribute 'get' Traceback (most recent call last): File "/var/task/GETAccountandContact.py", line 86, in lambda_handler customers = accountService.entity_sets.CustomerCollection.get_entities().count(inline=True).filter("LifeCycleStatusCode eq '2'").custom("$orderby", "LastChangeDateTime desc").custom("$top", "8").execute() File "/tmp/pyodata/v2/service.py", line 349, in execute return self._call_handler(response) File "/tmp/pyodata/v2/service.py", line 362, in _call_handler return self._handler(response) File "/tmp/pyodata/v2/service.py", line 1549, in get_entities_handler entity = EntityProxy(self._service, self._entity_set, self._entity_set.entity_type, props) File "/tmp/pyodata/v2/service.py", line 881, in __init__ self._cache[prop.name].append(EntityProxy(service, None, prop_etype, entity)) File "/tmp/pyodata/v2/service.py", line 825, in __init__ etag_body = proprties.get('__metadata', dict()).get('etag', None)
Temporary Solution:
As a temporary workaround, I had to downgrade to version 1.10.1, after which the query started working again without any errors.
Request:
I believe this is a bug introduced in version 1.11.0. It would be greatly appreciated if the team could investigate this issue and provide a fix or guidance on how to resolve it in the newer version of PyOData.
Thank you for your attention to this matter.
Activity
phanak-sap commentedon Nov 24, 2023
Hi @anthonyng288
thanks for the bug report. Clearly the existing test suite did not catch this problem. Yes, breaking change has the utmost priority.
Could you please provide me the $metatada for the service, or just snippet relevant to CustomerCollection? Or ideally, failing unit test (PR here) or a bug reproducer script - e.g PR for https://github.com/phanak-sap/pyodata-issue-files
The provided code
customers = accountService.entity_sets.CustomerCollection.get_entities().count(inline=True).filter("LifeCycleStatusCode eq '2'").custom("$orderby", "LastChangeDateTime desc").custom("$top", "8").execute()is only half of the root cause, I am only guessing what is on the other side this code is going trough. I can guess, but then - how can I be sure it is really the problem you are seeing.
phanak-sap commentedon Nov 26, 2023
Hi @anthonyng288, I have tried to reproduce this on my own - basically modify existing test
test_custom_with_get_entityto contain similar sequence of function calls, but I cannot raise the error.I really need the service metadata or the bug reproducer script/failing unit test to proceed further.
anthonyng288 commentedon Nov 26, 2023
Here is the service metadata, I think this is what you are looking for
phanak-sap commentedon Nov 27, 2023
Hi @anthonyng288,
thx for the metadata. URL Query generation part seems to be the same for both version, it is not from the encoder PR #243.
This seems to be bug introduced by the PR #258. And my current working hypothesis is that root cause is relevant to this, unchanged part of the service module - https://github.com/SAP/python-pyodata/blame/0d5c9dabfc7e5b99837eaf7fdccc592bc344d623/pyodata/v2/service.py#L1543
Since this is the part that is relevant to networking and actual service responses - and I do not have service at hand that returns that kind of data - to confirm my suspicions could you for sure post the returned json response for the
customers = accountService.entity_sets.CustomerCollection.get_entities().count(inline=True).filter("LifeCycleStatusCode eq '2'").custom("$orderby", "LastChangeDateTime desc").custom("$top", "8").execute()E.g. similarly to this comment #202 (comment) - the data can be obfuscated to just "VALUE" strings, I am interested just in the JSON structure only - and actually
custom("$top", "2")would be enough.Based on the metadata namespace I am guessing it is relevant to this API - https://blogs.sap.com/2021/04/05/how-to-connect-sap-cloud-for-customer-c4c-and-sap-analytics-cloud-sac/.
manuelseeger commentedon Nov 28, 2023
@anthonyng288 SAP C4C initially implemented collections off OData V2 spec. Try sending this header along with your requests:odata-v2-strict-json-format : trueksaito1125 commentedon Nov 30, 2023
Code that was working with pyodata 1.10.1 stopped working after upgrading to 1.11.0. I get a similar error.
@manuelseeger
I tried adding the header as follows, but there was no change in the result.
phanak-sap commentedon Nov 30, 2023
Hi @ksaito1125
It is almost guarantied it is the same problem. The odata-v2-strict-json-format : true IMHO will perhaps work with "SAP C4C API" only. the get_entities needs to be fixed, with workaround to stay on 1.10.1.
One side-note - it seems to me that you are doing (list of transports, "s4hanaapi") basically same thing as what CLI tool sapcli does. Which has many others already implemented features which may be of interest to you.
Recommending checking out https://github.com/jfilak/sapcli/blob/master/doc/commands.md and https://github.com/jfilak/sapcli/blob/master/doc/commands/cts.md
manuelseeger commentedon Nov 30, 2023
Problem was caused by my PR #258 . If there are deferred subcollections in the result they are included in the entity proxy. I'll submit a patch.
Fix SAP#262
phanak-sap commentedon Nov 30, 2023
@manuelseeger Thanks a lot taking this on yourself.
Fix #262 (#264)
phanak-sap commentedon Nov 30, 2023
Hi @anthonyng288 and @ksaito1125
I will create soon 1.11.1 release containing just this fix.
If you want, you can test this locally even before that as bug reporters, using (preferably in virtualenv or similar kind of isolation):
pip install git+https://github.com/SAP/python-pyodata.git@dc649f4