Customizable payloads for update and insert - #9
Conversation
NBIX-Mark-Southern
commented
Feb 21, 2025
For readers, my current workaround is a custom Session... classPrepareSession(requests.Session):
defprepare_request(self, request: Request) ->PreparedRequest:
prepared_request=super().prepare_request(request)
ifprepared_request.methodin ["POST", "PUT"] andprepared_request.body:
body= {}
forkey, valueinjson.loads(prepared_request.body).items():
ifvalueisNone:
continueifkey=="@odata.type":
continueifkey.endswith("@odata.bind") andnotvalue.startswith("/"):
value=f"/{value}"body[key] =valueprepared_request.body=json.dumps(body)
prepared_request.headers["Content-Length"] =str(len(prepared_request.body))
returnprepared_request |
I'm currently thinking that the 3rd option you suggested would be best. @dataclassclassODataServerFlags:
skip_null_properties: bool=Falseprovide_odata_type_annotation: bool=Falseodata_bind_requires_slash: bool=FalseWe should always pass an instance of the flags, we could have a default instance for the user if they don't want to specify it where the defaults are the current behaviour of the library. What do you think? |
NBIX-Mark-Southern
commented
Feb 24, 2025
I think you are exactly right, a combination of a configuration/flags class and passing through the service is definitely the way to go. I've updated the PR with an implementation of this. A bit more rigorous this time, I found and fixed some tests that were broken in my environment and TestCompositeKeys.test_update_entity which was broken by my PR #10! |
NBIX-Mark-Southern
commented
Feb 27, 2025
via email
Hey. In case you didn’t see, I have an update for you.
#9
Best,
Mark.
From: eblis ***@***.***>
Sent: Friday, February 21, 2025 11:21 PM
To: eblis/python-odata ***@***.***>
Cc: Mark Southern ***@***.***>; Author ***@***.***>
Subject: [EXTERNAL] Re: [eblis/python-odata] Customizable payloads for update and insert (PR #9)
This message comes from an external organization. Exercise caution when opening attachments or clicking links, especially from unknown senders.
I'm currently thinking that the 3rd option you suggested would be best.
I'm thinking that we could pass in an instance of a new class ODataServerFlags into ODataService, and the flags class could be something like:
@DataClass
class ODataServerFlags:
skip_null_properties: bool = False
provide_odata_type_annotation: bool = False
odata_bind_requires_slash: bool = False
What do you think?
—
Reply to this email directly, view it on GitHub<#9 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/BIKIFPVIQH7NKMNHFHIQ4O32RAQOFAVCNFSM6AAAAABXT2YBG2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDMNZWGA3DQMRZHA>.
You are receiving this because you authored the thread.Message ID: ***@***.******@***.***>>
[eblis]eblis left a comment (eblis/python-odata#9)<#9 (comment)>
I'm currently thinking that the 3rd option you suggested would be best.
I'm thinking that we could pass in an instance of a new class ODataServerFlags into ODataService, and the flags class could be something like:
@DataClass
class ODataServerFlags:
skip_null_properties: bool = False
provide_odata_type_annotation: bool = False
odata_bind_requires_slash: bool = False
What do you think?
—
Reply to this email directly, view it on GitHub<#9 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/BIKIFPVIQH7NKMNHFHIQ4O32RAQOFAVCNFSM6AAAAABXT2YBG2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDMNZWGA3DQMRZHA>.
You are receiving this because you authored the thread.Message ID: ***@***.******@***.***>> |
eblis
commented
Feb 28, 2025
I'm sorry, was a bit busy with other tasks, I saw the PR but didn't have time until today. Hope it works out for you. |
NBIX-Mark-Southern
commented
Feb 28, 2025
Not at all, thank you so much for such a helpful project. Maybe sometime in future we can talk about batched odata! |
For discussion; my OData source fails inserts and updates when payloads:
@odata.type@odata.bind's do not have a slash prefixI had a look at an existing PR but have reservations as every single call to save or update must pass state and increase client code complexity. Instead, I created some Class properties in the EntityState class so that it's payload generation is customizable. These can be set once only in a session though I guess this approach would fail if more than one incompatible odata source were being used at the same time. A third possibility might be to pass parameters through the
ODataService, store in theContextand pass to theEntityStatethat way.Thoughts welcome, thank you.