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

Add Validation property to response. #21

Merged
merged 6 commits into from
Mar 29, 2021
Merged

Conversation

mkatychev
Copy link
Contributor

@mkatychev mkatychev commented Mar 16, 2021

  • split Response into response.rs file
  • Added Response.validation in preparation for comparison modes
  • Made Request.body an Option<Value> to more accurately reflect empty body requests.

serialization impl

commit removing value.rs

interim commit

interim commit
@mkatychev mkatychev changed the title initial commit Add Validation property to response. Mar 25, 2021
@mkatychev mkatychev marked this pull request as ready for review March 25, 2021 16:53
Self {
body: None,
uri: Value::Null,
etc: Some(json!({})),
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Serde does not currently support #[serde(default, flatten)] combination:
thus calling deserialize on a flattened property will always return a Value::Object(<Map, Value>)

serde-rs/serde#1626

Comment on lines +91 to +95
impl<'a> PartialEq for Response<'a> {
fn eq(&self, other: &Self) -> bool {
self.body.eq(&other.body) && self.etc.eq(&other.etc) && self.status.eq(&other.status)
}
}
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

self.validator should always be ignored

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

could be worth adding a docstring comment to the eq method that notes why we're defining equality to mean what it does (and e.g. why validator doesn't count)

Copy link
Contributor

@mplanchard mplanchard left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

👍

pub(crate) request: Request,
pub response: Response,
pub response: Response<'a>,
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

does the instruction set necessarily have the same expected lifetime as the response?

Copy link
Contributor Author

@mkatychev mkatychev Mar 26, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As long as both Response.validation holds a BTreeMap<&'a str, Validator>, and InstructionSet.writes holds a HashMap<&'a str, &'a str>, both those properties should live as long as the deserialized Frame object since both those lifetime references start upon deserializing the json file.

let val = serde_json::to_value(v)?;
return Ok(Some(val));
}
Ok(None)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

for fun, since we were just talking about transpose:

self.body  // Option<Value>
  .map(|v| serde_json::to_value(v))  // Option<Result<Value, E>>
  .transpose()  // Result<Option<Value>, E>

Comment on lines +91 to +95
impl<'a> PartialEq for Response<'a> {
fn eq(&self, other: &Self) -> bool {
self.body.eq(&other.body) && self.etc.eq(&other.etc) && self.status.eq(&other.status)
}
}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

could be worth adding a docstring comment to the eq method that notes why we're defining equality to mean what it does (and e.g. why validator doesn't count)


impl<'a> Eq for Response<'a> {}

type Validator<'a> = BTreeMap<&'a str, Validation>;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Curious as to why you chose a BTreeMap for this rather than a HashMap (possibly worth a comment to explain in-code)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There needs to be an order of operations for instances like this:

{
  "validation": {
    "'response'.'body'": {
      "strict": false
    },
    "'response'.'body'.'collection'": {
      "strict": true
    }
  }
}

};
let attempts: Option<Attempts> = request
.get_etc()
.as_ref()
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is the .as_ref() needed?

Copy link
Contributor Author

@mkatychev mkatychev Mar 26, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

pub fn get_etc(&self) -> Option<Value> returns a "naked" Value so I need to create a reference,
otherwise you'd be dealing with a &Option<T> instead of an Option<&T>

@mkatychev mkatychev merged commit b641def into master Mar 29, 2021
@mkatychev mkatychev deleted the custom_json_struct branch March 29, 2021 15:40
@mkatychev mkatychev restored the custom_json_struct branch May 28, 2021 19:54
@mkatychev mkatychev deleted the custom_json_struct branch May 28, 2021 19:55
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

Successfully merging this pull request may close these issues.

2 participants