getReport2 should not rewrite the request about adobe-analytics-api-2.0

[loldenburg]

@pitchmuc sorry forgot to mention you. ;)

[loldenburg]

Small question @loldenburg, The request is being rewritten (gonna be fixed - deepcopy is a good idea), but it works, correct ? I do not have to fix that ?

The request works, just if it fails and you then want to try it again, it does not work because it has been re-written.

Q2: "Have you tried this?"
No. I still think the original request JSON should not be modified by the wrapper, even if you offer this option.

"Sorry it is unclear on the video where you grab the _req variable.
It seems you are trying to access a global variable, which will obviously get used.
I am not using Rust yet :D so I do not borrow things, I own them once they are passed. (For better of worse :D )
I would not have think that someone wants to have that original memory cache variable to stay unchanged.
It is interesting."

I am simply doing sth like:

req = {...} # the JSON request
req_copy = copy.deepcopy(req)
print(req == req_copy) # True
report = aa2.getReport2(req)
req == req_copy # now it is False, and that is highly unexpected, the wrapper should not change the request input, it should just return the response

As the code shows, req is no longer the original JSON request, but what the AA wrapper has rewritten it to. That is imho not how it should work, the original request JSON should remain unchanged so I can use it for the next request (and eg change it a bit for a similar report, e.g. try the same request, but with another segment on top).

Q3
"Question n°3
Do you want to have a deep copy of your original request in that attribute ? Or the one you have use with the possible parameter modification you could use via getReport2.
I am thinking the latter, so you have a copy of the real request that is sent to Adobe Analytics.

I hope these questions make sense"
=> Not sure if I understand. I just don't want the wrapper to modify the request I hand to the wrapper in any form in my scope, so creating a deepcopy of it and then doing your work on your end will do it. Just like when I hand a parameter to a function, I expect the function to work with the parameter, but not change its value in the outer scope.

"btw: I modify it when I am building the report afterwards via the Workspace class.
In order to ensure that I can give a name to the segment for the dataframe, I am building a segment name based on the context I can find on the segment.
In your case, it is a Hit segment with None search.

I am trying my best (probably too hard) to make it easily readable by users."
=> Yeah I appreciate that, but I guess that is too much... :) I just would not expect the wrapper to change sth in my outer scope. If you provide your "formatted" request as a separate sub-dictionary like myData.normalizedRequest, that may be a compromise.

[loldenburg]

In other words, if your wrapper is a worker with a shovel whom I can give directions (request) to dig out a treasure chest (report data), I don't expect the worker to have my directions changed after I receive the treasure chest. Maybe in the sense of "we normalized your directions, see the alternative here", but not simply discard and overwrite the original directions.

[loldenburg]

Sorry, finally found time to verify this now. It looks good now, thanks a lot! The request is no longer rewritten.

[pitchmuc]

Hey @loldenburg, yes I know, I think one of the latest bug was also providing me this type of feedback in the background. (see #95)
I was not respecting the parameter passed in the JSON and overwrite them by the default value pass as parameter.
So you would be able to run the same request but you need to tweak the parameter, which obviously the basic AA user do not even know they existed in the first place. :D

I will look into that specific example you gave me.

Make sure you have the latest version of the aanalytics2 library as well, as I solve some of these problems already.

I am in the middle to update the authentication method to support the new Oauth V2 token and I hope to be able to do a global release to fix that and support the new Oauth V2 token at the same time.
Hopefully you can wait ~10 days for that (hopefully faster but let's see)

[loldenburg]

Thanks, I do have the newest library (aanalytics2 0.3.3.post3) I think. No hurry with the fix. I have a workaround now in that one script where this request rewriting causes most of the trouble. My wrapper around your wrapper saves a deepcopy of the request before it passes it to getReport2, and if getReport2 fails, it retries with another deepcopy of the deepcopy :D But of course that is suboptimal.

Updating to support oAUTH V2 is amazing!
MERCI BEAUCOUP!

[pitchmuc]

Please bear with me as it takes a bit more time.
Summit and the AEP user rights modification created delay with verification of Oauth Server to Server compatibility.

[pitchmuc]

Small question @loldenburg,
The request is being rewritten (gonna be fixed - deepcopy is a good idea), but it works, correct ?
I do not have to fix that ?

[pitchmuc]

other questions @loldenburg :
I do not do a deepcopy yet of the request but I propose it via the Workspace instance.
You can retrieve it via this type of call :

myData = aa2.getReport2(myrequest)
myData.dataRequest ## your request. 

Question n°2
Have you tried that ?

Sorry it is unclear on the video where you grab the _req variable.
It seems you are trying to access a global variable, which will obviously get used.
I am not using Rust yet :D so I do not borrow things, I own them once they are passed. (For better of worse :D )
I would not have think that someone wants to have that original memory cache variable to stay unchanged.
It is interesting.

Question n°3
Do you want to have a deep copy of your original request in that attribute ? Or the one you have use with the possible parameter modification you could use via getReport2.
I am thinking the latter, so you have a copy of the real request that is sent to Adobe Analytics.

I hope these questions make sense

[pitchmuc]

btw: I modify it when I am building the report afterwards via the Workspace class.
In order to ensure that I can give a name to the segment for the dataframe, I am building a segment name based on the context I can find on the segment.
In your case, it is a Hit segment with None search.

I am trying my best (probably too hard) to make it easily readable by users.

[pitchmuc]

I have updated the behavior of the getReport2 and Workspace elements.
it should now work as you would expect, you can always retrieve the element on your attribute.
You can test now based on this git push : 172d9ce

Or wait for when I publish it, I have other change to take care of.

[loldenburg]

Thanks a ton, very much appreciated. I am really full this week so might not have time to test.

…

On Mon, Jun 19, 2023 at 1:17 PM Julien ***@***.***> wrote: I have updated the behavior of the getReport2 and Workspace elements. it should now work as you would expect, you can always retrieve the element on your attribute. You can test now based on this git push : 172d9ce <172d9ce> Or wait for when I publish it, I have other change to take care of. — Reply to this email directly, view it on GitHub <#96 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AD34SUCEUQXDMHUUOC52YQ3XMAYNJANCNFSM6AAAAAAYME52LU> . You are receiving this because you were mentioned.Message ID: ***@***.***>