> 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.
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. - Greg ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/39018/#review103063 ----------------------------------------------------------- On Oct. 20, 2015, 5:01 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, 5:01 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 > >
