Introduce Solution Model #309
Conversation
| @@ -170,48 +171,42 @@ class Vrp < APIBase | |||
| id = params[:id] | |||
| job = Resque::Plugins::Status::Hash.get(id) | |||
| stored_result = APIBase.dump_vrp_dir.read([id, params[:api_key], 'solution'].join('_')) | |||
| solution = stored_result && Oj.load(stored_result) rescue Marshal.load(stored_result) # rubocop:disable Security/MarshalLoad, Style/RescueModifier | |||
| job_object = stored_result && Oj.load(stored_result) rescue Marshal.load(stored_result) # rubocop:disable Security/MarshalLoad, Style/RescueModifier | |||
There was a problem hiding this comment.
why not result_object or solution_object or just result / solution?
There was a problem hiding this comment.
Actually, the object stored in redis is neither a single solution nor a single result.
It holds all the properties of the job and which contains a key called :result which is collection of solutions.
By changing the naming, I want to separate the internal objects from the objects manipulated on the api side to avoid confusion
There was a problem hiding this comment.
Yes but the part that is dumped (and loaded here) is a result, is it not?
There was a problem hiding this comment.
We directly store the content of the job returned through Redis
There was a problem hiding this comment.
I think I understand the differentiation you want to make but I don't think job_object is the way to go, because we have a class Job and real objects of this class which is confusing.
I know that it is not directly a single result nor a solution but at the end of the day we do get/set this "object" via OptimizerWrapper::Result class that's why I suggest calling it result_object:
result_object ||= OptimizerWrapper::Result.get(id)With the suffix _object we give a heads-up that it is not exactly solution[:result]. Would that work for you?
No description provided.