Storage Approach


  • DefaultNetwork currently maintains the life-cycle of Edge and Node elements, but the underlying stores are also tickled at various times. There is not yet a cohesive approach.
  • CA-63 moves this forward at least to the point of functionality, but an overall design would be a bigger step forward.
  • Sometimes there are services (NodeService) which talk to the Stores directly. Part of the overall solution will be to add a RecommendationService which is intended to span the Edge and Node stores.
  • DefaultNetwork holds some of the responsibility as well as SegmentService.
  • Currently, the NodeService is handling the addition of elements which have been blessed by the user/client.

Flow - Initialization of DefaultNetwork instance

The trigger in this flow is the request to instantiate the DefaultNetwork. With Dependency Injection, this occurs at the time a dependent class is instantiated, which can be at the start of a Jersey REST call.

  1. The getInstance() method is invoked which kicks off the private constructor
  2. The private constructor (no args?) is invoked.
  3. getLineFeatures() is invoked on the NetworkStore. This populates from disk when necessary (lazy initialization — not clear when this might be refreshed).
  4. The ‘allLineFeatures` instance variable of the DefaultNetwork (should be shown in composition) holds the ’working' copy of the Edges and Segments (not completely sure we need to distinguish these). It is originally sourced (as mentioned above) from the permanent storage.
  5. A utility class turns the List of LineFeature into a FeatureCollection which serves as the 'published' copy of the network's Edges and Segments.
  6. The last step to initializing the Network

Flow - Update Published Edges

These steps are not numbered on the diagram above. When turning this into an electronic diagram, it would be good to show this as a separate flow with the same classes.

  1. REST endpoint for confirming a recommendation sends the appropriate NetworkProposal (not shown) to the NodeService (perhaps turning into Rec Service).
  2. The NodeService makes calls (green line) into the SegmentService (again, not shown) to make changes to the allLineFeature list. This also tickles the Map which allows retrieving the features by ID.
  3. Nodes are also updated, but do not participate in the publishing.
  4. Once the NodeService completes the various additions and deletions, it triggers the TranslateUtil to "publish" the network's edges and segments. (storesReadyForPublishing() method).

Flow - Building Recommendations

Recommendations are built by considering what options are provided by the existing Network. For this case, the TrackEval class (and also the buildRec proposal method of the NodeService class — which should also move over to a Rec Service), will talk to a combination of the stores and the DefaultNetwork. This can be confusing.

  1. REST endpoint supplies a lat/lon pair which is evaluated against the network (Nodes and Edges). If the node co-incides directly with either an existing node or an Edge, this is handled without a Track-based recommendation.
  2. Flow on the diagram above shows the TrackEval involvement for Track based proposals.
  3. The Edges (shown) and Nodes (not shown) are consulted directly and without involvement of the Network service. Again, this could be confusing.

One bug that has already been corrected was checking the edges instead of the working copy `allLineFeatures`. This diagram is not yet updated to reflect this.

Unless otherwise stated, the content of this page is licensed under Creative Commons Attribution-ShareAlike 3.0 License