wiki:GROUP_MEM_RESOURCES_MODEL_R0

Version 3 (modified by mira, 16 years ago) (diff)

--

Error: Macro BackLinksMenu(None) failed
compressed data is corrupt

Error: Macro TicketQuery(summary=GROUP_MEM_RESOURCES_MODEL_R0, format=table, col=summary|owner|status|type|component|priority|effort|importance, rows=description|analysis_owners|analysis_reviewers|analysis_score|design_owners|design_reviewers|design_score|implementation_owners|implementation_reviewers|implementation_score|test_owners|test_reviewers|test_score|) failed
current transaction is aborted, commands ignored until end of transaction block

Analysis

Overview

This task is the firs task of the GROUP_RESOURCE_MODEL_REDESIGN_R0. Task`s goal is to present working implementation of the new model with MemAccesses and keys and changes logic.

Task requirements

  • Complete and stable design of the mem accesses hierarchy.
  • Implementation of immutable resource model with correct manipulations.
  • Providing logic for different keys getting.
  • Providing logic for creatuons of changes, applying changes and resource revisions.

Task result

The result will be source code and documentation of aspects of the new designs that were too specific to be part of the major redesign documentation.

Implementation idea

GROUP_RESOURCE_MODEL_REDESIGN_R0
GROUP_FILE_ACCESSES_PERSISTENCE_R0

How to demo

Show the new hierarchy and demonstrate that all of the tests work.

Design

Read the major design of GROUP_RESOURCE_MODEL_REDESIGN_R0. In this tasks design are explained only the unspecified things of the first.

ResourceModel

The model will be constructed by nodes that can either have value or children but not both. Once created the value of the node could not be changed. Every value node will hold the value of specific property that could be accessed only by the right key. The children nodes will hold maps of names and corresponding nodes so basically it is an immutable tree structure.

The path in this tree structure will be going through nodes that correspond to parts of the keys id and getting a keys value is just finding the right value node and getting its value. For example if you are looking for the value of the border color of page A you should look in the tree nodes as follows : root(“”)->children->PageA->border->color. All nodes except the last one are children nodes and the last node will be value node with the ImmColor as its value.

Since all nodes have only final values the modifications on it will return new instances of the model with all modifications applied. Furthermore it will be too heavy to apply every change on its own and copy the model every time so the modify method will take as argument a Map of keys to be changed and their new values.

The model will need only correct changes so the ModelChangers should take care of producing some times more than one write so that would be easier for developers to write AutoActions.

Accesses

The mem and file accesses would have basically the same logic except that file accesses should present additional logic for persistence. For this abstracts common parent classes should be created:

LocalRootAccess – keeps an list of all created accesses and when asked to open looks in it for one at the given location. Provides abstract method createTop () to be implemented of the concrete Mem and File RootAccesses.

LocalTopAccess – Provide abstract methods createInner() to be implemented by the concrete Mem and File TopAccesses. It does not memorize the created and creates new ones every time when opening an ref but since the inner accesses don`t have model.

LocalInnerAccess – Delegating logic to its top access.

There are tests for most of the functionality – []

Implementation

(Describe and link the implementation results here (from the wiki or the repository).)

Testing

(Place the testing results here.)

Comments

(Write comments for this or later revisions here.)