Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Ability to play back responses by parameters instead of order #38

Open
jantman opened this issue Feb 20, 2016 · 6 comments
Open

Ability to play back responses by parameters instead of order #38

jantman opened this issue Feb 20, 2016 · 6 comments

Comments

@jantman
Copy link

jantman commented Feb 20, 2016

As was discussed in #36 (comment) it would be really nice if placebo could automatically capture the parameters/arguments for API calls, and then play the calls back according to the parameters instead of order (perhaps using order only if there are multiple calls with the same parameters).

@garnaat
Copy link
Owner

garnaat commented Feb 20, 2016

This could be relevant:

https://github.com/boto/botocore/blob/develop/botocore/stub.py

Also, for an early version of this that I did just for the skew library, I encoded the parameters into the file name so that could be an option.

@jantman
Copy link
Author

jantman commented Feb 21, 2016

I know it would increase the complexity a bit, but I was thinking that maybe it would be better if this used a single file instead of multiple ones, or else uses the existing file structure but uses a special file to key the parameters to the filename? Encoding the parameters into the filename would probably work in most common cases, but I can also see the filenames getting very long for some API calls (which would look especially bad on GitHub). It's also problematic with how long the iteration tokens are for some API responses (EC2 describe_volumes returns a 304-character NextToken).

As an example of a problematic filename, I'm thinking of something like:

conn = boto3.client('ec2')
result = conn.describe_volumes(
    Filters=[
        {
            'Name': 'attachment.status',
            'Values': ['attached']
        },
        {
            'Name': 'volume-type',
            'Values': ['io1', 'gp2']
        }
    ],
    NextToken='eyJ2IjoiMSIsImMiOiJENU1EWFFjTUh2N0l3ZllSZHlkZ0ZZdnl3LzJhd281eDBFUWRhVjUrUDFudE1TUm1USFJzbmpsS3Fnei9ZYlRZSEgrbWl3c3BxQmYwcXdwN1J5SmJHbkRiOEg2OTVWaGRaSmxhZTNSWS9pYkg1bXFhVlRnQWtRZ01ES2NJUkVSRlJ0Q05lWVlvcmRqRzZoVTBVbkN6YmNjMFBVUVp3NFl0SkE5b3RlR1FZdzQ9IiwiaSI6InZ3MEIzQlo0bGdTL1JhNEcyekJRRUE9PSIsInMiOiIxIn0='
)

@jonjitsu
Copy link

What about serializing the parameters and then using a hash function to create a low collision unique ID.
The filenames would become:

ecs.DescribeContainerInstances_XXXXXXXXX.json

where XXXXXXXX is the hash.

@RyanJarv
Copy link

Just working on this now, so far hashing on parameters (uri, body, etc) is working ok in my limited testing.

Thinking about what edge cases might come up here now.

Pagination would be one at least, not sure how I should handle that atm.

@Johnlon
Copy link

Johnlon commented Jan 4, 2024

If the matching is done on a query param lookup rather than merely an index then the assertions would be MUCH better and also such a change would avoid the need for #83

@Johnlon
Copy link

Johnlon commented Jan 4, 2024

What about serializing the parameters and then using a hash function to create a low collision unique ID. The filenames would become:

ecs.DescribeContainerInstances_XXXXXXXXX.json

where XXXXXXXX is the hash.

Difficult to understand / explain / maintain.
Please don't focus on cramming something opaque into the file name.

Matching via a lookup text file that lists expected queries is more straightforward.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants