You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The current plan is to rename generators into readers and refactor the current flat class structure into a two-level hierarchy -- resource_reader_base_t as the base class and resource_reader_grug_t, resource_reader_hwloc_t, and resource_reader_jgf_t as derived classes. I will also use a factory class pattern to help the upper layer written with the base reader class as much as possible.
Then, I will add one method called load into resource_graph_db_t, which takes in a base reader object and a serialized string as input and newly populates its resource graph.
Expanding this, @milroy will further extend resource_graph_db_t with additional grow and shrink methods in support of #511 and later elastic scheduling.
resource_graph_db_t will be carved out from resource/schema subdirectory to its own subdirectory called resource/store. Two advantages: 1) We don't want to create an additional dependency into schema -- in fact it will create a circular dependency between schema and readers; 2) as resource_graph_db_t will be extended in the future for elastic scheduling support, we don't want to keep this as a headerfile only implementation, but rather treat this as a first class citizen: its own header and implementation files.
No description provided.
The text was updated successfully, but these errors were encountered: