> On Oct. 18, 2015, 6:18 p.m., Michael Park wrote:
> > src/common/resources.cpp, lines 482-532
> > <https://reviews.apache.org/r/39018/diff/13/?file=1098334#file1098334line482>
> >
> >     How about a structure like the following?
> >     
> >     ```cpp
> >     Resources result;
> >     
> >     // Populate `result` based on which format.
> >     Try<JSON::Array> resourcesJSON = JSON::parse<JSON::Array>(text);
> >     if (resourcesJSON.isSome()) {
> >       result = internal::convertJSON(resourcesJSON.get(), defaultRole);
> >     } else {
> >       foreach (...) {
> >         ...
> >         result += resource.get();
> >       }
> >     }
> >     
> >     // Validate the result regardless of what format
> >     Option<Error> validate = validateCommandLineResources(result);
> >     if (validate.isSome()) {
> >       return validate.get();
> >     }
> >     
> >     return result;
> >     ```
> >     
> >     `validateCommandLineResources` is as suggested before, with the 
> > `conflictingTypes` logic encapsulated within it.
> >     
> >     I noticed we only perform the minimal validation necessary for the 
> > semicolon-delimited string format currently.
> >     That is, we only do the `conflictingTypes` check. While this is 
> > sufficient in the current state of the format,
> >     I think it simplifies the code to just do the full check. It's also 
> > future-proof if we need to extend the string format later on.
> 
> Greg Mann wrote:
>     Yep I agree that this is cleaner. I implemented it and unfortunately, 
> since `internal::convertJSON` returns a `Try<Resources>`, we have to unwrap 
> the Try before assigning it to `result`. We could get around this by wrapping 
> the `if ... else` block in a lambda and assigning the result to a 
> `Try<Resources> result`. In that case, however, we end up wrapping the 
> old-style parsed resources in a `Try` unnecessarily, so we do extra work 
> either way. I think the current version (without the lambda) is a bit more 
> readable, so I went with that one.

This is totally fine. It's no worse than what we do in the old-style resources 
where we unwrap each of the `Try<Resource>` to build the `result`:
```cpp
Try<Resource> resource = Resources::parse(name, pair[1], role);
if (resource.isError()) {
  return Error(resource.error());
}

result += resource.get();
```
Pragramatically speaking, we also only do this on start-up for command-line 
parsing and maybe in tests. Not a big deal if we're not perf-optimized here.


- Michael


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/39018/#review103063
-----------------------------------------------------------


On Oct. 20, 2015, 6:09 a.m., Greg Mann wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/39018/
> -----------------------------------------------------------
> 
> (Updated Oct. 20, 2015, 6:09 a.m.)
> 
> 
> Review request for mesos, Adam B, Alexander Rukletsov, Jie Yu, and Michael 
> Park.
> 
> 
> Bugs: MESOS-2467
>     https://issues.apache.org/jira/browse/MESOS-2467
> 
> 
> Repository: mesos
> 
> 
> Description
> -------
> 
> This includes code changes necessary for JSON parsing of Resources. 
> Documentation changes will be posted soon in another review 
> (https://reviews.apache.org/r/39102/).
> 
> 
> Diffs
> -----
> 
>   include/mesos/resources.hpp 6c3a065945eb56dc88df9c977e5ca11d4cbcbf61 
>   include/mesos/v1/resources.hpp fe8925ac851b74d1b37919f00afc7ed816f47ea5 
>   src/common/resources.cpp 601388c35a1bff37c58e753d1870d53b8d0af2d1 
>   src/tests/resources_tests.cpp 6584fc6c39e6ffe9f8085576677dcc669f127697 
>   src/v1/resources.cpp dc868903472f8f3a1ddc56092e3f8f81d953ce39 
> 
> Diff: https://reviews.apache.org/r/39018/diff/
> 
> 
> Testing
> -------
> 
> New code was added to `ResourcesTest.ParsingFromJSON`, and two new tests were 
> added: `ResourcesTest.ParsingFromJSONWithRoles` and 
> `ResourcesTest.ParsingFromJSONError`. These attempt to test common error 
> scenarios that might show up in user-supplied JSON.
> 
> `make check` was used to confirm that all tests pass, with one notable 
> failure (ResourcesTest.ParsingFromJSONError) related to a picojson issue 
> tracked here: https://issues.apache.org/jira/browse/MESOS-3698
> 
> The original resources parsing format is used throughout many other tests 
> (check `src/tests/sorter_tests.cpp`, for example), so it's clear that the 
> original parsing continues to work correctly.
> 
> 
> Thanks,
> 
> Greg Mann
> 
>

Reply via email to