Hi guys, There have not been any code changes since the last update on 03-01-2014 however there was some discussion on the design of the Helix API today which is summarized below
Participants: Kishore, Kanak and myself. Kishore and Kanak please correct me if I misrepresented any of the discussion. (1) HelixProperty will be renamed to HelixRecord which will internally have HelixKey and HelixValue. (2) HelixKey is what is currently PropertyKey in Helix. A key is not versioned. A key is a path to the value stored. There was much discussion on trying to surface the segmented nature of the key in the API by expressing it as a URN but was tabled to be revisited later. (3) HelixValue is a value the key points to and is currently ZNRecord. A value is versioned and each key points to the latest value. The version helps build a CAS (CompareAndSet) semantic for update calls. (4) Helix Record will be placed in the model package along with HelixKey and HelixValue (5) Model package will carry classes with accessors only, all mutations should go through commands for the same. There is concern that we may end up proliferating commands so we need to be cognizant of this when we build the commands. (6) Command builders will be put in place to allow creating the commands (7) There was much discussion on the nomenclature of Instance v/s (Participant, Observer or Admin) in Helix. The conclusion was to avoid using Instance in the API as it is confusing and was legacy. Instead we will use the specific terms of Participant, Observer, Admin in command objects. For the sake of completion, a Node is seen as a physical instance which is why the abstraction of a Node was avoided. (8) Another example of command is ResourceCommand, it will have to carry the resource configuration and will need some way to express the Rebalancer config. So a command like ResourceCommand.using(ResourceConfig).with(RebalancerConfig) maybe. More details to be discussed as we move closer to the command design. (9) The HelixAdmin is thus shaping to have an API like newValue = HelixAdmin.do(Command) or newValue = HelixAdmin.execute(Command). The call internally reads existing data from the persistent store, identifies the deltas to be applied based on the command issued and applies the deltas to the store through the data accessor. The return value is the new model value. (10) This leads to ZNRecordDelta not being necessary in the API Based on the above next things I plan to tackle in order are (a) the HelixProperty realignment as outlined in (1) above (b) reworking some objects from config into model (see email exchange for API rework summary 03-01-2014 thread) (c) move more models into API, cleanup as necessary (d) start on command objects I will send a summary as and when I tackle these and check-in code. Thanks, Sandeep
